零成本异常机制指正常执行无开销，仅在抛出异常时产生显著性能代价。编译器通过生成异常表实现无异常时零开销，但异常抛出引发栈展开、对象析构、异常对象构造及控制流跳转，导致性能下降。建议避免在性能敏感路径使用异常，优先采用错误码或std::expected处理可预期错误，合理权衡功能与性能。
C++ 异常机制在现代编程中提供了结构化的错误处理方式，但其性能影响一直是开发者关注的重点。所谓“零成本异常”（Zero-cost Exception Handling）机制，并不是指异常处理完全没有开销，而是指在不抛出异常的正常执行路径中，异常相关的代码不会引入运行时开销。只有当异常被抛出时，才会有明显的性能代价。下面从实现机制和实际影响两个层面来分析。
零成本异常机制的原理
现代C++编译器（如GCC、Clang、MSVC）普遍采用基于表的异常处理模型（如DWARF或SEH），其核心思想是：
- 编译时生成异常处理元数据表（如.eh_frame或异常表），记录每个函数的异常处理信息，包括栈展开所需的操作和catch块的位置。
- 正常执行时，程序不插入额外的条件判断或跳转指令，因此没有运行时性能损耗。
- 只有当异常被抛出时，运行时系统才会查表并执行栈展开（stack unwinding），调用局部对象的析构函数，寻找匹配的catch块。
这种设计实现了“零成本”：无异常时无开销，有异常时付出代价。
异常抛出时的实际性能开销
虽然正常路径无开销，但一旦抛出异常，性能影响显著：
立即学习“C++免费学习笔记（深入）”；
- 栈展开过程耗时：需要遍历调用栈，查找匹配的处理块，期间执行所有局部对象的析构函数（RAII）。
- 异常对象的构造与传递：throw表达式会构造异常对象，可能涉及复制或移动，尤其在多层调用中开销累积。
- 控制流跳转代价高：异常跳转不是普通跳转，涉及上下文恢复、寄存器状态重建等，比return或goto慢得多。
- 编译器优化受限：存在异常可能的函数，编译器需保留栈帧信息以支持展开，可能抑制某些优化（如内联、寄存器分配）。
实测中，抛出一次异常可能比正常返回慢几个数量级，尤其在深度调用栈中。
使用建议与性能权衡
异常适合处理罕见但严重的错误情况，不应作为常规控制流手段。以下建议有助于平衡功能与性能：
- 避免在性能敏感路径（如内层循环）中使用throw。
- 优先使用错误码或std::optional/std::expected（C++23）处理可预期的失败。
- 确保异常安全的同时，减少异常路径中的复杂析构逻辑。
- 在编译选项中，启用异常但谨慎评估是否关闭（-fno-exceptions）以换取性能和体积优化。
基本上就这些。零成本异常机制在设计上很聪明，但“零成本”仅限于未触发异常的路径。理解其背后机制，才能在工程实践中合理使用异常，避免性能陷阱。
