异常机制在正常执行路径中无性能开销，因现代编译器采用零成本异常模型，异常信息在编译时生成并存于只读段，不干扰运行时；只有抛出异常时才会产生显著开销，涉及栈展开、析构函数调用、异常对象复制等操作，耗时远高于错误码返回；频繁用异常控制流程会严重降低性能；编译器选项如-fexceptions会增加二进制体积，而-fno-exceptions可减小体积并提升性能，常用于嵌入式或高性能场景；建议仅在真正异常情况下使用异常，避免用于常规逻辑控制，可预期错误宜用错误码或optional/expected类处理，性能敏感代码可考虑禁用异常；异常本身非性能杀手，滥用才是关键问题。
很多人认为C++异常机制会影响程序性能，但实际情况取决于使用方式和编译器优化。异常本身不一定会带来运行时开销，真正的代价主要出现在异常被抛出时，而不是在正常执行路径中。
异常机制的实现原理
C++异常基于“零成本异常模型”（Zero-cost Exception Model），常见于现代编译器（如GCC、Clang、MSVC）。这意味着：
- 在没有抛出异常的正常执行路径中，代码不会插入额外的条件判断或跳转指令
- 异常信息（如调用栈展开表）在编译时生成，存储在只读段中，不干扰运行时逻辑
- 只有当异常被抛出时，系统才开始查找匹配的catch块并执行栈展开，这个过程有显著开销
也就是说，使用异常不会拖慢正常流程，但一旦发生异常，处理成本较高。
异常抛出的实际开销
当调用throw时，程序需要：
立即学习“C++免费学习笔记（深入）”；
- 查找匹配的catch块（可能涉及多层函数调用回溯）
- 调用局部对象的析构函数（RAII清理）
- 复制异常对象（除非使用引用捕获）
- 执行终止处理（如std::terminate）
这些操作的耗时远高于简单的错误码返回。例如，抛出一个异常可能需要几百纳秒甚至微秒级时间，而return -1几乎无开销。
频繁使用异常做流程控制（如用throw代替if判断）会严重降低性能。
编译器与优化的影响
不同编译选项对异常开销影响很大：
- 开启异常支持（-fexceptions）会增加二进制体积，因为需要生成异常表
- 关闭异常（-fno-exceptions）可减小代码体积并提升性能，但无法使用try/catch
- 某些优化（如LTO）能减少异常元数据的冗余
嵌入式或高性能场景常禁用异常以换取确定性行为和更小体积。
合理使用建议
为了兼顾代码清晰与效率，可以：
- 用异常处理真正异常的情况（如文件打开失败、内存分配失败）
- 避免用异常控制常规逻辑流程（如循环终止、输入验证）
- 优先通过错误码或optional/expected类处理可预期错误
- 在性能敏感代码中评估是否禁用异常
基本上就这些。异常不是性能杀手，滥用才是。理解底层机制，才能做出合适选择。
