有几个问题与此完全相反，我不明白为什么/为什么在发布模式下运行我的应用程序，但在调试模式下崩溃与EXC_BAD_ACCESS错误。
崩溃的方法是递归的，非常!!大量的;只要没有太多的递归，它在调试（iPhone XS上少于~1000，模拟器上无限制）和发布模式（无限制？）上都能正常工作。
我不知道在哪里开始找到如何调试调试模式，我想知道是否存在由于堆栈跟踪或其他未知的某种递归软限制捆绑？它甚至可以归结为电缆，因为我能够在模拟器中成功运行而没有问题吗？
我应该注意到Xcode报告看似随机点的崩溃，比如我知道实例化和有效的属性getter;如果有帮助。
我将把它重构为更小的块，但我想我会发布这里，以防任何人对可能导致此问题的任何想法有所了解。
见：https://gist.github.com/ThomasHaz/3aa89cc9b7bda6d98618449c9d6ea1e1
你的堆栈内存不足了。
考虑这个非常简单的递归函数，将1和n之间的整数相加：
func sum(to n: Int) -> Int {
guard n > 0 else { return 0 }
return n + sum(to: n - 1)
}
您会发现，如果您尝试将数字总和在1到100,000之间，那么应用程序将在发布和调试版本中崩溃，但在调试版本中会更快崩溃。我怀疑在调试版本中只有更多的诊断信息被推送到堆栈中，导致它更快地耗尽堆栈中的空间。在上面的发布版本中，堆栈指针每次递归调用前进0x20字节，而每次调试构建前进0x80字节。如果你在递归函数中做了任何重要的事情，这些增量可能会更大，并且可能会发生崩溃，甚至更少的递归调用。但是我的设备（iPhone Xs Max）和我的模拟器（Thread.current.stackSize）上的堆栈大小是524,288字节，这对应于堆栈指针前进的量以及我能够实现的递归调用的最大数量。如果您的设备比模拟器更快崩溃，那么您的设备可能内存较少，因此分配了较小的stackSize。
最重要的是，如果您希望享受快速性能但又不想产生巨大调用堆栈的内存开销，您可能希望将算法重构为非递归算法。顺便说一下，上面的非递归再现比递归再现快一个数量级。
或者，您可以异步调度递归调用，这可以消除堆栈大小问题，但会引入GCD开销。上述异步再现比简单的递归再现慢两到三个数量级，显然，比迭代再现慢一个数量级。
不可否认，我简单的sum方法是如此微不足道，以至于递归调用的开销开始代表整个计算时间的重要部分，并且鉴于您的例程似乎更复杂，我怀疑差异将不那么明显。尽管如此，如果你想避免耗尽堆栈空间，我只是建议追求非递归的再现。
我将向您推荐以下WWDC视频：
值得注意的是，深度递归例程并不总是需要占用大量堆栈。值得注意的是，有时我们可以使用tail-recursion，其中我们的递归调用是最后一次调用。例如。我上面的代码片段不使用尾调用，因为它将n添加到递归调用返回的值。但是我们可以重构它来传递运行总数，从而确保递归调用是一个真正的“尾调用”：
func sum(to n: Int, previousTotal: Int = 0) -> Int {
guard n > 0 else { return previousTotal }
return sum(to: n - 1, previousTotal: previousTotal + n)
}
发布版本足够智能以优化此尾递归（通过称为“尾调用优化”的过程，TCO，也称为“尾调用消除”），减轻递归调用的堆栈增长。 WWDC 2015 Profiling in Depth，在另一个主题上，时间分析器，显示在优化尾部调用时发生的确切情况。
实际效果是，如果您的递归例程使用尾调用，则版本构建可以使用尾调用消除来缓解堆栈内存问题，但调试（非优化）构建将不会执行此操作。
EXC_BAD_ACCESS通常意味着您正在尝试访问不在内存中或可能未正确初始化的对象。
检查你的代码，如果你以某种方式删除它后访问你的Dictionary变量？你的变量是否已正确初始化？您可能已声明该变量但未初始化并访问它。
可能有很多原因，如果没有看到任何代码，就无法说清楚。
尝试打开NSZombieOjects - 这可能会为您提供更多的调试信息。请参阅此处如何在Xcode中启用NSZombie？
如果您想知道错误发生的确切位置和时间，您可以使用仪器检查内存泄漏。这可能是有用的http://www.raywenderlich.com/2696/instruments-tutorial-for-ios-how-to-debug-memory-leaks