pdb 是需主动介入、分步观察的交互式调试器，推荐用 breakpoint()、python -m pdb 或 post_mortem 启动，核心命令为 n/s/c/p/l，需避开循环盲目 n、谨慎改变量、善用 until 和条件断点。
Python 的 pdb 不是用来“加完断点就 run”的调试工具，而是需要主动介入、分步观察、精准控制的交互式调试器。用对了，它比 IDE 的图形化调试更轻量、更直接；用错了，容易卡在循环里、错过关键状态，甚至误改变量。
启动 pdb 的合理时机
别等程序崩了才想起 pdb —— 那时可能已丢失上下文。推荐三种启动方式：
-
代码中嵌入
import pdb; pdb.set_trace()：最常用，适合定位某段逻辑异常，Python 3.7+ 可简写为breakpoint()（自动读取PYTHONBREAKPOINT环境变量，方便统一关闭） -
命令行直接启动：
python -m pdb script.py：适合想从头跟踪执行流，或脚本一运行就出错但没加断点的情况 -
在异常后进入：
python -c "import sys, pdb; pdb.post_mortem(sys.last_traceback)"：仅限交互式环境（如 IPython
），用于事后分析未捕获异常
核心命令要精用，不是全记
日常调试靠 5 个命令就够覆盖 90% 场景，不用死背全部：
-
n（next）：执行当前行，不进入函数内部 —— 适合快速跳过确定无问题的调用 -
s（step）：进入函数内部 —— 当怀疑某个函数逻辑有问题时用 -
c（continue）：继续运行直到下一个断点或结束 —— 别在循环里盲目按 c，容易跳过关键迭代 -
p：打印变量值（支持表达式，如p len(my_list)或p obj.attr） -
l（list）：显示当前代码上下文（默认 11 行），配合l 20,30可指定行范围，避免迷失位置
避开常见陷阱
很多“pdb 不好用”其实是操作习惯问题：
-
别在循环体第一行反复
n：容易漏看某次迭代的异常状态。改用until 35（运行到第 35 行再停）或临时加条件断点 -
pp比p更适合复杂结构：比如pp locals()或pp my_dict，会自动缩进、换行，看清嵌套内容 -
修改变量要谨慎：在 pdb 中执行
my_var = new_value确实能改，但可能掩盖真实 bug。改完记得用p my_var确认，并思考“为什么这里需要手动修正？” -
退出前用
q，别用Ctrl+C：后者可能中断异常处理逻辑，导致后续调试信息丢失
进阶技巧提升效率
小技巧让调试事半功倍：
-
条件断点：在 pdb 中执行
b 42, i == 5，表示“第 42 行，仅当i等于 5 时中断”，避免手动过滤无关迭代 -
临时执行任意语句：直接输入
print("debug:", x)或import json; print(json.dumps(data, indent=2))，无需改源码 -
用
h查命令，h查具体帮助：比如h until，比翻文档快得多 -
结合
pprint和pp：在 pdb 启动前加import pprint; pp = pprint.pprint，之后就能用pp my_obj获得更清晰输出
