启用异常处理会显著增加二进制体积，空try/catch块可增2–5 KiB，复杂模块膨胀达10–30%；-fno-exceptions能大幅削减体积但需全项目统一禁用并替换异常相关标准库调用。
启用异常处理会增加多少二进制体积？
开启 C++ 异常（-fexceptions，GCC/Clang 默认）会让编译器为每个可能抛出或捕获异常的函数生成额外的 unwind 表（如 .eh_frame 或 .gcc_except_table），这些元数据不执行，但必须驻留在二进制中。实测表明：在嵌入式或精简场景下，仅一个空 try/catch 块就可能使目标文件增长 2–5 KiB；含多个层级调用和异常路径的模块，膨胀可达 10–30% —— 具体取决于函数数量、调用深度和 RTTI 是否启用。
-fno-exceptions 能彻底消除异常开销吗？
能显著削减体积，但有前提：
- 所有翻译单元（包括所链接的静态库、第三方头文件）都必须统一禁用异常，否则链接时可能因
__cxa_throw等符号缺失失败 - 标准库组件（如
std::vector::at()、std::string构造）仍可能隐式抛异常；禁用后它们的行为变为未定义或直接 abort，需人工替换为operator[]、reserve()+push_back()等无异常替代方案 - 某些平台（如 ARM Cortex-M + newlib-nano）默认已裁剪异常支持，此时
-fno-exceptions影响极小
如何确认哪些符号或段导致体积膨胀？
用工具定位真实来源：
- 查看节区大小：
readelf -S your_binary | grep -E '\.(eh_frame|gcc_except)'
- 分析符号引用：
nm -C your_binary | grep -E '__cxa|_ZSt[^\ ]*throw'
- 对比构建：
size before.elf after.elf
观察bss/data/text变化，通常text增长最明显
注意：.eh_frame 在 stripped 二进制中仍存在，它不属于调试信息，strip 不会删它。
立即学习“C++免费学习笔记（深入）”；
不用 try/catch 就安全了吗？
不安全。即使代码里没写任何异常语法，只要链接了启用异常的标准库（如 libstdc++ 默认版本），且调用了可能抛异常的函数（std::make_unique、dynamic_cast、std::regex），编译器仍会保留 unwind 支持。真正可控的方式只有两种：
- 全局禁用：
-fno-exceptions -fno-rtti，并使用-static-libstdc++配合无异常版 STL（如libc++的-DLIBCXX_ENABLE_EXCEPTIONS=OFF） - 精细控制：对特定文件保持
-fexceptions，其余一律-fno-exceptions，但需确保异常永不跨编译单元边界传播（否则运行时 UB）
最易被忽略的是：C++17 起 noexcept 函数声明本身不减少代码体积，它只影响调用约定检查；真正起作用的是编译器开关和链接时的库选择。
