Python调试核心技能：掌握pdb交互式调试器的实战指南

1. 这不是“学个命令就完事”的调试课，而是帮你把 Python 程序从“跑起来”变成“看得清、想得透、改得准”的实战手册

你写完一段 Python 代码，运行后报错： IndexError: list index out of range 。你加了三行 print() ，发现某个列表在第 17 行突然变空了——可它明明在第 5 行还好好地 append 了五个元素。你删掉 print，再 run，错误又变了？或者更糟：程序没报错，但结果不对，你盯着逻辑看了半小时，越看越像对的，越对越怀疑自己。

这就是绝大多数 Python 新手（甚至不少写了两三年的人）每天真实面对的困境： 代码能动，但程序不透明；逻辑在脑中，不在眼前；问题在暗处，不在控制中。 而 pdb —— Python 自带的交互式调试器 —— 就是那把能直接捅进代码运行时心脏的手术刀。它不依赖 IDE 图形界面，不增加额外依赖，只要 Python 在， pdb 就在。你不需要等 VS Code 启动、不用配 launch.json、不用点开变量树、不用反复打断点再 resume。你只需要在代码里插一行 import pdb; pdb.set_trace() ，程序就会在那一行“冻结”，给你一个完全可控的 Python shell，让你逐行执行、检查任意变量、跳转到任意位置、甚至临时修改变量值来验证假设。

这门技术的价值，远不止于“修 bug”。它是你理解第三方库源码的钥匙（比如你想搞懂 requests.get() 内部到底怎么发 HTTP 包，直接 pdb 进去单步跟）；是排查异步代码竞态条件的唯一可靠手段（ asyncio 的 await 链路， print 根本跟不上节奏）；更是你写出健壮生产代码的肌肉记忆（在关键函数入口加 breakpoint() ，不是为了修 bug，是为了确认输入永远符合你的契约）。我见过太多人用 print() 调试爬虫，结果被反爬策略绕晕，却不知道 pdb 可以在 response.text 解析前一秒，直接 inspect 整个 response 对象的所有属性和方法。也见过团队用 pdb 在线上灰度环境快速定位一个内存泄漏：不是靠猜，而是用 !gc.get_objects() 实时查看哪些对象在疯狂堆积。所以，这不是一个“Python 入门教程”里轻描淡写的附加小节，这是你从“写代码的人”蜕变为“掌控程序运行的人”的分水岭。无论你是刚装好 Python 的零基础新手，还是正在用 pandas 做数据分析、用 Flask 写后端、用 PyTorch 训练模型的实践者，只要你还在和“为什么结果不是我想要的”搏斗， pdb 就是你今天最该花 45 分钟真正掌握的硬技能。

2. 为什么是 pdb ，而不是 VS Code 的图形断点或 print() 大法？

2.1 pdb 的不可替代性：它活在 Python 运行时的“最底层”

很多初学者会问：“VS Code 点一下就能断点，有图形界面，还能看变量树，为啥还要学命令行的 pdb ？”这个问题问到了本质。答案是： pdb 不是 VS Code 断点的“简化版”，而是它的“内核”和“终极备胎”。 VS Code 的 Python 扩展、PyCharm、甚至 Jupyter Notebook 的 %debug 魔法命令，底层调用的几乎都是同一个东西 —— pdb 模块。当你在 IDE 里点击断点，IDE 并没有自己实现一套解释器，它只是在背后悄悄注入了 pdb.set_trace() 或其等效机制，并把 pdb 的输入输出重定向到了自己的图形界面里。

这意味着什么？意味着一旦你的调试环境脱离了 IDE， pdb 就成了你唯一的、原生的、无需配置的武器。举几个真实场景：

• 服务器上调试线上脚本 ：你 SSH 登录到一台只装了 Python 的 Linux 服务器，要查一个每小时跑一次的 cron 任务为什么失败了。你不可能在服务器上装 VS Code，也不可能把日志全打出来（日志可能根本没覆盖到关键路径）。你直接 vim script.py ，在疑似出问题的函数开头加一行 breakpoint() ， python script.py ，程序立刻停住，你用 p 命令打印变量，用 l 查看上下文，用 n 单步执行，整个过程 30 秒搞定。而 print() ？你得改代码、加日志、保存、再运行、再看输出、再改……循环十次，天都亮了。

• 容器化环境调试 ：你的 Dockerfile 里只 RUN pip install -r requirements.txt ，没装任何 IDE。 pdb 是唯一能让你在容器内部实时介入程序执行流的工具。 docker exec -it <container> /bin/sh 进去， python -m pdb your_app.py ，一切照旧。

• 极简环境验证 ：你在一个全新的、干净的 venv 里测试一个包的兼容性，连 pip install 都不想多敲一次。 python -m pdb -c continue your_script.py ， -c continue 表示启动后直接运行（相当于无调试），但 pdb 已加载，随时可以按 Ctrl+C 中断进入调试模式。这种“按需激活”的灵活性，是任何图形 IDE 都无法比拟的。

提示： breakpoint() 是 Python 3.7+ 引入的官方推荐方式，它本质上就是 import pdb; pdb.set_trace() 的语法糖，但更优雅，且支持通过环境变量 PYTHONBREAKPOINT 全局禁用或替换为其他调试器（如 ipdb ）。新手请无脑用 breakpoint() ，它就是 pdb 的现代标准接口。

2.2 print() 的三大致命缺陷， pdb 如何一击必杀

print() 是所有程序员的“第一把刀”，但它在复杂场景下，脆弱得不堪一击。 pdb 的价值，正是建立在对 print() 缺陷的精准打击之上。

缺陷一：信息是“快照”，不是“现场”。
你写 print(f"list_a: {list_a}, len: {len(list_a)}") ，得到的是这一行执行完毕后的状态。但如果你想知道 list_a.append(item) 这个操作 执行前 item 是什么、 list_a 的 id 是否发生了变化（比如被重新赋值）、甚至 append 方法内部到底做了什么（比如是否触发了 __setitem__ ）， print() 给不了。 pdb 的 n （next）命令让你停在 append 调用之前， s （step into）命令让你直接跳进 append 的源码（如果可用）， p item 和 p id(list_a) 可以在毫秒级的时间窗口里获取任何你想知道的信息。这就像用高速摄像机拍子弹出膛，而不是只看靶子上的弹孔。

缺陷二：侵入性强，污染代码。
你加了十个 print() ，修完 bug 后，必须手动一个个删掉，否则上线后满屏日志。删漏一个，轻则影响性能，重则暴露敏感信息。 pdb 的 breakpoint() 是“无痕”的：它只在你明确需要时才生效，且 breakpoint() 本身在非调试模式下是空操作（ pass ），完全不影响运行时性能。你甚至可以把它留在生产代码里（当然，强烈不建议），它也不会做任何事。

缺陷三：无法交互式探索。
print() 是单向输出。你看到 x = [1, 2, 3] ，但如果你怀疑 x[0] 的类型有问题，你得再加一行 print(type(x[0])) ，再运行一次。 pdb 是双向的。程序停住后，你输入 p x[0] ，回车，立刻看到结果；再输 p type(x[0]) ，再回车；再输 !x[0] = 'hacked' （注意 ! 表示执行任意 Python 语句），把第一个元素改成字符串，然后 n 继续执行，看下游逻辑如何崩溃——这是一种主动的、实验性的调试，而非被动的、观察式的猜测。

2.3 pdb 的核心哲学：控制流即调试流

pdb 的所有命令，都围绕着一个中心思想设计： 你对程序执行流的控制权，就是你对调试过程的控制权。 它不提供“变量监视窗”，因为你可以用 p variable_name 随时打印；它不提供“调用栈视图”，因为 w （where）命令会清晰列出当前栈帧和每一层的文件、行号、函数名；它不提供“内存占用分析”，因为 !import gc; gc.get_stats() 就是一条命令的事。

这种设计让 pdb 极其轻量，学习曲线陡峭但回报巨大。你不需要记住几十个按钮，只需要掌握 6 个核心命令，就能解决 90% 的问题：

• n (next)：执行下一行， 不进入 函数内部。
• s (step)：执行下一行， 进入 函数内部（如果下一行是函数调用）。
• c (continue)：继续执行，直到遇到下一个断点或程序结束。
• l (list)：列出当前执行位置附近的源码（默认显示 11 行）。
• p (print)：打印表达式的值（ p my_list , p len(my_dict) ）。
• q (quit)：退出调试器，终止程序。

这六个命令，就是 pdb 的全部骨架。其余命令（如 pp 美化打印、 a 打印所有参数、 u/d 上/下栈帧）都是锦上添花。我教过上百个学员，凡是能熟练使用这六个命令的人，调试效率平均提升 3 倍以上。因为他们不再是在“找 bug”，而是在“指挥程序”，让程序按照他们的意志，一帧一帧地展开，暴露出所有隐藏的细节。

3. 从零开始： pdb 的四种实战接入方式与完整操作流程

3.1 方式一：最简单粗暴—— breakpoint() 插入法（推荐新手首选）

这是最直观、最不容易出错的方式，适合所有场景，尤其是你第一次接触 pdb 。

实操步骤：

1. 找到你的“怀疑区域” ：比如你有一个函数 process_data(data) ，它返回的结果总是 None ，而你预期是处理后的列表。你怀疑问题出在函数内部某一行。

2. 插入断点 ：在你希望程序暂停的那一行 上方 ，插入 breakpoint() 。例如：

   def process_data(data):
       # 数据预处理
       cleaned = [x.strip() for x in data if x]
       breakpoint()  # <-- 就在这里！程序会停住
       # 核心处理逻辑
       result = []
       for item in cleaned:
           if item.isdigit():
               result.append(int(item) * 2)
       return result
   

3. 运行程序 ：在终端里，直接 python your_script.py 。程序运行到 breakpoint() 这一行时，会立即暂停，并出现 (Pdb) 提示符。

4. 开始调试 ：此时，你已经进入了 pdb 的交互 shell。你可以：

   • 输入 l ，查看当前行及周围代码，确认你停对了地方。
   • 输入 p cleaned ，打印 cleaned 列表，看看预处理是否成功。
   • 输入 p data ，看看传进来的原始数据长什么样。
   • 输入 n ，执行下一行（即 result = [] ），然后 p result ，确认空列表已创建。
   • 输入 s ，进入 for 循环的第一轮迭代，再 p item ，看第一个 item 是什么。

关键细节与原理：
breakpoint() 的工作原理，是 Python 解释器在执行到这一行时，会触发一个 BdbBreakpoint 事件， pdb 模块捕获这个事件，暂停当前线程，并接管 sys.stdin 和 sys.stdout ，为你提供一个独立的、功能完整的 Python 解释器环境。这个环境共享当前作用域的所有局部变量、全局变量和导入的模块。所以你在 (Pdb) 下输入的任何 p 、 pp 、 ! 命令，都是在当前函数的执行上下文中执行的，效果和你在代码里写 print() 完全一样，只是更灵活、更即时。

注意：如果你在 Python 3.6 或更早版本中使用，需要将 breakpoint() 替换为 import pdb; pdb.set_trace() 。两者功能完全一致，只是后者多敲几个字。

3.2 方式二：命令行启动—— python -m pdb （适合调试脚本、复现问题）

当你有一个独立的 .py 文件，你想在不修改任何代码的前提下，直接从命令行启动调试， python -m pdb 就是你的最佳选择。

实操步骤：

1. 准备一个有问题的脚本 ：比如 buggy_script.py ，内容如下：

   import sys
   
   def calculate_average(numbers):
       return sum(numbers) / len(numbers)
   
   if __name__ == "__main__":
       # 模拟从命令行读取参数
       args = sys.argv[1:]
       nums = [int(x) for x in args]
       avg = calculate_average(nums)
       print(f"Average: {avg}")
   

2. 在终端运行 ： python -m pdb buggy_script.py 1 2 3 。注意， -m pdb 后面的参数，会原封不动地传递给你的脚本。

3. 进入调试模式 ：程序会停在脚本的第一行（ import sys ）。此时 (Pdb) 提示符出现。

4. 导航到目标函数 ：你不想在 import 上浪费时间，所以用 b （break）命令设置一个断点。输入 b calculate_average ， pdb 会告诉你断点已设在 calculate_average 函数的第一行。然后输入 c （continue），程序会直接运行到那个断点。

5. 深入探究 ：现在你停在 return sum(numbers) / len(numbers) 这一行。输入 p numbers ，你会看到 [1, 2, 3] 。输入 n ，程序执行这一行并返回。但等等，如果 numbers 是空列表呢？我们来模拟： python -m pdb buggy_script.py （不带参数）。 args 会是空列表， nums 也是空列表。 c 运行到 calculate_average ， p numbers 显示 [] ， n 执行，立刻报错 ZeroDivisionError 。你甚至可以在报错前，用 p len(numbers) 确认长度为 0，从而提前规避。

关键细节与原理：
python -m pdb 的本质，是把 pdb 模块当作一个可执行的主模块来运行。它会加载你的目标脚本，但不会立即执行，而是先初始化 pdb 的调试器对象，然后等待你的指令。 b 命令设置的断点，是 pdb 内部维护的一个断点列表，当解释器执行到某一行时， pdb 会检查该行是否在断点列表中，如果是，则暂停。这种方式的最大优势是 零代码侵入 ，你调试别人的代码、开源项目的 demo、或者一个你不敢轻易修改的遗留脚本时，它就是你的“外科手套”。

3.3 方式三：异常后自动进入—— pdb.post_mortem() （专治“程序崩了，但我不知道在哪崩的”）

这是 pdb 最酷、最救命的功能之一。当你的程序因为未捕获的异常而崩溃时， pdb 可以让你“时光倒流”，回到异常发生的那一瞬间，查看所有变量的状态。

实操步骤：

1. 制造一个崩溃 ：写一个 crash_script.py ：

   def risky_function():
       data = {"key": "value"}
       return data["nonexistent_key"]  # Key Error!
   
   if __name__ == "__main__":
       result = risky_function()
       print(result)
   

2. 正常运行，看崩溃 ： python crash_script.py ，你会看到熟悉的 KeyError: 'nonexistent_key' traceback。

3. 用 post_mortem 进入崩溃现场 ： python -c "import pdb, sys; pdb.post_mortem(sys.last_traceback)" 。这条命令的意思是：导入 pdb 和 sys ，然后调用 pdb.post_mortem() ，传入 sys.last_traceback （即上一次未捕获异常的 traceback 对象）。

4. 见证奇迹 ： (Pdb) 提示符出现，而且它停在了 return data["nonexistent_key"] 这一行！输入 p data ，你会看到 {'key': 'value'} ，完美印证了问题所在。输入 l ，可以看到出错的上下文。输入 u （up），可以向上移动到调用 risky_function() 的那一行，查看是谁传了这个 data 。

关键细节与原理：
sys.last_traceback 是 Python 解释器内置的一个变量，它始终保存着上一次未被 try/except 捕获的异常的 traceback 对象。 pdb.post_mortem() 接收这个对象，解析出其中的最后一个栈帧（即异常发生的位置），然后将 pdb 的调试器“附着”到那个栈帧上。这相当于把崩溃的那一刻，冻结成一个可交互的快照。这个技巧在调试那些难以复现的、偶发的线上异常时，价值连城。你不需要重启服务，不需要加日志，只需要拿到崩溃时的 traceback（通常在日志里就有），就能立刻进行深度分析。

3.4 方式四：集成到单元测试—— unittest 的 --pdb 参数（让测试成为你的调试助手）

如果你已经养成了写单元测试的习惯，那么 unittest 模块自带的 --pdb 参数，会把你的测试套件变成一个强大的、自动化的调试平台。

实操步骤：

1. 写一个失败的测试 ： test_example.py ：

   import unittest
   
   def add_numbers(a, b):
       return a + b
   
   class TestAddNumbers(unittest.TestCase):
       def test_add_positive(self):
           self.assertEqual(add_numbers(2, 3), 5)
   
       def test_add_negative(self):
           # 这个测试会失败，因为我们故意写错了
           self.assertEqual(add_numbers(-1, -1), -3)  # 应该是 -2
   
   if __name__ == '__main__':
       unittest.main()
   

2. 运行测试并启用 pdb ： python -m unittest test_example.py --pdb 。

3. 自动进入调试 ：当 test_add_negative 失败时， unittest 不会直接报错退出，而是自动调用 pdb.post_mortem() ，把你带到 self.assertEqual(...) 这一行的断点处。

4. 深度分析 ：输入 p a, b ，你会看到 (-1, -1) ；输入 p add_numbers(a, b) ，你会看到 -2 ；输入 p -3 ，你会看到 -3 。对比之下，问题一目了然。你甚至可以 s 进入 add_numbers 函数，确认它的逻辑。

关键细节与原理：
unittest 的 --pdb 参数，是在其内部的 TestCase.run() 方法中，捕获 AssertionError 后，主动调用 pdb.post_mortem() 。这使得每一个失败的测试，都变成了一个精心设计的、可重复的调试场景。你不需要手动构造数据，测试框架已经为你准备好了。这种“测试即调试”的工作流，是专业 Python 开发者提升代码质量的核心实践。它强迫你把调试思维前置到开发阶段，而不是等到用户报告 bug 才开始。

4. pdb 核心命令详解与高阶技巧：从“能用”到“精通”的跃迁

4.1 六大核心命令的深度剖析与避坑指南

4.2 高阶技巧：让 pdb 成为你思考的延伸

技巧一： pp （pretty print）——让复杂数据结构一目了然
当 p 打印一个嵌套很深的 dict 或 list 时，输出可能是一长串挤在一起的字符，难以阅读。 pp 会自动格式化，添加缩进和换行。

(Pdb) p {"users": [{"name": "Alice", "scores": [95, 87]}, {"name": "Bob", "scores": [88, 92]}]}
{'users': [{'name': 'Alice', 'scores': [95, 87]}, {'name': 'Bob', 'scores': [88, 92]}]}
(Pdb) pp {"users": [{"name": "Alice", "scores": [95, 87]}, {"name": "Bob", "scores": [88, 92]}]}
{'users': [{'name': 'Alice', 'scores': [95, 87]},
          {'name': 'Bob', 'scores': [88, 92]}]}

实操心得： pp 是我调试 JSON API 响应的标配。 pp response.json() 比 p response.json() 清晰十倍。

技巧二： ! （execute）——在调试器里写任意 Python 代码
! 后面跟的，就是纯粹的 Python 代码。你可以用它来修改变量、调用函数、甚至导入新模块。

(Pdb) !import json
(Pdb) !json.dumps({"debug": True})
'{"debug": true}'
(Pdb) !x = [1, 2, 3]
(Pdb) p x
[1, 2, 3]

实操心得：这是 pdb 最强大的地方。有一次我调试一个加密算法，需要验证一个中间密钥是否正确，我直接 !from cryptography.hazmat.primitives import hashes ，然后 !hashes.SHA256().name ，当场验证，不用退出重来。

技巧三： a （args）与 pp locals() —— 快速掌握当前函数的“全貌”
a 命令会打印当前函数的所有参数及其值。 pp locals() 会打印当前作用域的所有局部变量。这两者结合，能让你在 3 秒内理解函数的输入和当前状态。

(Pdb) a
data=['hello', 'world'], threshold=0.5
(Pdb) pp locals()
{'data': ['hello', 'world'], 'threshold': 0.5, 'cleaned': ['hello', 'world'], 'result': []}

实操心得：我把它当作“调试快照”。每次进入一个新函数，先 a 再 pp locals() ，就像医生问诊前先看一眼病历。

技巧四： u （up）与 d （down）——在调用栈中自由穿梭
u 命令让你向上移动一个栈帧（即回到调用当前函数的那个函数）， d 命令让你向下移动一个栈帧（即进入被当前函数调用的函数）。这让你能像剥洋葱一样，一层层查看整个调用链。

(Pdb) w
  /path/to/script.py(10)<module>()
-> result = process_data(raw_data)
  /path/to/script.py(5)process_data()
-> cleaned = clean_data(data)
  /path/to/script.py(1)clean_data()
-> return [x.strip() for x in data if x]
(Pdb) u
> /path/to/script.py(5)process_data()
-> cleaned = clean_data(data)
(Pdb) d
> /path/to/script.py(1)clean_data()
-> return [x.strip() for x in data if x]

实操心得：这是排查“谁传错了参数”的终极武器。当一个函数收到奇怪的输入时， u 一次，看调用者； u 再次，看调用者的调用者，直到找到源头。

5. 真实世界踩坑实录： pdb 使用中的 7 个经典问题与独家解决方案

5.1 问题一： breakpoint() 不起作用，程序直接跑过去了！

现象描述：
你在代码里加了 breakpoint() ，运行 python script.py ，程序飞快地跑完，没有任何提示， (Pdb) 提示符根本没出现。

排查思路与解决方案：
这几乎 100% 是因为 PYTHONBREAKPOINT 环境变量被设置为了 "0" 或空字符串。Python 3.7+ 的 breakpoint() 函数，会首先检查这个环境变量。如果它的值是 "0" ， breakpoint() 就会直接返回，不做任何事。

验证与修复：

• 在终端输入 echo $PYTHONBREAKPOINT （Mac/Linux）或 echo %PYTHONBREAKPOINT% （Windows）。如果输出是 0 或为空，问题就在这里。
• 临时修复 ：在运行前，临时取消该变量： PYTHONBREAKPOINT= python script.py （Mac/Linux）或 set PYTHONBREAKPOINT= && python script.py （Windows）。
• 永久修复 ：检查你的 shell 配置文件（ .bashrc , .zshrc , .profile ）或 Windows 系统环境变量，找到并删除或注释掉 export PYTHONBREAKPOINT=0 这一行。

我的独家心得：这是我带新人时遇到的最高频问题。一个简单的 echo $PYTHONBREAKPOINT ，能省下 2 小时的无效排查。把它加入你的“调试 checklist”第一条。

5.2 问题二：在 for 循环里， n 命令执行了整个循环，而不是一次迭代！

现象描述：
你在一个 for item in items: 循环里设置了断点，期望 n 能让你一次只走一个 item ，但 n 却直接执行完了整个循环，跳到了循环之后的代码。

原因与原理：
n （next）命令的含义是“执行下一行源代码”。在 Python 的字节码层面， for 循环的主体（即 for 下面的缩进块）是一个整体。 n 执行的不是“下一个 item ”，而是“下一行源码”，而 for 循环体在源码上只占一行（ for ...: ），所以 n 会直接执行完所有迭代。

正确解法：

• 方案 A（推荐）：用 s （step） 。 s 会进入循环体的第一行，执行完后停住，这样你就可以对每个 item 逐一检查。
• 方案 B：在循环体内加断点 。把 breakpoint() 放在 for 循环体的第一行，这样每次迭代都会触发。
• 方案 C：用 until 命令 。 until 25 （假设循环体结束在第 25 行）会让程序一直执行，直到到达第 25 行，这样也能实现“跳到下一次迭代开始”。

我的独家心得： s 是循环调试的黄金法则。我几乎从不用 n 来调试循环，一律用 s 。它虽然多按一次键，但带来的确定性和可控性，远超那点微小的效率损失。

5.3 问题三： p 命令报错 NameError: name 'xxx' is not defined ，但变量明明存在！

现象描述：
你在函数里 p my_variable ，却得到 NameError 。但你确定 my_variable 是在这个函数里定义的。

原因与原理：
最常见的原因是，你当前停在的位置， my_variable 还没有被定义。 pdb 的 p 命令，只能访问当前执行点 已经声明 的变量。例如：

def func():
    if False:
        my_variable = "hello"  # 这行永远不会执行
    p my_variable  # 这里会报 NameError，因为 my_variable 根本没被创建

排查与解决：

• 输入 l ，确认你停在了变量定义 之后 的行。
• 输入 pp locals() ，查看当前作用域里到底有哪些变量。如果 my_variable 不在列表里，说明它还没被创建。
• 如果是条件分支，确保你停在了正确的分支里。可以用 p condition 先检查条件值。

我的独家心得： pp locals() 是我的“变量存在性检测仪”。只要对变量有哪怕一丝怀疑，我就 pp locals() ，它从不撒谎。

5.4 问题四： pdb 里无法使用 Tab 补全，输命令太慢！

现象描述：
在 (Pdb) 提示符下，你输入 p 然后按 Tab ，没有任何反应，无法补全变量名。

原因与原理：
pdb 默认的 readline 支持，在某些系统（尤其是 Windows 的 CMD）或某些 Python 版本下， Tab 补全功能可能被禁用或损坏。

解决方案：

• 终极方案：安装 ipdb 。 ipdb 是 pdb 的增强版，基于 IPython ，拥有完美的 Tab 补全、语法高亮、历史命令等。 pip install ipdb ，然后把代码里的 breakpoint() 换成 import ipdb; ipdb.set_trace() ，或者设置 PYTHONBREAKPOINT=ipdb.set_trace 。
• 临时方案：用 p + Tab 补全变量名 。在 p 命令后， Tab 通常能补全变量名（因为 p 是一个命令，后面跟的是表达式）。
• Windows 用户 ：尝试在 Windows Terminal 或 Git Bash 中运行，它们的 Tab 支持比原生 CMD 好得多。

我的独家心得： ipdb 是我从不离身的“ pdb 升级包”。它不改变 pdb 的核心逻辑，却让交互体验提升了 200%。对于任何严肃的 Python 开发者， ipdb 都是必装项。

5.5 问题五：调试多