10-9.【安全性与稳定性】在发布版本和 Debug 版本中，断言的行为有什么差异？断言的行为差异主要源于 Swift

断言的行为差异主要源于 Swift 编译器的**优化级别（Optimization Level）**设置。

在 Swift 中，编译器会根据不同的构建目标（Build Configuration）自动决定是否将断言指令编译进最终的二进制文件中。

1. 核心行为差异表

特性	Debug 版本 (-Onone)	Release 版本 (-O)	Release Unchecked (-Ounchecked)
`assert`	生效：触发崩溃并报错	被移除：代码不执行	被移除
`precondition`	生效：触发崩溃并报错	生效：触发崩溃并报错	假定成功：不检查，后果不可测
`fatalError`	生效：始终崩溃	生效：始终崩溃	生效：始终崩溃
对性能的影响	较低（但存在检查开销）	无开销（断言代码被剔除）	极高（允许编译器进行激进优化）

在 Debug 模式下，编译器的首要任务是暴露问题。

在 Release 模式下，编译器的首要任务是性能和稳定性。

剔除 assert：编译器认为 assert 检查的是开发者的逻辑错误，既然 App 已经发布，这些检查就不应该再消耗 CPU 时间。
保留 precondition：它保留了对“核心契约”的检查。如果关键条件不满足（如数组越界），App 会选择主动崩溃。这是一种保护机制——宁愿崩溃，也不要带着错误的数据继续运行（可能导致数据库损坏或隐私泄露）。

这是开发者最容易犯的错误：在断言中执行业务逻辑。

Swift

// ❌ 错误示范
assert(performCriticalTask(), "任务执行失败")

防御式做法：

Swift

// ✅ 正确示范
let success = performCriticalTask()
assert(success, "任务执行失败")

在 Xcode 的 Build Settings 中，如果你将优化等级设为 Fast, Whole Module Optimization [-Ounchecked]：

编译器会完全信任你的代码，甚至跳过 precondition。
如果此时发生数组越界，它不会崩溃，而是会访问一块随机内存。这可能导致极难排查的内存漏洞。除非是极致性能要求的科学计算，否则严禁在普通 App 中开启此选项。