异常处理在提升代码健壮性的同时可能引入运行时开销，尤其在高频路径中应避免使用；可通过返回码、std::optional或std::expected替代异常传递错误状态；禁用异常（如-fno-exceptions）可消除开销，适用于性能敏感场景；合理使用noexcept、RAII及断言，确保析构函数不抛异常，并将异常用于真正异常情况，而非常规控制流，以提升程序效率。
在C++中，异常处理虽然提升了代码的健壮性和可维护性，但可能带来运行时开销，尤其是在频繁抛出异常或异常路径较深的场景中。若性能是关键考量，可以通过合理设计和使用技术手段减少异常处理带来的影响。
避免在高频路径中使用异常
异常不应作为常规控制流使用，尤其在性能敏感的代码路径中。抛出和捕获异常通常涉及栈展开、对象析构和运行时查找匹配的catch块，这些操作成本较高。
- 用返回码或std::optional/std::expected代替异常传递错误状态
- 例如，查找函数返回std::optional
而非在未找到时抛出异常
编译器优化与异常模型选择
不同编译器对异常的支持机制不同，可通过编译选项控制异常行为以提升效率。
- 使用-fno-exceptions（GCC/Clang）完全禁用C++异常，消除所有相关开销
- 禁用后，try、throw、catch将无法使用，但代码体积和执行速度可能提升
- 适用于嵌入式系统或对性能要求极高的服务端组件
减少异常安全保证的代价
异常安全的代码常依赖RAII和异常中立的析构函数，但过度使用可能引入额外检查。
立即学习“C++免费学习笔记（深入）”；
- 确保析构函数noexcept，避免在析构中抛出异常
- 使用noexcept关键字标记不抛异常的函数，帮助编译器优化调用路径
- 避免在构造函数中做可能失败的复杂操作，降低异常清理负担
用断言替代部分异常检查
对于内部逻辑错误或不可恢复条件，可在调试阶段使用断言，在发布版本中直接忽略或快速崩溃。
- assert()在NDEBUG定义时无开销
- 适用于“绝不应发生”的情况，如数组越界访问前提条件
- 避免将assert用于用户输入或可恢复错误
基本上就这些。合理权衡异常的使用场景，结合编译优化和替代错误处理机制，能有效降低运行时开销，提升程序效率。关键是把异常留给真正“异常”的情况，而不是当作常规流程控制手段。
