调试这件事，说难是真难。代码写完了编译通过，一运行就崩，或者结果死活不对，print大法打了几十个日志还是找不到问题在哪。这时候如果还只会用printf碰运气，效率实在太低了。GDB作为Linux/Unix环境下最经典的调试器，是每个C/C++开发者绕不开的必修课。这篇文章我不会给你堆砌命令手册，而是从实际调试场景出发，把GDB从入门到进阶的完整路径捋一遍，包含我在真实项目中踩过的坑和沉淀下来的技巧，希望能帮你把调试效率真正提上来。
如果你是从零开始的新手，读完这篇文章你能掌握GDB最核心的用法，足以应对日常开发中的绝大多数问题。如果你已经有了一些GDB基础，后面关于watchpoint、core dump分析、多线程调试的部分，大概率能帮你打开新思路。文章里所有命令我都会讲清楚“为什么这么做”的道理，而不只是告诉你怎么敲。
1. 为什么需要GDB：从一次线上崩溃说起
1.1 一个真实的“诡异崩溃”场景
有一次我在调试一个网络服务程序，表现为运行几小时后不定期崩溃，日志里只有一行“Segmentation fault”，没有任何其他线索。用printf在关键路径上打点，打印了几十行日志，跑了两天终于复现，发现崩溃点在一个看起来人畜无害的内存拷贝函数上。但为什么拷贝会崩？光看代码根本看不出来。后来用GDB加载崩溃时生成的core文件，一条bt命令直接把调用栈完整打印出来，问题根源一目了然——是上层某个模块提前释放了缓冲区。那次经历让我彻底明白：printf只能告诉你“程序走到了哪”，GDB能告诉你“程序为什么走到了这一步”。
这个案例不是个例。在真实项目的开发与维护中，段错误、内存越界、逻辑错乱、死锁、多线程竞争这一类问题，几乎都无法靠肉眼看代码解决。GDB的价值就在于，它能让你在程序运行的任意时刻“冻结”现场，检查内存、变量、调用栈、寄存器，甚至改变程序的运行轨迹。
1.2 GDB的核心能力与适用场景
GDB能做的事情，远不止“下断点、看变量”这么简单。我把它在实际工作中的能力归为六类：
- 断点与运行控制：在任意函数、行号、地址下断点，控制程序暂停、单步、继续运行。
- 变量与内存检查：查看变量的值、类型、地址，直接读取指定内存区域的内容，甚至可以调用函数。
- 调用栈分析：程序告诉你崩溃时间、崩溃位置之后，你第一时间要看的是“它从哪来”，
backtrace就是干这个的。 - 动态修改数据：调试过程中直接修改变量的值，跳过某段逻辑，用“伪造数据”验证后续流程。
- 崩溃现场复现：加载core dump文件，重现程序崩溃时的状态，这是定位偶现崩溃的王牌手段。
- 多线程与多进程调试：切换线程、查看线程栈、定位死锁与数据竞争。
适用场景也远不止C/C++。只要你的工具链生成的是ELF格式的二进制，并且包含调试信息，GDB都能调试。写Rust用了debug build，崩溃时一样可以挂GDB；Linux内核驱动开发有kgdb；嵌入式开发有gdb-server远程调试。可以说，掌握GDB就是掌握了一套通用的调试方法论，换个语言、换个平台，核心思路全都用得上。
1.3 和IDE调试器的关系
很多同学在IDE里点击“运行”按钮旁边的小虫子图标就能调试，觉得没必要单独学GDB。我的看法是：两者根本不是替代关系，而是互补关系。IDE调试器（不管是什么IDE）底层其实都是GDB的封装，你点的“Breakpoint”“Step Over”“Watch”，本质上都是在调用GDB的接口。但在服务器上排查问题、分析线上core dump、调试没有图形界面的嵌入式环境时，IDE是无能为力的。我见过太多只会点IDE小虫子的开发，一到生产环境就抓瞎。搞懂GDB命令行，你对调试原理的理解会更深，回头再用IDE反而会感觉更通透。
2. 环境准备与第一个调试会话
2.1 安装GDB与确认版本
绝大多数Linux发行版默认不会装GDB，需要手动安装。在Debian/Ubuntu系上：
sudo apt-get install gdb在RedHat/CentOS系上：
sudo yum install gdb装完后用gdb --version确认一下，不同的GDB版本在某些命令细节上略有差异，但核心功能二十年来基本稳定。我自己常用的是GDB 12以上的版本，新版本对Python脚本支持更好（后面会提到）。
macOS上的情况稍微特殊一点。系统自带的lldb是默认调试器，但通过brew install gdb也能装GDB，只是首次使用需要签名授权，步骤略麻烦。如果你的主力开发环境是macOS，我建议直接用lldb，命令风格和GDB高度相似，大部分GDB技巧迁移过去完全无障碍。
2.2 编译参数：调试信息是怎么生效的
调试的第一步不是打开GDB，而是在编译时加上-g参数。
gcc -g -O0 -Wall -o myapp myapp.c-g让编译器在生成的目标文件中插入DWARF调试信息，包括源码行号、变量名、类型、函数签名等。有了这些信息，GDB才能把二进制指令映射回源码，让你在源码级别下断点、看变量。
在真实项目中，-O0（不优化）和-g配合是最佳调试组合。为什么？因为优化器会重排指令、复用寄存器、内联函数、消除临时变量，导致源码和机器码的对应关系变得面目全非，你会在GDB里看到变量值变成<optimized out>，单步执行乱跳。这是无数新手第一次调试时最困惑的问题。
注意：线上排查问题时，如果二进制是用
-O2编译的，仍然可以用-g信息调试，但很多变量已无法查看。编译时同步保留一份带-g的版本，会省很多事。
还有一种常见做法是-g3，比-g多了宏定义信息，调试带宏的代码时会很有用。我一般习惯用-g3 -O0做开发调试，发布时用-g -O2并配合strip把符号表去掉以减小体积。
2.3 启动GDB的三种姿势
根据你要调试的对象，GDB有三种启动方式：
- 直接调试程序：
gdb ./myapp，此时程序还没有运行，你需要用run命令启动。 - 附加到运行中的进程：
gdb -p 1234或gdb ./myapp 1234，这里的1234是目标进程的PID。这种方式非常适合调试服务器类的长期运行程序，发现问题时再挂上去看状态。 - 分析core dump：
gdb ./myapp core，程序崩溃后留下的core文件就是“尸体”，GDB配合调试信息可以还原案发现场。
第三种方式值得多说一句。要生成core文件，系统需要允许core dump，用ulimit -c unlimited打开限制。很多服务部署脚本都会默认关闭core，排查崩溃问题时记得先看这个。
2.4 跑通第一个最小调试流程
我们快速跑通一个最基础的流程。假设有这样一个程序：
#include <stdio.h> void print_sum(int a, int b) { int sum = a + b; printf("sum = %d\n", sum); } int main() { int x = 10; for (int i = 0; i < 5; i++) { print_sum(x, i); } return 0; }编译后启动GDB：
gcc -g -O0 -Wall -o demo demo.c gdb ./demo在GDB交互界面里依次输入：
break main # 在main函数入口下断点 run # 运行程序，停在main入口 next # 单步执行，不进入函数 step # 单步执行，进入函数 print x # 查看x变量的值 continue # 继续运行到下一个断点或程序结束 quit # 退出整个过程应该不到一分钟。你可能会注意到，next和step的区别在于：next执行当前行代码但不会进入被调函数，step则进入函数内部逐行执行。理解这两者的区别，是控制调试节奏的基础。
3. 核心命令实操：断点、运行控制与变量检查
3.1 断点管理的全套操作
断点是调试的基石。除了最基本的break <位置>，断点的管理还涉及暂定、启用、批量删除等操作。下面是我在实际使用中高频用到的一组：
| 操作 | 命令示例 | 说明 |
|---|---|---|
| 在函数入口下断点 | break print_sum | 函数名即可，不要求写出完整签名 |
| 在指定行号下断点 | break demo.c:15 | 文件名:行号，多文件项目必备 |
| 查看所有断点 | info breakpoints | 会显示断点编号、位置、命中次数 |
| 暂停某个断点 | disable 2 | 编号2的断点先留着但不生效 |
| 恢复断点 | enable 2 | 再次启用 |
| 删除断点 | delete 1 | 彻底删除编号1的断点 |
| 按条件下断点 | break demo.c:15 if i == 3 | 只有i等于3时才停下 |
break <位置> if <条件>这个语法是效率神器。循环要跑十万次，你只想看i等于99999时的情况，加个条件断点，程序会自动跑到你想看的那次迭代才停，完全不用手动单步按到手抽筋。
断点还有一个“一次性”属性：某些场景下你只希望断点生效一次，命中之后就自动删除。在GDB里用tbreak设定临时断点，调试复杂逻辑时可以少删好多操作。
3.2 运行控制的节奏感
运行控制类命令中，除了前面提到的next和step，还有几个高频实用的：
finish：执行完当前函数并停在返回处。这个命令在“进坑”之后“出坑”特别有用。until <行号>：一直执行到指定的行号。适用于在一个函数内跳到远处的某行，而不是一步步走过去。continue：继续执行到下一个断点或程序正常结束。return：强制当前函数提前返回，可以不返回值，也可以带一个表达式作为返回值。jump <行号>：直接跳转到指定行执行。这个命令比较危险，跳过变量初始化会引发各种奇怪问题，但某些绕过崩溃代码的临时验证场景下很管用。
掌握这些命令的关键是形成节奏感。我调试时的习惯是：先用break在可疑函数入口下断点，用next一行一行走，走到可疑的调用时用step进去，确认不是这个函数的问题后立刻finish退出，避免在无关函数里浪费太多时间。
3.3 变量查看与表达式的花式玩法
print是最基本的变量查看命令，但用法远不止print x这么简单。我常用的变体：
print x # 查看x的值 print &x # 查看x的地址 print x[0] # 查看数组第一个元素 print *ptr # 查看指针指向的内容 print (char*)buf # 把内存按char*类型解释 print func(3) # 在调试时实际调用函数func最后这条print func(3)是把GDB当成解释器用，调试时验证一个函数的返回逻辑非常方便。但要记住，调用函数相当于在你自己的程序里执行了代码，它会改变程序状态。换句话说，它会带来副作用（例如修改全局变量）。别在调试环境里乱调有读写文件、网络请求这类副作用的函数。
display命令可以把变量注册为“常显”，每次程序暂停时自动打印它的值。调试循环体内某个变量如何变化时，display i之后不断next，每次停顿都能看到i的最新值，省去反复敲print的麻烦。
whatis用来查看变量的类型信息，看到whatis ptr的输出，你就知道这个指针到底是int*还是char*。查类型和查值的组合拳是：whatis x+print x，先确认类型再确认值，减少类型混淆导致的误判。
3.4 调用栈：定位问题的第一现场
程序崩溃时你最想知道的第一个问题是：它死在哪条调用链上。backtrace（简写bt）就是回答这个问题的。它会把当前线程的函数调用链从上到下列出来，每一帧都包含函数名、文件、行号和参数信息。
(gdb) bt #0 print_sum (a=10, b=4) at demo.c:4 #1 0x0000000000401153 in main () at demo.c:10看到崩溃点在print_sum，上一层调用来自main的第10行。这个信息量已经足够大。但调用栈的功能不止于此：
frame 1：切换到第1帧（即调用者那一层），局部变量和参数就变成那一层的。info locals：查看当前帧的所有局部变量。info args：查看当前帧的函数参数。
排查问题时我几乎总是一套连招：bt看栈，frame 被怀疑的那一层切换过去，info locals看现场变量。只要崩溃发生在代码逻辑上，这套组合拳90%都能定位出问题的大致区域。
4. 高级调试技巧：从会用到用得巧
4.1 条件断点与断点命令自动化
条件断点在第三章已经提过，这里展开讲两个进阶用法。
第一个是断点命中次数。GDB支持给断点设置忽略次数，让前N次命中自动跳过：
break func ignore 1 1000 # 跳过前1000次命中第二个是断点命令脚本。GDB允许你在断点命中时自动执行一组命令，用commands <断点编号>定义：
break main commands print x continue end每次在main停下后，自动打印x的值并继续运行。这个功能在调试循环中的累计变化时特别好用，相当于在循环体内埋了一个临时“探针”。我调试数值计算程序时，经常用断点命令在每个关键迭代点打印中间量变化曲线，效果和插桩日志类似，但不用改代码重新编译。
深层逻辑是，断点命令本质上是GDB脚本能力的一小部分。GDB支持if、while这些控制流语句，甚至支持引用Python脚本做自定义处理。调试复杂的临时状态时，可以在命令行里写一段几十行的小脚本完成自动分析，这种能力IDE调试器几乎给不到。等GDB基础命令熟练之后，花一个下午把官方文档的“Command Files”章节过一遍，投资回报会非常高。
4.2 watchpoint 数据改变监控
断点基于“执行到某条指令”，watchpoint则基于“某片内存被修改”。它们的定位完全不同：断点是"当程序执行到这里时停"，watchpoint是"当这个变量被改时停"。后者在追踪内存被意外篡改的问题时，几乎是唯一高效的方案。
watch my_var # 当my_var的值发生变化时暂停 watch -l my_var # 监控my_var的地址变化，更精确 rwatch my_var # 当my_var被读取时暂停 awatch my_var # 读写都暂停硬件watchpoint有数量限制（x86上是4个），软件watchpoint则通过单步实现，会拖慢程序执行速度。调试内存越界时我最常用的模式是：先watch被越界的数组最后一个元素，然后continue，程序一旦在越界点停下，bt直接看到是谁改坏了它。
注意watchpoint在函数退出后可能失效，因为栈内存已被回收。想要继续看的话，可以根据变量作用域调整watch的位置。
4.3 内存查看与x命令详解
print只能查看变量的值，直接查看内存字节则要用x命令。它的语法是x/<数量><格式><单位> <地址>。
x/20x buf # 以16进制查看buf地址开始的20个字节 x/10i main # 查看main函数的空格映射（反汇编） x/20d arr # 以10进制查看数组arr的20个元素 x/s ptr # 查看以\0结尾的字符串要把x用出价值，需要建立起“内存即数据”的思维。数组越界、缓冲区溢出这类问题，用print看单个变量往往看不出问题，但是用x把相邻的一片内存全部dump出来，经常能一眼看出数据被覆盖的痕迹。比如某个数组后面的内存区域出现了一串不相关字符串，那基本可以判定有写越界。
x命令和print的差异还在于它可以配合GDB的寄存器名使用。调试汇编级别的问题时，x/10i $pc能直接反汇编当前指令地址附近的机器码，配合info registers查看寄存器状态，是可以把程序执行还原到每一条指令粒度的。
4.4 core dump：崩溃现场复原术
前面提过core dump的生成和GDB加载方式。这里重点讲一套我自己养成的排查流程：
- 复现崩溃：用
ulimit -c unlimited确保能产生core文件。 - 加载core：
gdb ./myapp core，进入交互界面。 - bt：看完整调用栈。这是定位问题的第一手信息。
- frame N：切换到最可疑的那一帧，通常是栈顶附近的几帧。
- info locals / print 变量：检查当时的局部变量与参数。
- 分析内存：对涉及指针的变量，用
x查看指针指向的内存是否合法。 - 查看线程：如果是崩溃在多线程程序里，
info threads看一下所有线程的状态，找到真正导致崩溃的线程。
core dump文件的一个反直觉点在于：它不是“崩溃瞬间的完整内存快照”，而是内核在进程退出时保存的必要现场信息。理论上你可以在core里找到绝大多数内存内容，但某些被释放的内存可能已被内核丢弃。也就是说，core里能看到的信息是大部分但不是全部。
线上服务通常会设置core文件统一存放目录和命名规则，比如/var/crash/core-%e-%p-%t这种。运维体系的同学如果没有对core做集中收集，排查问题时建议先在部署脚本里把core文件保留策略配好。在没有core可用的场景下，另一条路是给程序挂上崩溃时的信号处理器（如signal(SIGSEGV, handler)），在handler里做现场转储。但不要过度依赖handler，handler里的操作本身也可能不安全，GDB加载core仍然是更干净可靠的方式。
4.5 多线程调试要点
用-p附加到运行中的多线程程序后，info threads会列出所有线程：
(gdb) info threads Id Target Id Frame 1 Thread 0x7f... (LWP 12345) 0x... * 2 Thread 0x7f... (LWP 12346) func_a ()带*的是当前线程。切换线程用thread 2，每个线程有自己的调用栈和局部变量空间，所以切换后bt看到的是那一个线程的调用链。
调试多线程最痛苦的问题之一是死锁。死锁表现为程序卡住、CPU不动了、日志停更。GDB排查死锁的常用路径是：info threads观察所有线程在哪里卡着，如果多个线程都在pthread_mutex_lock里停住，再用frame切到对应线程的函数调用位置，看它们各自持有什么锁、等待什么锁。
另一个多线程调试利器是set scheduler-locking。默认情况下，next只控制当前线程，其他线程仍在跑。这会导致单步调试时数据被其他线程修改，看到的值不稳定。可以把模式设为on，让单步时只运行当前线程，其他线程冻结，保证观察的确定性。注意这个模式是全局的，调试完记得改回来。
5. 实战复盘：一次数组越界问题的完整定位全过程
5.1 案例背景与现象描述
某内部项目X（一个模拟消息分发模块）在压力测试中偶发段错误，崩溃概率大约在每万次请求一次。代码逻辑简单：从环形缓冲区读数据，解析消息头，把消息体拷贝到输出缓冲区。已经用printf在关键位置打点，但崩溃点不固定，有时在拷贝处，有时在解析函数的返回处。
现象不稳定、崩溃点不集中，这是典型的“内存已经被写坏，但崩溃发生在后续某个使用坏内存的时间点”。此时数据流已经污染了一段时间，当务之急不是看崩溃那一刻的指令，而是找出“谁在什么时候把内存写坏了”。
5.2 通过core dump先获取现场证据
最先做的是获取崩溃现场。修改启动脚本，打开ulimit -c unlimited，把core文件保存下来。加载core：
gdb ./msgdispatch core回车进入GDB后，先看栈：
(gdb) bt #0 parse_message (data=0x7fff... ) at parser.c:88 #1 0x... in dispatch_one (msg=0x...) at dispatch.c:45 #2 0x... in worker_thread (arg=0x...) at worker.c:120崩溃在parse_message的第88行，看起来是一个memcpy调用。但这个位置在第0帧意味着崩溃只是“果”，“因”可能在更早的执行路径。我立刻检查了parse_message的参数地址：
(gdb) frame 0 (gdb) info args data = 0x7f... (gdb) x/20x data看到data指针指向的消息头数据一切正常。于是切换caller帧，看dispatch_one传给parse_message的消息缓冲区地址，再用x查看该地址周围的内存布局，果然发现缓冲区头部之前的8个字节出现了预期外的数据模式。
5.3 复现实验：改用watchpoint抓“写入者”
core给出的是污染后的结果，还不足以完全确定是谁写坏了字节。为此我做了一次在受控条件复现，在缓冲区头部之前的位置下watch：
watch -l *(long*)(buffer - 8) continue程序跑了一会儿后在某个任务处理线程里停下，bt一看，是在一个日志格式化函数里对snprintf的缓冲区大小计算错误，导致多写了一个字符串到内存里，偏移量恰好越过了边界8字节，踩到了消息缓冲区头部的保留区。因为这个保留区用于存放消息长度，被改坏后解析流程出现错乱，后续随机的崩溃点就都解释通了。
修复方案是对齐日志缓冲区的长度计算，给snprintf预留足够的尾字节空间。从发现问题到定位真凶，用watchpoint只花了两轮调试，比打日志快得不是一点半点。
5.4 复盘：这套方法论怎么迁移到其他问题
这次调试的核心思路可以总结为三步：
- 第一步：用core dump固定现场，把崩溃那一刻的调用栈、参数、内存全记录下来。这一步解决“信息不足”的问题。
- 第二步：区分“结果”和“原因”，看到崩溃点不要立刻下结论，往上翻调用栈，找数据流中更靠前的污染点。
- 第三步：用watchpoint盯住可疑内存，让程序在“被篡改”那一刻把“案犯”抓个正着。这一步解决“溯源”的问题。
这个流程换到任何内存型问题都适用。无论是数组越界、use-after-free还是缓冲区溢出，思路都是同一套。如果你被困在“崩溃点不固定”的泥潭里，解决方案很大概率不是加更多日志，而是用watchpoint盯住核心数据结构的落址。
6. 常见问题排查与效率提升技巧
6.1 调试信息缺失：识别与应对
走进GDB，输入break main，报错“No symbol table is loaded”或者list看不到源码，翻译过来的意思就是：目标文件里没有调试信息。原因基本只有一个：编译时没加-g。
排查方法是用file命令查看可执行文件的符号状态：
file ./myapp如果输出里有not stripped和with debug_info字样，说明调试信息在。如果显示stripped，说明符号表已经被剥离。如果没有debug_info，肯定是编译参数缺了-g。
这种问题在从CI服务器或别人那里获取二进制时最常见。解决的办法是让构建流程默认产出带调试信息的版本，发布时单独再strip一份。哪怕是线上环境，也建议把带-g的副本归档保留，以备排查时使用。
6.2 优化代码调试的困境
编译参数带-O2时，GDB单步跳行、变量显示<optimized out>，这是因为优化器重排了指令并复用了寄存器。处理办法有几条路可以选择：
- 对于难以调试的模块，单独关掉优化：编译这个文件时用
-O0 -g，其他文件保持-O2。这需要在Makefile或CMake里对特定源文件设置不同编译参数。 - 接受优化带来的混乱，用汇编级调试。
layout asm配合layout regs看汇编执行流，照样可以定位问题。 - 用
-fno-omit-frame-pointer保留帧指针，虽然不能还原变量，但调用栈信息会更可靠。
我个人遇到优化代码下的怪异逻辑问题时，会先尝试关掉优化复现。很多在-O0下消失的问题，本质上都是“未定义行为”在不同优化级别下的不同表现。如果你在-O0下复现不了，就要考虑这是优化器导致的问题还是代码里藏了未定义行为。
6.3 多线程调试中的“假死”与竞态
调试多线程时，程序明明跑得好好的，GDB一暂停，恢复运行后程序反而卡住不走了。这在Linux线程模型下非常常见：GDB暂停默认是所有线程同时停（set stop-on-solib-events等参数会影响具体行为），这时某线程可能正处于持有锁的状态。恢复运行后，如果其他线程被调度并等待这个锁，而持有锁的线程又因为你设置的调度锁定卡住了，就出现了循环等待的“假死”。
解决方法是灵活调整scheduler-locking，或者在后端快速用thread apply all bt查看所有线程状态。实际工作中，我的建议是：多线程调试时尽量保持“暂停-观察-立刻全部继续”的节奏，不要长时间让部分线程停在一个依赖其他线程的协作点上。
6.4 交互体验升级：init文件与快捷键
GDB每次启动都要敲一堆重复命令？可以把常用设置写进~/.gdbinit文件。举个例子：
set pagination off set print pretty on set print thread-events on set confirm offpagination off去掉分页提示，输出长栈时不用一直按空格。set print pretty on让结构体打印按字段换行，看着舒服很多。set confirm off去掉各种“真的退出吗？”的确认交互，批量自动化脚本里尤为重要。
~/.gdbinit还支持定义自定义命令。GDB的define命令能封装一组常用操作：
define pshow printf "====================================\n" info locals bt end之后输入pshow就会执行上面这个组合。这个能力让我在调试重复性场景时省下大量重复输入。再进阶一点的玩法是加载Python脚本（python命令），实现自定义的数据格式化和分析逻辑。
6.5 调试效率的三个核心习惯
第一，先搞清楚问题的类型再选工具。是崩溃？异常值？还是逻辑错乱？崩溃用core dump、异常值用watchpoint、逻辑错乱用断点加单步。工具选错了，再熟练的操作也是事倍功半。
第二，保持调试环境与线上环境尽量一致。编译器版本、优化参数、链接库的差异都会导致问题无法复现，复现不了就谈不上定位。我见过同事在本地GCC 9上怎么调都没问题，线上GCC 7一跑就崩，最后发现是未定义行为的优化差异。环境一致性这个坑，早意识到早省心。
第三，善用日志和GDB的互补关系。日志负责宏观记录“程序的大致执行轨迹”，GDB负责微观检查“特定时刻的具体状态”。日志打得太粗看不到细节，太细性能扛不住。我的习惯是：先用日志缩小范围，再用GDB精准取证，两者配合永远比单打独斗高效。
7. 写给新手的最后几句经验
调试这件事，经验积累和工具熟练度同样重要。用GDB越久我越觉得，它本质上是在帮你建立一个“程序执行的心智模型”：变量在内存里怎么排布、函数调用栈如何生长、数据如何在模块间流动。一旦这个模型建立起来，很多问题在动手调试之前你就能先猜出答案，GDB只是用来确认你的猜测。
我自己刚开始学GDB时，对着命令表背了很多，真正用的时候还是手忙脚乱。后来换了思路：遇到问题先想清楚“我需要程序在什么地方停下”“我需要看什么数据”，然后带着目的去查命令。命令是工具，思路才是核心。这个过程里踩过的坑，比如忘了加-g导致符号表加载失败、优化开启导致变量不可见、core文件被系统限制导致崩溃现场丢失，每一个都让我对调试的理解更深了一层。
如果你想拿一个小项目练手，我推荐一个特别好的起点：写一个带数组越界的简单程序，编译后用GDB加载并故意触发崩溃，然后用bt看调用栈、x看内存、watch盯住越界点，整套流程走通一遍，对GDB的理解会比只看文档深刻得多。调试能力没有捷径，但走对这条路，回报率绝对超出你的预期。
