来不及解释快上车的 PDB 调试指南

什么是 PDB

PDB 全称 Python Debugger，专门调试 Python 程序的官方库。

有代码就有 Bug，而调试 Bug 则是程序员的必备技能。工欲善其事必先利其器，还好 Python 为我们提供了强大的 PDB。

那么，何时使用 PDB？

以日志调试为荣，以单点调试为耻告诉我们，单点（单步）调试的效率不是很高，也许打印日志是更好的解决办法，说不定利用日志调试的同事早下班了，而你还在吭哧吭哧的单步调试，画面感人。

另外，在解决一个问题的「典型步骤」中，「分析问题并作出假设」占有很大的比重，不要一上来，抓起工具就是干，这是莽撞的做法，连问题都没有定义清楚的情况下，只能是南辕北辙。

你可能在以一种错误的方式使用 PDB

使用 pdb 调试，你是不是习惯这样做？
第一步，在代码中加入这几句：

import pdb

......
pdb.set_trace()                                         # 埋断点
......

第二步，执行 python $yourFile.py, 则程序会自动停留在断点处，然后开始愉快地调试。

但是这样做的效率真的很低。首先你的断点是死的，固定的，静态的；其次是你还要修改代码文件，万一哪天忘记将文件改回原来的状态了，然后直接推向生产环境。。。

这种做法是不好的，甚至是错误的。

这不是我们想要的，也不是 pdb 想给你的。

我们需要的是，动态地，随心所欲地注入断点，并且不要去动源码文件。

哪条是正道呢？

下面就来讲讲使用 PDB 的正确思路。

第一步，直接以python -m pdb $yourFile.py运行文件，然后 pdb 会停留在文件的第一行。

第二步，随心所欲地注入断点。只需要在 pdb 交互式环境中，运行break $lineNumber即可，每运行一次，就是打了一个断点。（break 查看所有断点）

第三步，enable / disable 断点。

• disable $breakPointNumber 暂时禁止掉该断点
• enable $breakPointNumber 启用该断点
• clear $breakPointNumber 彻底清除该断点

第四步，执行断点。

• next单步走
• step单步走，但是遇到函数调用，会陷进去
• until从循环中脱离
• return从被调用函数中脱离
• list 告知自己的位置
• quit直接退出本次调试

第五步，至此，随心所欲地调试，感受世界的善意。

尝试 PDB 的其他用法

调试的时候，我们需要频繁地查看一个变量，或者一个对象的值。

当然，你可以这样：

(Pdb)  p $variable
(Pdb)  pp $variable

# 查看某个变量的帮助
(Pdb)  !help $someInstance 
# 查看某个对象的 __dict__
(Pdb)  pp vars($someInstance)                         

每次输入这么多，次数多了，不免觉得厌烦，有没有更好的办法呢？

当然，答案就是 alias 。

(Pdb)  alias ph !help(%1)                              # %表示变量的意思
(Pdb)  alias pv pp vars(%1)
(Pdb)  alias                                           # 列举所有 alias
(Pdb) unalias $someAlias

可惜，这样还是只能临时 alias，只是帮我们省了一小部分力气，并不是我们想要的。

这时候 .pdbrc 就上场了。

1. ~ 目录下的 .pdbrc 表示全局的 pdb 配置
2. 当前目录下的  .pdbrc 表示针对某个项目的 pdb 配置
3. 非常类似 .bashrc 的配置规则

那么现在就把你所经常使用的 pdb 配置，放到 ~ 目录下或者当前目录下的 .pdbrc 中去吧，一劳永逸有木有！

总结一下

pdb 其实提供了很多很强大的功能，只是我们不会利用，或者没有正确地使用，致使我们不断在黑暗中前行，无形中让我们加了很多班。