C++异常处理在正常路径几乎零开销，但throw触发后会启动昂贵且隐式的栈展开：从抛出点向上回溯，强制调用所有已构造局部对象的析构函数，直至匹配catch；未捕获则调用std::terminate；依赖异常表增大二进制，noexcept影响优化与行为，异常对象构造、跨库传播及嵌入式限制均带来实际工程约束。
异常处理在 C++ 中不是“免费的午餐”——它在正常路径上几乎零开销，但一旦 throw 触发，就会激活一整套隐式、昂贵且难以预测的运行时机制。
栈展开（stack unwinding）是最大隐性开销来源
抛出异常时，编译器不会逐层“返回”，而是启动栈展开：从 throw 点开始，沿调用栈向上回溯，对每个已构造完成的局部对象调用析构函数，直到找到匹配的 catch 块。
- 这个过程是强制的、不可跳过的；哪怕你只 throw 一个空异常，所有中间作用域的析构函数仍会被调用
- 若析构函数本身复杂（如含 I/O、锁、递归释放），开销会指数级放大
- 未捕获异常时，
std::terminate()可能提前中止展开，导致部分资源未释放（尤其在析构函数未标记noexcept时） - 栈展开依赖编译器生成的异常表（
unwind tables），这些元数据会增大二进制体积，嵌入式或 AOT 场景下尤为敏感
noexcept 不只是声明，它直接影响编译器优化与行为
函数是否声明 noexcept，决定了编译器能否省略某些异常安全相关的保护逻辑。
- 未声明
noexcept的函数，编译器必须为其生成完整的栈展开支持代码，即使它从不 throw - 移动构造/赋值等关键操作若未标记
noexcept，容器（如std::vector）可能退化为拷贝而非移动，性能直接受损 - 若
noexcept函数内部意外抛出异常，程序直接调用std::terminate()，无法捕获——这不是 bug，是契约违约
异常对象本身的生命周期成本常被低估
每次 throw 都会构造一个异常对象，其开销远不止一次内存分配。
立即学习“C++免费学习笔记（深入）”；
- 异常对象通常在堆上分配（尤其是带字符串消息的
std::runtime_error），涉及动态内存管理 - 类型信息（
type_info）、虚表指针、异常链指针等元数据都会被附加，增加构造和匹配成本 - 捕获时若按值传递（
catch (std::exception e)），还会触发一次额外拷贝；应始终使用 const 引用（catch (const std::exception& e)） - 跨 shared library 边界抛出异常可能失败，因 ABI 和运行时环境不一致——这不是标准问题，而是部署现实
实时系统与嵌入式场景下，异常往往被禁用
在硬实时、资源受限或无完整 C++ 运行时的环境中，异常不是“可选优化”，而是明确禁止的特性。
- 很多交叉编译工具链默认启用
-fno-exceptions，此时throw/catch会编译失败 - 即便手动启用，栈展开在中断上下文或无栈环境中不可靠，
std::terminate()可能导致静默死锁 - 替代方案不是“不用错误处理”，而是显式错误码 + RAII 封装（如
std::expected）或断言 + 日志组合 - 混合代码（异常开启模块调用异常关闭模块）需严格隔离，否则异常穿越边界将触发未定义行为
真正难处理的从来不是“要不要用异常”，而是“哪些函数必须 noexcept”、“哪些资源释放路径不能依赖栈展开”、“异常表膨胀是否影响 OTA 升级包大小”——这些细节不在语法里，而在你的构建配置、部署目标和故障恢复设计中。
