小郑那天在修一个数据处理的bug。
一段代码本地跑没问题，线上跑出来的结果就是不对。他在关键位置插了一排print，把中间变量全打出来：
def process(data):
print("data:", data)
filtered = [x for x in data if x > 0]
print("filtered:", filtered)
result = sum(filtered) / len(filtered)
print("result:", result)
return result
跑了一遍，print的输出看起来都正常。他把print删了，换了个位置又插了一排，再跑一遍。来来回回折腾了十几轮，print加了一堆，代码被打印语句淹没了，bug还是没找到。
他隐约觉得问题出在某个循环的中间状态，但循环跑了几万次，他不可能把每次都打出来。他想“如果能让程序停在某个时刻，我看看当时的变量就好了”，但不知道Python有这个能力。
同事路过看了一眼他满屏的print，说：“你干嘛不用pdb？打个断点，程序停下来，你想看什么变量就看什么变量，想看多少看多少，不用提前猜。”
小郑试了一下，在可疑的地方加了一行breakpoint()，程序果然停住了。他在交互式终端里输入变量名，实时查看当前状态；输入n执行下一行；输入c继续运行。几分钟就定位到了问题——某个循环在特定条件下把一个变量覆盖了，而这个覆盖发生在print语句的下一行，他之前的print根本看不到。
“原来调试可以不是‘猜哪里有问题然后打印’，而是‘停下来直接看’。”
这个区别，就是print和pdb最本质的差异：**print是“预先埋点、事后看输出”，pdb是“现场暂停、实时查看”。**
先看一个最直观的对比
同一个函数，两种调试方式：
def calculate(items):
total = 0
for item in items:
total += item.price * item.quantity
discount = get_discount(total)
final = total * discount
return final
用print调试：
def calculate(items):
total = 0
for item in items:
total += item.price * item.quantity
print("total:", total) # 埋点
discount = get_discount(total)
print("discount:", discount) # 埋点
final = total * discount
print("final:", final) # 埋点
return final
用pdb调试：
def calculate(items):
total = 0
for item in items:
total += item.price * item.quantity
breakpoint() # 停下来
discount = get_discount(total)
final = total * discount
return final
print方式下，你必须提前想好要看什么，把变量名写死在代码里，跑一遍，看输出，然后根据输出决定下一步看什么。如果看错了地方，就得改代码、重跑。
pdb方式下，程序在breakpoint()处暂停，你进入一个交互式终端，可以当场查看任何变量、调用任何函数、执行任何表达式。看完了输入n走下一行，或者输入c继续跑。不需要提前猜，不需要改代码重跑。
用一个生活场景来理解。
print像你在房间里装了几个固定的摄像头。你只能看到摄像头对着的地方。想知道别的地方发生了什么，得重新布线、重新安装、重新录一遍。
pdb像你亲自走进房间。你想看哪里就看哪里，想翻抽屉就翻抽屉，想开柜子就开柜子。看完走出来，房间还是原样。
区别一目了然：一个是被动接收预设的输出，一个是主动探索运行时的状态。
print：简单直接，但视野有限
print调试的优势是零门槛。不需要记任何命令，不需要理解调试器，print(x)就能看到x的值。对于“我就想确认一下这个变量是不是我预期的值”这种简单场景，print完全够用。
def parse_config(path):
with open(path) as f:
content = f.read()
print(repr(content)) # 确认读到了什么
return json.loads(content)
但print的局限也很明显。
第一，你必须提前知道要看什么。 bug往往出在你“没想到要看”的地方。你print了a和b，结果问题出在c上。这时候只能改代码、加print(c)、重跑。
第二，你只能看到“值”，看不到“过程”。 print输出的是某一时刻的快照。如果变量的值是在循环中被逐步修改的，你只能看到最终结果，看不到中间每一步的变化。要看过程，得在循环里加print，然后面对几万行输出。
第三，print会改变程序行为。 在性能敏感的代码里，大量print会拖慢程序，甚至改变时序，让并发bug消失或出现。而且print写进代码后，调试完必须手动删掉，忘了删就会污染生产日志。
第四，print无法交互。 你打印出来的东西是死的。你不能在打印之后说“等等，我再看看另一个变量”，只能重新跑。
pdb：交互式调试，现场探索
pdb是Python标准库自带的调试器。它的核心能力是：在指定位置暂停程序，进入一个交互式命令行，让你实时检查和控制程序的执行。
启动方式有几种：
代码里打断点：
breakpoint() # Python 3.7+，等价于 import pdb; pdb.set_trace()
命令行启动：
python -m pdb script.py
这种方式会在脚本第一行就停下来，你可以设置断点、单步执行。
运行中临时进入：
在程序运行时按Ctrl+C中断，然后输入import pdb; pdb.pm()，可以进入中断时的调用栈。
进入pdb之后，你会看到一个(Pdb)提示符，可以输入命令：
(Pdb) p total # 打印变量
(Pdb) pp items # 美化打印
(Pdb) l # 查看当前位置的代码
(Pdb) n # 执行下一行
(Pdb) s # 进入函数
(Pdb) c # 继续运行
(Pdb) b 42 # 在第42行设断点
(Pdb) w # 查看调用栈
(Pdb) q # 退出
这些命令里最常用的是p（打印变量）、n（下一行）、s（步入）、c（继续）、l（看代码）、w（看调用栈）。
核心区别一：主动探索 vs 被动接收
print是“我猜这里有问题，打印出来看看”。pdb是“我停在这里，把所有相关的东西都看一遍”。
假设你在调试一个列表推导式的结果不对：
result = [transform(x) for x in data if condition(x)]
用print，你可能会写：
print("data:", data)
print("result:", result)
但你不知道是transform的问题、condition的问题、还是data本身的问题。你得一个个加print去排除。
用pdb，你在这一行前面停下来：
breakpoint()
result = [transform(x) for x in data if condition(x)]
然后在(Pdb)里：
(Pdb) p len(data)
(Pdb) p data[:5]
(Pdb) p condition(data[0])
(Pdb) p transform(data[0])
当场就能看到data的内容、condition对第一个元素的返回值、transform对第一个元素的返回值。不需要改代码，不需要重跑。
核心区别二：看到“过程”而不是“快照”
print只能看到某一时刻的值。pdb可以让你在循环中反复停下来，观察变量的变化过程。
def find_bug(items):
total = 0
for i, item in enumerate(items):
total += item.value
if total > 100:
break
return total
用print，你只能打印最终total，或者打印每次循环的total，然后面对一大堆输出。
用pdb，你在循环里设一个条件断点：
(Pdb) b 5, total > 90 # 在第5行，total > 90 时停下来
程序会一直跑，直到total超过90才暂停。你看到的是“出问题之前那一刻”的精确状态，而不是几百行无关输出里翻找。
pdb支持条件断点，这是print完全做不到的。
核心区别三：不侵入代码
print必须写进代码。调试完要删掉。忘了删就会留在生产环境里。
def process(data):
print("debug:", data) # 忘了删，生产环境每次调用都打印
return transform(data)
pdb的breakpoint()虽然也要写进代码，但它有一个关键优势：可以通过环境变量全局禁用。
PYTHONBREAKPOINT=0 python script.py
设置了PYTHONBREAKPOINT=0之后，所有breakpoint()调用都会被忽略，不会暂停。这样即使代码里留了断点，生产环境也不会被卡住。
print没有这种全局开关。你只能靠人工检查、代码审查、或者用linter规则来发现残留的print。
核心区别四：调用栈可见
print只能看到当前作用域的变量。pdb可以让你沿着调用栈往上走，看到每一层函数的局部变量。
(Pdb) w
/home/user/main.py(10)<module>()
-> process(data)
/home/user/service.py(25)process()
-> result = calculate(items)
/home/user/calc.py(8)calculate()
-> discount = get_discount(total)
(Pdb) up # 往上一层
(Pdb) p items # 看上一层的局部变量
bug经常是“这一层的输入不对”，而输入是上一层传进来的。用print，你只能在每一层都加打印；用pdb，你直接up上去看。
坑一：breakpoint() 留在生产代码里
def process(data):
breakpoint() # 调试完忘了删
return transform(data)
如果生产环境没有设置PYTHONBREAKPOINT=0，程序会在这里暂停，等待输入。在后台服务里，这等于挂起。
解决方案：
第一，设置PYTHONBREAKPOINT=0环境变量。 这是生产环境的标配。
第二，用linter规则检查。 很多linter可以配置规则，禁止提交包含breakpoint()或pdb.set_trace()的代码。
第三，用pdb的替代品。 比如pdbpp、ipdb，它们提供了更友好的界面，但同样需要清理断点。
坑二：pdb 里看不到想要的变量
在pdb里输入变量名，如果变量不存在，会报NameError：
(Pdb) p user
*** NameError: name 'user' is not defined
可能是因为你停在了变量定义之前，或者变量在另一个作用域。用l看当前代码，确认停在了哪一行；用w看调用栈，确认当前在哪个函数。
坑三：pdb 的 n 和 s 搞混
n（next）执行下一行，遇到函数调用不进入。s（step）执行下一行，遇到函数调用进入。
result = calculate(data) # 在这一行按 n，直接执行完 calculate
result = calculate(data) # 在这一行按 s，进入 calculate 内部
想深入某个函数看细节，用s；想跳过不关心的函数，用n。搞反了会在不相关的函数里浪费时间。
坑四：pdb 命令和 Python 表达式混淆
在(Pdb)提示符下，输入p x是打印x，输入x是执行表达式x（如果x是一个变量，会打印它的repr）。但有些命令和变量名冲突：
(Pdb) n # 执行下一行，不是打印变量 n
(Pdb) p n # 打印变量 n
如果变量名恰好是n、c、s、l这些命令，要加p前缀才能打印它。
什么时候用 print，什么时候用 pdb？
判断标准：
只需要确认一个值，位置明确，不需要深入探索：用print。简单直接，不需要学命令。
bug 位置不确定，需要现场探索变量和调用栈：用pdb。停下来看，比猜着打印高效得多。
循环里的问题，需要观察中间状态：用pdb的条件断点，比打印几万行输出强。
性能敏感的代码，print 会改变行为：用pdb（虽然也会暂停，但可以精确控制停在哪一次）。
临时脚本、一次性的调试：print够了。pdb的学习成本在简单场景下不划算。
生产环境排查：用日志（logging），不要用print，也不要用pdb。pdb是开发阶段的工具。
pdb 的替代品
pdb是标准库自带的，零依赖，但界面比较简陋。实际开发中，很多人用增强版：
pdbpp：pip install pdbpp，提供彩色输出、更好的代码补全、sticky模式（代码和提示符同屏）。
ipdb：pip install ipdb，基于IPython的调试器，支持IPython的所有魔法命令。
IDE断点：PyCharm、VS Code都有图形化调试器，本质上是pdb的封装，但提供了点击设断点、变量面板、调用栈视图。对于习惯图形界面的开发者，这是最直观的方式。
这些工具的命令和pdb基本兼容，学会pdb之后可以无缝切换。
回到小郑的故事
小郑最终的调试方式是这样的：
def process(data):
filtered = [x for x in data if x > 0]
breakpoint() # 在这里停下来
result = sum(filtered) / len(filtered)
return result
程序暂停后，他在(Pdb)里：
(Pdb) p len(data)
(Pdb) p filtered[:10]
(Pdb) p [x for x in data if x <= 0][:10] # 看看被过滤掉的是什么
他当场发现，filtered里混进了一些本不该通过的数字，问题出在x > 0这个条件上——某个上游函数把字符串传了进来，字符串和整数比较时Python 3直接报错，但那个错误被一个宽泛的except吞掉了，导致部分数据被静默跳过。
如果用print，他得先猜“可能是过滤条件的问题”，然后打印data、打印filtered、对比、再猜下一步。用pdb，他停在那里，两分钟就看到了全貌。
他后来在团队文档里写了一条：“调试先想清楚是‘确认一个值’还是‘探索一个区域’。确认值用print，探索区域用pdb。pdb的breakpoint()生产环境用PYTHONBREAKPOINT=0禁用。条件断点比打印循环输出高效得多。n是下一行，s是进入函数，c是继续，w是看调用栈，p是打印变量。”
这个区分看起来简单，但真到写代码的时候，很多人会习惯性地print，然后在“猜哪里有问题—加打印—重跑—再猜”的循环里耗掉一下午。或者知道pdb但不会用，面对(Pdb)提示符不知道敲什么。
记住那个进房间的比喻：print是装摄像头，只能看你提前对准的地方；pdb是亲自走进房间，想看哪里看哪里。你要探索一个不确定的区域，就走进去；你只是确认一个已知的点，摄像头也够用。
调试本身不难，难的是意识到“我现在的调试方式，是不是在限制我能看到什么”。print限制了你的视野，pdb打开了它。学会在合适的场景切换工具，调试的效率会完全不同。
