真正决定Python调试效率的是对sys.settrace、breakpoint()、pdb三层机制的理解深度；breakpoint()可能因PYTHONBREAKPOINT=0、IDE未启用调试器或被try/except吞掉而失效；pdb中n、s、c命令在嵌套或异步场景易卡住；sys.settrace可自定义条件追踪但开销大；异步调试需避免直接在await后设断点，推荐pytest-asyncio或VS Code配合asyncio.create_task()。

标题里的“第232讲”和“教程”是干扰项，Python 调试没有编号课程体系，真正决定调试效率的是对 sys.settrace、breakpoint()、pdb 三层机制的理解深度，而不是看多少“讲”。

为什么 breakpoint() 有时不触发？

Python 3.7+ 引入的 breakpoint() 是个封装函数，默认调用 import pdb; pdb.set_trace()，但它会受环境变量 PYTHONBREAKPOINT 控制。常见失效场景包括：

• PYTHONBREAKPOINT=0 时，breakpoint() 直接变成空操作（no-op）
• 在 IDE（如 PyCharm、VS Code）中运行时，若未启用内置调试器，可能跳过断点或报 ImportError: No module named 'pdb'
• 被包裹在 try/except 中且异常被捕获并吞掉，导致控制流没走到断点位置

验证方式：运行

python -c "import os; print(os.environ.get('PYTHONBREAKPOINT'))"

pdb 命令行调试中最容易卡住的三个操作

不是所有命令都适合交互式调试现场——尤其在嵌套调用或异步上下文中：

• n（next）：只执行当前行，不进入函数。但若当前行是 func() 调用，你将直接跳过整个函数体，错过内部逻辑
• s（step）：进入函数，但遇到内置函数（如 len()、json.loads()）会卡死或报 *** Error in argument: ''
• c（continue）：继续运行到下一个断点，但如果后续无断点，程序直接退出，无法观察中间状态

更稳妥的做法是混合使用：l 查看上下文，p var_name 检查变量，pp dict_obj 美化打印复杂结构，避免盲目单步。

自定义 trace 函数绕过 pdb 的局限性

当需要在特定条件（如某变量等于某个值）时才中断，或想记录调用栈而不阻塞执行，sys.settrace 是底层可控方案：

import sys
def trace_calls(frame, event, arg):
if event == 'call':
func_name = frame.f_code.co_name
if func_name == 'target_function':  # 只追踪目标函数
filename = frame.f_code.co_filename
lineno = frame.f_lineno
print(f"[TRACE] {filename}:{lineno} → {func_name}")
return trace_calls
sys.settrace(trace_calls)
启动你的主逻辑
main()

注意：sys.settrace 开销极大，仅用于诊断，不可长期开启；它不会暂停执行，如需中断，得手动插入 import pdb; pdb.set_trace()。

调试异步代码时 asyncio 和 pdb 的兼容陷阱

pdb 本质是同步阻塞式调试器，直接在 async def 函数里写 breakpoint() 会导致事件循环挂起，甚至抛出 RuntimeError: await wasn't used with future。

• 不要在 await 表达式后立刻设断点，比如 await fetch(); breakpoint() —— 此时协程已恢复，上下文丢失
• 推荐用 asyncio.debug=True 启动解释器：

  python -X dev -c "import asyncio; asyncio.run(main())"

  ，配合 asyncio.current_task().get_coro() 查看当前协程对象
• 真实调试建议改用 pytest-asyncio + VS Code 断点，或用 asyncio.create_task() 包裹待调试协程再设断点

最常被忽略的一点：breakpoint() 在子进程、线程、协程中各自独立生效，主线程设的断点不会自动传播到 asyncio.to_thread() 启动的线程里。