gdb 的核心是“遇问题才真正开始用”，需编译时加 -g 和 -o0，断点要设在可执行语句且避免优化干扰，多线程调试需手动控制线程行为。
gdb 不是“学完就能用”，而是“遇到问题才真正开始用”——它不帮你写代码，但能让你看清代码到底在干什么。
怎么启动 gdb 并加载可执行文件
关键不是“怎么进 gdb”，而是“为什么进不去”或“进去后没符号”。常见错误是直接 gdb ./myapp 却发现 print var 报错 No symbol "var" in current context，这几乎 100% 是编译时没加 -g。
- 必须用
g++ -g -O0 myapp.cpp -o myapp编译（-O0防止优化导致变量被删/重排） - 如果程序带参数，别在 gdb 外传：用
gdb ./myapp启动后，再用run --input data.txt - core dump 文件要配合原二进制：
gdb ./myapp core.1234，否则堆栈全是问号
断点设在哪、什么时候生效
断点不是越多越好，设错位置反而浪费时间。比如在内联函数里下断，或者对已优化掉的函数名下断，gdb 会静默忽略，还假装停住了。
- 函数入口断点：用
break main或break MyClass::doWork—— 注意类名和作用域符不能少 - 某行断点：
break myapp.cpp:42，但前提是该行有可执行语句（空行、注释、声明都不行） - 条件断点慎用：
break vector.h:123 if i == 5可能因内联或优化失效；优先用watch监视变量变化 - 临时断点只触发一次：
tbreak，适合确认某段逻辑是否真走到
查看变量值总显示 <optimized out></optimized>
这不是 gdb 的 bug，是编译器在告诉你：“这段代码我重写了，你看到的变量名已经不存在了”。哪怕加了 -g，只要开了 -O1 及以上，就大概率中招。
立即学习“C++免费学习笔记（深入）”；
- 最可靠解法：重新编译，明确指定
-O0 -g - 临时绕过：用
info registers看寄存器，或x/4xw $rbp-8手动查栈帧（需懂汇编基础） -
print某指针时显示地址但内容为空？先print *ptr解引用，再确认 ptr 是否为nullptr - STL 容器（如
std::vector）变量默认只显示 size/capacity，要展开得用print v._M_impl._M_start（GCC libstdc++ 内部字段），不同标准库实现字段名不同
调试多线程时为什么停不住、切不对线程
默认情况下，gdb 只在主线程中断，其他线程继续跑，你看到的堆栈可能瞬间就变了。更糟的是，next 或 step 可能跨线程跳转，根本不是你想要的逻辑流。
- 启动时加
--ex "set follow-fork-mode child"跟子进程，多线程程序通常需要这个 - 查看线程列表：
info threads，当前线程前有*；切换用thread 2 - 让所有线程都停在断点：
set scheduler-locking on（慎用，可能掩盖竞态） - 想只在某线程下断点：
break myfunc thread 3，避免干扰其他线程执行路径
真实调试里，最难的不是命令记不全，而是分不清“程序没按你想的走”，还是“你根本没看清它实际怎么走”。gdb 显示的每一行汇编、每一个寄存器值，都是证据，不是装饰。
