pytest运行失败时加--pdb参数可自动进入pdb调试器，停在异常抛出处；--trace用于逐行调试，--pdb-on-failure无效时可用assert false伪造失败触发pdb。
pytest运行时怎么在失败处自动进pdb
直接加 --pdb 参数就行，pytest会在测试抛出未捕获异常时自动启动交互式调试器。这不是事后查日志，是立刻停在出错那行代码上，变量、调用栈全在手边。
常见错误现象：只加了 -s 或 --capture=no，以为能看输出就等于能调试——其实没触发pdb，失败后直接退出。
-
pytest test_module.py::test_something --pdb：只对单个测试启用 -
pytest --pdb -x：失败即停，且不继续跑后续用例 - 如果测试里用了
try/except吞掉了异常，--pdb不会触发——它只响应未被处理的异常
想在某一行手动打断点，但不用改源码加breakpoint()
用 --trace，它会让pytest在进入每个测试函数前暂停，然后你手动输入 n（next）或 s（step）推进，遇到想深挖的地方再按 s 进入函数内部。
比在代码里写 breakpoint() 更灵活：不用提交调试语句，不污染逻辑，也不依赖Python 3.7+；但需要你对执行路径有基本预判，否则容易错过断点位置。
-
--trace和--pdb可以一起用，但优先走--trace的逐行模式 - 在pdb里输
pp some_var能安全打印复杂结构，比print()不怕触发__repr__异常 - 如果测试依赖fixture，
--trace会先进入fixture setup，别误以为卡住了
为什么pdb里看不到局部变量，或者报NameError
因为pytest默认用 exec 动态加载测试模块，导致pdb的上下文作用域和实际执行时不完全一致——尤其是你在测试函数外设断点，或者用了lambda、内嵌函数时。
这不是环境配置问题，是CPython调试器本身的限制。最稳的解法是：把想观察的变量显式赋给全局可访问的名字，比如临时加一句 debug_x = x，再在pdb里查 debug_x。
- 避免在lambda里设断点，pdb几乎无法正确解析其locals
- 用
!locals()命令看当前作用域所有变量，但注意它可能漏掉优化掉的临时值 - 如果用pytest-xdist并行跑测试，
--pdb会失效——它不支持多进程下的调试器接管
测试通过但结果不对，怎么用pdb验证中间状态
加 --pdb-on-failure 不起作用，因为它只响应失败。这时候得靠 --pdb 配合预期失败：手动让测试抛个异常，比如末尾加 assert False, "inspect here"，运行后就会停住。
这招本质是“伪造失败”，只为拿到pdb控制权。做完检查后删掉那行assert就行，比反复改 breakpoint() 开关更轻量。
- 别用
raise Exception("stop")，有些测试框架会捕获基类异常，导致pdb不触发 - 在fixture里加断点更危险：多个测试共享fixture时，pdb可能停在不该停的地方
- 如果测试读文件或发HTTP，pdb暂停期间外部状态可能变化，注意时间敏感逻辑
真正麻烦的是异步测试——pdb本身不理解async/await事件循环，await 行停不住，必须用 pytest-asyncio 配合专用调试方式。这点很容易被忽略，等发现pdb跳过await才反应过来不是自己操作问题。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
