pytest并非故意吞异常，而是默认将未捕获异常视为测试失败并精简traceback；使用--tb=long可完整显示fixture setup/teardown中的异常源头，配合正确处理teardown异常和pytest.raises()的match/excinfo校验，才能避免误判。
pytest为什么会“吞掉”异常
不是pytest故意隐藏异常，而是它默认把未捕获的异常当作测试失败来处理，并只展示 traceback 的关键部分——尤其是当你在 conftest.py 或测试函数里用了 try/except 却没重新抛出，或者异常发生在 fixture teardown 阶段时，堆栈会截断、信息被压缩，看起来就像“异常消失了”。
用 --tb=short 或 --tb=long 控制 traceback 输出粒度
pytest 默认用 --tb=auto，对通过的测试不显示 traceback，对失败的也只显示最后一层。这会让底层异常（比如 fixture 里 raise 的）被折叠掉。
-
pytest --tb=short：保留文件名和行号，但省略局部变量，适合快速定位 -
pytest --tb=long：完整显示所有帧，包括 setup/teardown 中的异常源头 -
pytest --tb=native：用 Python 原生格式输出，不加 pytest 修饰，方便复制到 pdb
最常用的是 --tb=long，尤其排查 fixture 异常时，能一眼看到 setup 或 teardown 哪一行崩了。
检查 fixture teardown 是否静默吃掉了异常
这是最隐蔽的“吞异常”场景：你写了 yield fixture，但在 finally 或 __exit__ 里发生异常，pytest 默认只报最后一个异常，前面的直接丢弃。
创建 Flask + Vue.js 全栈项目，采用单端口架构、uv 依赖管理、结构化日志和生产级前端设计。当用户要求以下操作时触发：创建新的 Flask+Vue 项目、搭建 Web 应用、构建全栈 Python+Vue 应用、初始化 Flask Web 项目、设置单端口 Flask 前后端项目。触发词：新建项目、创建项目、搭建项目、Flask项目、Vue项目。
立即学习“Python免费学习笔记（深入）”；
- 避免在
finally块里做可能 raise 的操作（比如关闭已关闭的资源） - 若必须做清理，用
try/except包裹并显式记录：def my_fixture(): conn = get_conn() try: yield conn finally: try: conn.close() except Exception as e: print(f"[fixture cleanup error] {e}") # 至少打日志 raise # 不要吞，除非你真想忽略 - 用
@pytest.fixture(autouse=True)时更要小心——它的 teardown 错误会影响整个测试模块
用 pytest.raises() 主动捕获异常时别漏掉 match 或 excinfo
写 with pytest.raises(ValueError): 很常见，但如果异常类型对但消息不对，pytest 默认不报错；更糟的是，如果你在 with 块里没触发异常，pytest 会静默通过（除非你加 match 或后续检查 excinfo）。
- 强制验证异常消息：
with pytest.raises(ValueError, match="timeout"): - 需要 inspect 异常对象时，用
as excinfo：with pytest.raises(RuntimeError) as excinfo: risky_func() assert "broken" in str(excinfo.value) - 漏写
as excinfo又不做match，就等于只测了“有没有抛”，不保证抛得对——容易掩盖逻辑缺陷
真正难 debug 的，往往是那些“测试看似通过，但异常根本没按预期抛出”的 case。盯住 excinfo 和 match 是最省时间的习惯。
