Swift 的 throws 机制常被误解为类似于 Java 或 C++ 的“昂贵异常”，但其底层实现实际上非常轻量化。它更接近于一种自动化的错误传播机制，而非传统意义上的异常捕捉。
1. throws 的底层实现原理
Swift 的错误处理通过一种称为 Error Handling ABI 的机制实现。
A. 寄存器返回（Register-based Returns）
在底层汇编层面，Swift 并不使用昂贵的堆栈回溯（Stack Unwinding）。当一个函数被标记为 throws 时，它的函数签名在编译时会被隐式修改：
- 普通函数：通过寄存器返回结果（如 ）。
- Throwing 函数：会额外占用一个特定的寄存器（在 ARM64 上通常是 ），专门用于存放错误对象的指针。
B. 类型擦除与自动传播
当你 throw 一个错误时：
- 错误对象被存入预留的寄存器。
- 函数立即通过普通返回指令（
ret）退出。 - 调用方（Caller） 负责检查该寄存器。如果寄存器不为空，则跳转到最近的
catch块；如果为空，则继续正常逻辑。
这种机制被称为 "Typed Throws" (在 Swift 6.0 之前本质上是类型擦除的 any Error) 。其执行开销几乎等同于一个 if (error != nil) 的判断。
2. 与 Optional / Result 的对比及成本
虽然三者在语义上都能表示失败，但在底层开销和开发体验上有显著差异：
A. 性能成本分析
| 方式 | 成功路径成本 | 失败路径成本 | 内存开销 |
|---|---|---|---|
Optional (T?) | 极低（仅需检查标签位） | 极低 | 额外 1 字节或空指针优化 |
Result (Result<T, E>) | 较高（需装箱/拆箱） | 较高（涉及枚举分支切换） | 取决于 T 和 E 的最大尺寸 |
| Throws | 几乎为零（因为寄存器是预留的） | 中等（涉及动态内存分配和寄存器写入） | 无额外包装损耗 |
- 成功路径（Happy Path） ：
throws的性能表现最佳，因为它不改变返回值的类型，不需要像Result那样进行枚举包装。 - 失败路径（Error Path） ：
throws的开销略高于Optional，因为Error协议通常涉及对象的内存分配（特别是如果使用CustomNSError）。
B. 语义与架构成本
- Optional：最简单，但丢失了“为什么失败”的信息。适用于简单的查找或尝试。
- Result：由于是值类型，它可以被存储（例如异步回调的变量）。这是
throws做不到的（throws只能在调用链上同步传递）。 - Throws：具有强制性。它迫使调用方必须处理错误，适合用于复杂的业务逻辑链。
3. 防御式编程中的平衡
在复杂架构中，我们通常这样组合使用：
- 底层/细粒度逻辑：使用
Optional（如数组越界检查）。 - 异步/数据流：使用
Result（如 Combine 或传统的闭包回调）。 - 高层/同步业务流：使用
throws。它能让代码看起来像“一切正常”的线性逻辑，而将所有的错误处理集中在catch块中。
性能建议
- 避免在循环中频繁 throw：如果一个错误发生的频率极高（例如每秒上千次），请改用
Optional或逻辑判断，因为throw涉及的动态错误类型包装会产生累计开销。 - 利用 Typed Throws (Swift 6.0+) ：通过明确指定错误类型（如
throws(MyError)），编译器可以进一步优化，甚至完全避免堆分配。
