异常处理是否影响性能取决于使用方式和场景。若程序极少抛出异常，现代编译器的零成本机制确保无额外开销；但若频繁抛出异常则会导致性能下降。关键点包括：1. 不要用异常代替常规控制流；2. 避免在性能敏感代码中频繁抛出异常；3. 了解编译器优化策略。零成本机制通过异常信息表和栈展开实现，正常流程几乎无代价，仅在抛出异常时产生开销。减少开销的方法有：1. 高频路径避免异常，改用返回码或std::optional；2. 使用轻量级异常类型，减少构造开销；3. 控制catch范围，减少栈展开次数，合理使用noexcept。此外，异常支持会增加二进制体积、链接时间，并可能不适用于资源受限的嵌入式平台。
C++异常处理在现代程序设计中提供了良好的错误处理机制，但很多人也担心它带来的性能开销。其实，在大多数现代编译器中，零成本异常（Zero-cost Exception Handling）机制已经广泛应用，使得“正常执行路径”几乎不产生额外开销。本文就来聊聊如何减少C++异常处理的开销，并剖析一下零成本异常的实现原理。
异常处理真的会影响性能吗？
这个问题的答案是：取决于使用方式和运行场景。
如果你的程序很少抛出异常，只是在错误时使用
try/catch结构，那么现代编译器采用的“零成本”机制会确保你不会为没发生的异常付出代价。但如果异常频繁抛出（比如用异常控制流程），那确实会导致明显的性能下降。
立即学习“C++免费学习笔记（深入）”；
所以关键点在于：
- 不要用异常代替常规控制流
- 避免在性能敏感代码中频繁抛出异常
- 了解编译器对异常处理的优化策略
零成本异常处理是怎么回事？
“零成本”听起来很理想，但它到底是什么意思？简单来说：
在没有发生异常的情况下，几乎不带来任何运行时开销。
这主要靠两个方面实现：
- 异常信息表（Exception Table）
- 展开栈帧时不依赖运行时判断
具体来说：
- 编译器会在编译期生成一张关于函数调用栈的元数据表（通常是
.eh_frame
段），记录每个函数的入口、出口以及异常处理信息。 - 当异常被抛出时，运行时系统根据这张表进行栈展开（stack unwinding），而不需要在正常代码中插入条件跳转指令。
- 只有在真正抛出异常的时候，才会进入异常处理逻辑，这时候才会有一定的性能代价。
所以，“零成本”并不是说异常完全免费，而是指在没有异常抛出时，不会影响正常流程的执行效率。
如何减少异常处理带来的实际开销？
虽然编译器做了很多优化，但我们仍然可以通过一些手段进一步降低异常处理的性能影响。
1. 避免在高频路径中使用异常
如果你写的是一个性能敏感的内核模块、图形渲染循环或者网络服务的主干逻辑，那就尽量避免使用异常来处理可预期的错误情况。
✅ 推荐做法：
- 使用返回码或
std::optional
- 使用
std::expected
（C++23） - 对常见错误做预判而不是捕获
❌ 不推荐做法：
try {
// 每次都尝试访问容器元素
value = vec.at(i); // at()会抛出异常
} catch (...) {}2. 减少异常对象构造开销
抛出异常本身就会触发对象构造、复制等操作。如果你经常抛出大型异常对象，比如自定义的异常类包含大量字符串拼接信息，那这部分构造成本也不容忽视。
优化建议：
- 尽量使用轻量级异常类型，如
std::runtime_error
或更简单的封装 - 避免在异常构造中做复杂运算
- 如果只是标识错误类型，可以考虑只传递枚举或简短消息
3. 控制catch
范围，减少栈展开次数
异常的栈展开过程是比较耗时的。如果多个层级都需要捕获异常，而又不做实质性处理，只会增加不必要的开销。
优化建议：
- 在合适的层次统一捕获异常，避免层层嵌套的
catch
- 对不需要处理的函数，不要随意包裹
try/catch
- 使用
noexcept
标注不会抛出异常的函数，帮助编译器优化
零成本也有代价：异常支持带来的间接开销
虽然“零成本”意味着正常路径无负担，但也有一些副作用需要注意：
-
二进制体积增大：因为需要存储
.eh_frame
这类异常信息表 - 静态库链接变慢：带异常信息的目标文件会比不带的大不少
-
某些嵌入式平台禁用异常：为了节省资源，很多嵌入式环境默认关闭RTTI和异常处理（通过
-fno-exceptions
）
如果你的项目对性能和体积非常敏感，可以考虑是否真的需要开启异常处理功能。
基本上就这些。掌握好C++异常的使用边界，理解其底层机制，才能在写出安全代码的同时兼顾性能。
