11-3.【错误处理】throws 在链式调用中是如何传播的？它对性能有什么影响？在 Swift 中，throws 的链

在 Swift 中，throws 的链式调用（尤其是结合可选链 ? 或高阶函数）遵循一种**“短路传播”与“显式冒泡”**相结合的机制。

它的底层实现非常精巧，旨在保证错误能够安全传递的同时，尽可能减少 CPU 的指令跳转开销。

Swift 中的 throws 传播主要分为两种场景：

当你调用一系列返回 throws 的函数时，每一个 try 都会在底层生成一个条件检查点。

Swift

func process() throws {
    try step1() // 如果抛出，直接跳出 process，将错误寄存器传给上层
    try step2() // 只有 step1 成功才会执行
}

底层逻辑： 编译器为每个 try 生成一个 test 指令和一个 jne (jump if not equal) 跳转。如果错误寄存器不为空，程序计数器（PC）会直接跳转到函数的退出点，执行栈清理并返回。

try? 是将 throws 转换为 Optional 的“转换器”。

Swift

let result = try? fetchData()?.parse()

传播逻辑：如果 fetchData() 抛出错误或返回 nil，或者 parse() 抛出错误，整条链条会立即停止。
类型提升：try? 会将结果包装成 Optional。如果内部本身返回 Int?，结果会变成 Int??（除非使用 flatten 逻辑）。

尽管 Swift 的 throws 很轻量，但在链式调用中，性能影响主要来自以下三个维度：

在“一切正常”的情况下，throws 的链式调用性能极高。

原因：由于 Swift 使用专用的错误寄存器（如 ARM64 的 x21），调用方只需在函数返回后检查该寄存器是否为 0。
CPU 友好：现代 CPU 的分支预测器对这种“大部分时间为 0”的检查非常擅长。在成功路径上，它的开销仅相当于一次额外的寄存器比较，比 Objective-C 的 NSError** 指针检查要快得多。

当错误真实发生并开始传播时，成本会上升：

跳转开销：每一层嵌套的 try 都会执行一次跳转指令。
错误包装（Boxing） ：在 Swift 6 之前，抛出的错误会被包装进 any Error（存在体容器）。这涉及到堆内存分配和**引用计数（ARC）**操作。
性能瓶颈：如果你在长循环中频繁触发 throw，堆分配和 ARC 会成为明显的性能瓶颈。

每一个 try 都会让编译器生成额外的分支检查代码。在极大规模的链式调用中，这会导致二进制文件体积（Code Size）略微增大，虽然对运行速度影响极小，但对指令缓存（I-Cache）会有微弱影响。

在 Swift 6 中，如果你使用具名错误抛出：

Swift

func step() throws(MyError) -> Int

性能优化：编译器知道错误的具体类型和大小。如果 MyError 是一个简单的 enum，编译器可以直接在寄存器中传递错误值，完全跳过堆分配和包装逻辑。
结果：这使得 throws 在失败路径上的性能几乎等同于返回一个 Result 枚举，甚至更优。

为了获得最佳性能和安全性，建议在复杂链式调用中遵循以下原则：

避免在循环核心（Hot Loop）中使用 throw：如果一个操作每秒执行数万次且经常失败，使用 Optional 或 Bool 会比 throws 快得多。
优先使用 try? 处理非关键错误：如果你不关心错误细节，try? 可以简化传播链，减少冗余的 catch 逻辑。
利用 Result 存储，利用 throws 传递：
- 在异步回调或数组存储中使用 Result（它是静态的）。
- 在同步的逻辑转换流中使用 throws（它是动态的且具有短路特性）。

总结： Swift 的 throws 链式调用通过“寄存器传递 + 自动短路”实现了极高的成功路径性能。只要避免在超高频循环中产生大量错误，它的性能开销在绝大多数工程应用中都是可以忽略不计的。

11-3.【错误处理】throws 在链式调用中是如何传播的？它对性能有什么影响？