断点管理：调试的基石

调试这件事，说白了就是让程序在关键时刻停下来，让你看看它到底在干什么。而断点，就是我们喊停的那只手。

我个人习惯，在开始调试之前，先把断点规划好。就像打仗前要看地图一样，你得知道要在哪些关键路口设卡。今天我们就聊聊断点的那些事儿——怎么设、怎么管、怎么用才顺手。

设置断点：最基础的操作

设置断点，GDB 里最常用的命令就是 break，简写 b。你可以按函数名、行号、文件名+行号来设。

(gdb) break main          # 在 main 函数入口停
(gdb) break 42            # 在当前文件的第 42 行停
(gdb) break foo.c:128     # 在 foo.c 的第 128 行停
(gdb) break my_function   # 在 my_function 入口停

嗯，这里要注意：如果你有多个同名函数，GDB 会问你要停哪一个。我遇到过几次这种情况，后来就养成了习惯——尽量用文件名+行号，避免歧义。

条件断点：只在需要的时候停

有时候你不想每次都停，只想在某个条件成立时才停。比如循环 1000 次，你只关心第 500 次的情况。这时候条件断点就派上用场了。

(gdb) break 42 if i == 500
(gdb) break my_function if x > 0 && y < 100

我曾经调试过一个内存泄漏问题，只在分配大小超过 1MB 时才停。用条件断点，省去了大量无用的中断，效率提升很明显。

临时断点：用完即走

临时断点，就是那种只用一次、自动删除的断点。命令是 tbreak。

(gdb) tbreak 88
(gdb) tbreak my_function

我个人的习惯是：当我想确认某个路径是否被执行到，但又不想长期保留断点时，就用 tbreak。它停一次就自动消失，省得后面还要手动清理。

断点列表：看看你设了哪些

断点设多了，难免会忘。用 info breakpoints 或 info b 可以列出所有断点。

(gdb) info breakpoints
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x4004e0  main
2       breakpoint     keep y   0x400520  foo.c:42
3       breakpoint     keep n   0x400560  bar.c:128

这张表里，Num 是断点编号，Enb 表示是否启用（y/n），What 是断点位置。我个人习惯每次调试前先跑一遍 info b，确认断点状态，避免漏停或错停。

禁用/启用断点：临时开关

有时候你不想删除断点，只是暂时不想让它生效。用 disable 和 enable 来控制。

(gdb) disable 2          # 禁用编号为 2 的断点
(gdb) enable 2           # 启用编号为 2 的断点
(gdb) disable            # 禁用所有断点
(gdb) enable             # 启用所有断点

我曾经调试一个复杂的多线程程序，有十几个断点。为了定位一个特定场景，我先把所有断点禁用，然后逐个启用，配合条件断点，很快就找到了问题。这种「逐个排除」的思路，在调试中很实用。

删除断点：彻底清除

断点不用了，就删掉。用 delete 或 d。

(gdb) delete 2           # 删除编号为 2 的断点
(gdb) delete             # 删除所有断点

知识体系一览

下面这张图，帮你理清断点管理的核心逻辑：

实战建议

说了这么多，总结几条我自己的经验：

• 先规划，再设断点。 别一上来就到处设，想清楚你要观察什么。
• 条件断点优先。 能加条件就别设普通断点，减少中断次数。
• 临时断点用于「探路」。 不确定某个路径是否执行时，用 tbreak 最合适。
• 定期清理断点。 调试完记得 delete，否则下次调试可能被旧断点干扰。
• 善用 info b。 每次调试前看一眼，心里有数。

断点管理看似简单，但用好了，调试效率能翻倍。你想想看，如果每次都要手动跳过几百次循环，那得多浪费时间？

好了，断点管理就聊到这儿。记住这些命令和技巧，下次调试时试试看，你会发现世界清静了很多。