gdb调试必须使用带-g选项编译的可执行文件，否则无法映射源码；break支持函数名、文件行号、成员函数全限定名等定位方式；run启动程序，next不进函数，step进入函数；backtrace查看调用栈，frame切换栈帧，print查看变量；关闭编译优化（-O0）是确保调试准确的前提。
gdb 启动时必须带可执行文件，不能只写源码名
直接运行 gdb 不加参数会进入空调试环境，无法设置断点或运行；必须指定已编译且含调试信息的可执行文件，比如 gdb ./a.out。若用 g++ 编译，务必加 -g 选项，否则 gdb 无法映射源码行号、变量名或查看局部作用域：
g++ -g -o main main.cpp。漏掉
-g 是最常见导致“断点打在汇编行”“print x 显示 Cannot access memory”的原因。
设置断点用 break，但位置写法影响命中效果
break 支持多种定位方式，选错会导致断点不触发或停在意外位置：
-
break main：停在main函数第一行（推荐用于入口检查） -
break main.cpp:12：停在main.cpp第 12 行（需确保该行有可执行语句，空行或注释行无效） -
break ClassName::methodName：C++ 成员函数需写全限定名，例如break Vector::push_back -
break *0x401234：按地址设断点（极少用，仅用于无符号信息或 inline 函数调试）
断点设完后用 info breakpoints 查看编号和状态；用 disable 1 或 delete 1 管理，避免多断点干扰单步流程。
运行与单步用 run/next/step，区别直接影响调试效率
这三个命令行为差异明显，误用会导致跳过关键逻辑或陷入系统库：
立即学习“C++免费学习笔记（深入）”；
-
run（或简写r）：启动程序，支持传参，如run arg1 "arg two" -
next（n）：逐行执行，**不进入函数体**，把函数当黑盒；适合快速跳过标准库调用 -
step（s）：逐行执行，**遇到函数就进入其第一行**；C++ 中对重载函数或模板实例容易卡在未知头文件里，此时可先finish退出当前函数
特别注意：对内联函数（inline）、std::vector::size() 这类 trivial getter，step 可能直接跳到汇编或报 “No source file”的错误——这不是 bug，是编译器优化+调试信息缺失的正常表现。
查看堆栈用 backtrace，但要结合 frame 和 print 定位真实问题
backtrace（bt）只显示调用链，真正定位崩溃原因得往下挖：
-
bt：默认显示全部帧，太长时可用bt 5只看最近 5 层 -
frame 2：切换到第 2 帧（从 0 开始），让后续print、list针对该栈帧上下文生效 -
print x或p this->data_[i]：打印变量或表达式；C++ 中访问成员需显式写this->，尤其在模板类中 -
list（l）：显示当前帧所在源码，默认 10 行；list 20,30可指定范围
如果 bt 显示大量 ?? 或地址（如 #3 0x00007ffff7b8a1a0 in ?? ()），说明对应共享库没装 debuginfo 包（如 Ubuntu 的 libstdc++6-12-dbg），此时只能靠源码逻辑推理，无法查看 STL 内部变量。
-g，若同时用了 -O2，gdb 也可能显示变量值为 -O0）比学多少 gdb 命令都管用。 
