日常开发必须用-O0调试，交付构建推荐-O2，-O3仅适用于已验证无副作用的数值计算热点；-O0保证源码与指令严格对应，-O2平衡性能与稳定性，-O3则以牺牲可调试性和浮点精度为代价换取极限性能。
直接结论：日常开发用 -O0，交付构建用 -O2，数值计算或已验证无副作用的热点代码才考虑 -O3。
什么时候必须用 -O0
调试阶段不是“可以”用 -O0，而是“必须”——只要你在 GDB/LLDB 里设断点、看变量值、单步执行，就别碰其他优化级别。因为 -O0 唯一保证的是：源码第 42 行对应机器指令第 42 行，int x = 5; 的值真能被调试器读出来，不会被优化掉或提前计算进寄存器。
常见错误现象包括：
- 断点设在某行却跳过，或停在完全不相关的行
- 打印
x显示“<optimized out></optimized>” - 函数调用栈缺失中间帧（内联未禁用时更明显）
注意：-O0 不等于“没编译器处理”，它仍会做语法检查、宏展开、预处理；只是不做任何语义等价变换。如果你在 CI 流水线里对 debug 构建也用了 -O2，那等于把调试能力主动交出去了。
-O2 是生产环境的默认安全线
-O2 启用的优化（函数内联、循环展开、寄存器分配、死代码消除、强度削减）覆盖了绝大多数性能瓶颈场景，且不引入额外风险。它的核心价值不是“比 -O1 快多少”，而是“在不改变程序行为的前提下，榨干通用 CPU 的流水线和缓存效率”。
几个关键事实：
- Clang 和 GCC 对
-O2的实现高度收敛，跨编译器行为可预期 - 它默认禁用可能破坏浮点语义的重排（比如
a + b + c不会擅自改顺序），对科学计算友好 - 生成的二进制体积通常比
-O3小 10%–20%，对嵌入式或移动端仍有意义 - 几乎所有 Linux 发行版的包构建、Rust 的
releaseprofile、Xcode 的 Release scheme 都默认走-O2
不要因为听说 -O3 “更快”就盲目升级——很多项目实测发现，-O3 在某些 ARM 或旧款 x86 上反而因指令缓存压力增大而变慢。
-O3 的真实代价常被低估
-O3 不是 -O2 的“加强版”，而是策略转向：它主动承担风险去换性能，典型手段包括自动向量化（SSE/AVX）、跨函数内联、预取指令插入、热路径特殊调度。这些在图像处理、矩阵运算、音视频编码中确实有效，但代价明确：
- 编译时间显著增加（尤其模板-heavy 的 C++ 项目）
- 代码体积膨胀，可能触发 I-cache miss，反而拖慢小函数高频调用场景
- 某些优化（如循环向量化）依赖数据对齐，若内存分配不满足
alignas(32)，运行时可能崩溃或结果错误 - 浮点运算顺序变更，
(a + b) + c和a + (b + c)可能不再等价，影响单元测试通过率
如果你真要上 -O3，务必配合 -ffp-contract=fast（启用融合乘加）和 -march=native（否则向量化可能不生效），但也要同步开启 -fsanitize=undefined 跑回归测试——因为 -O3 会把原本被 -O0 掩盖的未定义行为暴露出来。
最易被忽略的一点：-O2 和 -O3 对调试信息的支持程度差异极大。即使你加了 -g，-O3 下的变量生命周期、调用栈还原、行号映射都可能失真。线上 core dump 分析若依赖符号表，-O3 会让问题定位成本翻倍。
