调试递归必须用step而非next，step逐层进入函数体观察参数与栈帧变化；用bt查看调用栈确认层级与状态；在边界条件设断点提升效率；回溯时用print验证head->next->next和head->next赋值是否正确。
用 step 进入递归调用，别用 next
递归函数调试最常踩的坑，就是误用 next。它遇到函数调用直接“跳过”，根本看不到递归展开过程。比如调试 reverseList 时，next 会把 reverseList(head->next) 当成黑盒一步执行完，你完全看不到栈帧怎么一层层压上去的。
必须用 step（或简写 s）：它会在每次递归调用处停下，进入下一层函数体，让你亲眼看到当前参数、局部变量、返回地址的变化。
-
step遇到函数调用就进，适合观察递归“深入”过程 -
next遇到函数调用就执行完再停，只适合跳过不关心的辅助函数 - 如果已经卡在某层递归里，想快速退出到上一层，用
finish，它会运行完当前函数并停在调用点
用 bt 看清调用栈深度和每一层状态
递归的本质是调用栈不断增长。光看代码行号没用，得实时确认自己在哪一层、参数是什么、上一层是谁调的。这时候 bt（backtrace）是唯一可靠手段。
每执行一次 step 进入新递归，立刻敲 bt，你会看到类似：
#0 reverseList (head=0x55555556b2a0) at list.c:12 #1 0x00005555555551a9 in reverseList (head=0x55555556b280) at list.c:12 #2 0x00005555555551a9 in reverseList (head=0x55555556b260) at list.c:12 #3 0x000055555555517c in main () at list.c:35
这说明已进入第 3 层递归（从 #0 开始数），每层 head 地址都不同——这就是链表节点在栈上的真实映射。
-
bt显示的是当前执行点的完整调用路径，不是静态代码结构 - 配合
frame n（如f 1）可切换到任意一层栈帧，再用info args和info locals查具体值 - 递归越深，
bt输出越长；若卡死，先bt看是否无限递归（比如忘记判head == NULL）
在递归边界打断点，避免手动 step 到崩溃
手动 step 一路走到递归终止条件太累，还容易漏掉关键帧。更稳的做法是在边界条件处设断点，比如 reverseList 的第一行：
if (head == NULL || head->next == NULL) return head;
直接 break list.c:8（假设这是 if 行），然后 continue。GDB 会一口气跑到最后一层递归入口，这时再用 step 开始回溯，效率高得多。
- 递归函数的“底”通常只有 1–2 行，断点打在这里最省力
- 别在
return语句后设断点——GDB 可能因优化跳过，优先选判断逻辑所在行 - 如果用了
-Og编译，断点位置和源码基本对齐；若用-O2，bt可能不准，step行为也会异常
回溯阶段重点观察指针赋值和 next 断开操作
递归反转真正的“翻转动作”不在深入过程，而在层层返回时的两行核心代码：
head->next->next = head; head->next = NULL;
这两句必须在每一层返回时逐行验证。用 step 执行完第一行后，立刻 print head->next->next 和 print head，确认指针确实反向了；执行第二行后，再 print head->next，确保它真变 NULL，否则会形成环。
- 不要依赖肉眼读代码逻辑，要靠
print实时验证每个指针的值 - 常见错误是漏掉
head->next = NULL，导致链表成环，后续遍历时死循环 - 如果某层
head->next是NULL，head->next->next就会触发段错误——bt会立刻暴露这一层是“不该被调用”的非法入口
head）和上一层的同名变量完全无关。每次 step 进入，都是一个全新世界。
