真正决定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'))"，非空且非 0 才有效。
pdb 命令行调试中最容易卡住的三个操作
不是所有命令都适合交互式调试现场——尤其在嵌套调用或异步上下文中：
立即学习“Python免费学习笔记（深入）”；
-
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() 启动的线程里。