-O2 -g 是正确组合，因 -g 生成的调试信息不依赖优化等级，GCC 支持在 -O2 下输出完整 DWARF 符号供 GDB 还原源码结构，虽部分变量不可见或步进异常，但兼顾性能与基本调试能力。
-O2 和 -g 可以共存，-Og 是独立选项，不是 -O2 的替代品；直接写 -O2 -g 即可，无需替换或取舍。
为什么 -O2 -g 是正确组合，而不是 -Og
-Og 是专为调试设计的优化级别：它启用部分 -O1 级优化（如死代码消除），但刻意避免影响调试体验的操作（如内联、寄存器变量重用、栈帧省略）。而 -O2 会做更激进的优化，包括函数内联、循环展开、常量传播等——这些会改变源码与汇编的对应关系，导致 GDB 中单步跳转异常、变量显示为 <optimized out></optimized>。
但关键点在于：-g 生成的调试信息本身不依赖优化等级。GCC 支持在 -O2 下依然输出完整 DWARF 调试符号，GDB 能据此还原变量名、行号、类型等——只是某些优化后变量确实无法被观测。
- 要保留调试能力，必须加
-g（或-ggdb） - 要获得生产级性能，应选
-O2（而非-Og） -
-Og是“调试优先”的折中，不是“-O2+-g”的等价替代
-O2 -g 下哪些调试行为会失效
即使加了 -g，-O2 的优化仍会导致以下常见现象：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- GDB 中
print var显示<optimized out></optimized>：该变量被提升到寄存器、被常量折叠、或生命周期被缩短 -
step跳过某行：因为该行被内联或优化掉（例如空构造函数、返回常量的 getter） -
bt显示不完整调用栈：尾调用优化或函数被完全内联 - 局部变量在作用域外仍“可见”：优化重用了栈空间，GDB 误读残留值
这不是 -g 失效，而是优化改变了程序执行模型——调试信息描述的是源码结构，不是运行时状态。
实际编译命令怎么写才可靠
最常用且兼容性最好的写法是：
g++ -O2 -g -Wall -std=c++17 main.cpp -o main
注意顺序无关紧要，GCC 按参数语义处理，不是按位置覆盖。但需避开几个典型错误：
- 不要写
-O2 -Og：后者会覆盖前者，最终等效于-Og - 不要漏掉
-g——-O2默认不带调试信息 - 避免
-flto（链接时优化）与-g混用：LTO 会合并符号，大幅削弱调试体验，除非你明确需要并配置了-grecord-gcc-switches - 若用 CMake，确保
CMAKE_BUILD_TYPE不是Release（默认无-g），推荐设为RelWithDebInfo，它自动加-O2 -g
什么时候该考虑 -Og 而不是 -O2 -g
-Og 的真实定位是：开发阶段快速验证逻辑正确性，同时比 -O0 略快一点。它适合以下场景：
- 你正在调试一个因内联/重排导致行为异常的 bug，需要稳定、可预测的执行流
- 项目启动慢，想加速单元测试执行但又不能牺牲断点精度
- 嵌入式目标 RAM 极其紧张，
-O2生成的代码太大，而-Og在体积和速度间有更好平衡
但只要你的调试工具链是现代 GDB（≥8.0）+ DWARF5，且接受部分变量不可见，-O2 -g 就是 release 前验证逻辑 + 性能的黄金组合——别被 <optimized out></optimized> 吓退，它提醒你：这段代码已经被编译器认定“足够简单”，不必深究。
