pytest中直接写import pdb; pdb.set_trace()会因输出捕获和stdin关闭而卡住，正确做法是加-s关闭捕获、加--pdb-trace触发断点；推荐用python 3.7+的breakpoint()，它支持pythonbreakpoint环境变量灵活切换调试器或禁用。
pytest运行时如何触发pdb交互式断点
直接在测试代码里写 import pdb; pdb.set_trace() 仍然有效，但 pytest 默认会捕获 stdout/stderr 并禁用 stdin，导致 pdb 卡住或报错 ValueError: I/O operation on closed file。根本原因是 pytest 的输出重定向机制干扰了 pdb 的交互通道。
正确做法是启用 pytest 的内置 pdb 支持：
- 加
-s（等价于--capture=no）：关闭输出捕获，让 pdb 能读取键盘输入 - 加
--pdb：测试失败时自动进入 pdb；或加--pdb-trace（简写-P）：一运行就停在第一个breakpoint()或import pdb; pdb.set_trace() - 命令示例：
pytest test_example.py -s --pdb-trace
为什么推荐用 breakpoint() 而非 pdb.set_trace()
breakpoint() 是 Python 3.7+ 官方推荐的断点入口，它不只是调用 pdb.set_trace()，而是读取环境变量 PYTHONBREAKPOINT 来决定用哪个调试器。默认值是 pdb.set_trace，但你可以临时切到 ipdb.set_trace 或 pudb.set_trace，无需改代码。
实际影响明显：
- 如果项目已装
ipdb，设PYTHONBREAKPOINT=ipdb.set_trace，所有breakpoint()都自动用 ipdb - 在 CI 或某些容器环境里，设
PYTHONBREAKPOINT=0可全局禁用断点，避免意外阻塞 -
pdb.set_trace()是硬编码，改调试器必须批量替换代码
pytest + pdb 常见卡死场景和绕过方法
即使加了 -s，仍可能遇到 pdb 提示符不出现、按任意键没反应、或者报 EOFError: EOF when reading a line。这通常不是 pdb 问题，而是 pytest 的子进程/fixture/异步逻辑干扰了 stdin 绑定。
可尝试的组合策略：
- 对含
async def的测试，不要用--pdb-trace，改用--pdb+ 故意触发一个断言失败，再在失败栈里用u/d导航到目标帧后执行pp vars() - 若测试用了
monkeypatch或重定向了sys.stdin，在断点前手动恢复：import sys; sys.stdin = sys.__stdin__ - 在 Docker 或 GitHub Actions 中，确保启动 pytest 时未重定向 stdin，例如不要用
echo | pytest ...，而要用pytest ...
怎样在 fixture 中设置断点并保持上下文完整
fixture 执行早于测试函数，且 pytest 会缓存 fixture 返回值。如果在 fixture 里加 breakpoint()，第一次命中后后续测试可能跳过它——这不是断点失效，而是 fixture 复用机制生效了。
要稳定调试 fixture：
- 加
@pytest.fixture(autouse=True)+scope="function"（默认），确保每次测试都重建 - 在断点后加一句
print(f"DEBUG: fixture {request.node.name} running")，确认是否被跳过 - 避免在
session或module级 fixture 中设断点，除非你明确想只调试第一次初始化 - 如果 fixture 返回的是复杂对象（如数据库连接），在断点后用
p type(obj)和pp obj.__dict__查看真实状态，别只信print(obj)
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
