调试时变量“消失”或断点不触发，大概率是优化导致的：-O0禁用所有优化，确保源码与汇编一一对应；-O1及以上会将变量存入寄存器、删除死代码、内联函数，破坏调试映射；-O0配合-g才是可靠调试基线，-Og虽兼顾调试但仍有行为偏差风险。
调试时变量“消失”或断点不触发，大概率是优化在作怪
因为 -O0 禁用所有重排、内联、寄存器替换类优化，源码和生成的汇编/机器码基本一一对应。一旦启用 -O1 及以上，编译器会把局部变量直接塞进寄存器、删掉未使用的计算、合并重复表达式、甚至把整个函数内联展开——你设的断点可能落在被优化掉的代码上，GDB 也找不到你声明的变量。
-O0 和 -Og 都能调试，但适用场景不同
-O0 是最保守的选择：它不牺牲任何调试友好性，变量生命周期、控制流走向、函数边界都严格按源码保留。而 -Og 虽然也以调试为优先，但它仍会启用部分不影响单步执行的优化（比如常量传播、死代码消除），在某些复杂逻辑中仍可能导致行为偏差。如果你要确认某段逻辑是否真如所写那样执行，-O0 才是唯一可靠基线。
-
-O0：适合逐行验证逻辑、定位崩溃位置、观察变量实时变化 -
-Og：仅适用于已知代码稳定、想略提速编译+保留基本调试能力的开发中期 - 两者都必须搭配
-g（或-g3）才能生成完整调试信息
为什么 -O2 -g 经常让人误以为“GDB 坏了”
常见现象包括：print var 显示“Cannot access memory at address …”，step 跳过整行，next 行为不符合预期。这不是 GDB 的问题，而是 -O2 把变量生命周期压缩到几条指令内，或把循环展开后打乱了源码行号映射。即使加了 -g，调试信息也只能描述“优化后的结构”，而非原始语义。
- 函数内联后，
bt不再显示中间调用栈 - 循环被展开或向量化后，单步会跳过大量逻辑
- 条件分支被预测合并，
if块可能根本没生成对应指令
反汇编和源码对照必须用 -O0
如果你想用 objdump -d 或 IDE 内置反汇编窗口看某行 C 代码对应哪几条汇编，-O0 是硬性前提。其他优化级别下，一条 for 循环可能对应二十多条无规律跳转指令，且中间穿插着寄存器重命名和指令调度痕迹，根本无法与源码对齐。
- 命令示例：
gcc -O0 -g main.c -o main && objdump -S main - 注意：
-S生成 .s 文件是编译阶段输出，仍受优化影响；只有-O0下的-S才真正反映源码结构 - Code::Blocks / VS Code + GDB 插件中查看汇编，同样依赖
-O0编译结果
-g 就能调”，而是“加了 -g 且没被优化破坏，才能调”。-O0 是唯一不引入额外干扰的起点。 
