debug与release本质是-g和-o选项的组合：debug用-g -o0 -ddebug保留调试信息且禁用优化，release用-o2 -dndebug启用优化并移除断言。
gcc 编译时 -g 和 -O 选项决定 Debug/Release 本质
Debug 和 Release 不是 GCC 内置的模式开关，而是人为约定的一组编译选项组合。核心差异就两点：-g（是否带调试信息）和 -O 级别（是否开启优化）。其他如 -DNDEBUG、-static 都是衍生行为。
典型组合如下：
- Debug：常用
gcc -g -O0 -DDEBUG—— 保留符号、禁用优化、启用断言 - Release：常用
gcc -O2 -DNDEBUG或gcc -Os -DNDEBUG—— 去掉符号（默认不加-g）、启用优化、屏蔽assert()
注意：-O0 是显式“无优化”，不是“不写 -O”；不写 -O 时 GCC 默认仍是 -O0，但显式写出更可靠，避免被构建系统覆盖。
为什么加了 -g 就能用 gdb 调试，不加就不能
因为 -g 会在 ELF 文件中写入 .debug_* 段（如 .debug_info、.debug_line），这些段把机器指令地址映射回源码文件名、行号、变量名。gdb 读不到这些，就只能显示汇编，无法 list、无法 print var、断点也设不到 C 行上。
验证方法：
- 查 debug 版本：
readelf -S hello_debug | grep debug—— 会看到多个.debug_*段 - 查 release 版本：
readelf -S hello_release | grep debug—— 输出为空 - 体积差异明显：
ls -lh hello_debug hello_release，debug 版通常大 2–10 倍
开启 -O2 后变量显示 怎么办
这是优化导致的直接后果。编译器发现某个变量只用于计算、未被取地址或未在后续逻辑中真正使用，就可能把它存在寄存器里、合并进表达式、甚至整个删掉。gdb 找不到它的内存位置，自然报 <optimized out></optimized>。
这不是 bug，是预期行为。解决方式只有两个：
- 调试阶段切回
-O0（最常用） - 若必须在优化下调试，可对特定变量加
volatile修饰（如volatile int flag = 0;），阻止编译器优化掉它——但仅限诊断，勿滥用到生产逻辑中
另外，-Og（GCC 4.8+）是个折中选项：开启部分不影响调试体验的优化，变量基本可查，但性能提升有限，不推荐用于最终 Release。
Release 版本里 assert() 消失了，怎么确认它真被关掉了
只要定义了 NDEBUG 宏，C 标准库的 assert() 就会展开为空宏，不生成任何代码。GCC 下最常见做法是加 -DNDEBUG 参数。
验证方法：
- 检查预处理结果：
gcc -E -DNDEBUG test.c | grep assert—— 应该看不到assert展开体 - 反汇编看有没有调用：
objdump -d a.out | grep assert—— Release 版本中一般搜不到 - 故意触发 assert 的代码，在 Release 下运行不会 abort，而 Debug 下会立即终止
注意：有些项目自己实现断言宏（如 MY_ASSERT），它们是否生效取决于自身逻辑，和 -DNDEBUG 无关。这类宏需要单独检查定义方式。
真正容易被忽略的是：Debug/Release 差异不仅影响调试，还可能暴露隐藏的未定义行为。比如未初始化变量在 -O0 下偶然“看起来正常”，但 -O2 下被优化重排后突然崩掉——这不是编译器问题，是代码本身有缺陷。所以 Release 测试不可跳过。
