pytest.raises 未捕获 assertionerror 是因 pytest 将测试函数内未处理的 assertionerror 视为测试失败而非待验异常；需将断言逻辑封装在独立函数或 lambda 中调用。
pytest.raises 为什么没捕获到 AssertionError？
因为 assert 报错是 AssertionError，但 pytest 默认把测试函数里未处理的 AssertionError 当作测试失败，而不是待验证的异常——它根本不会进 pytest.raises 的拦截逻辑。
实操建议：
- 把要触发断言的代码包在独立函数里（不能直接写在测试函数体顶层），再让
pytest.raises调用它 - 或者用
lambda匿名包装：pytest.raises(AssertionError, lambda: assert False) - 别写
assert some_func() == 42这种「测试断言」，那是 pytest 自己的断言机制，和你要捕获的业务逻辑断言不是一回事
如何正确提取并校验报错信息文本？
pytest.raises 返回的是一个上下文管理器对象，进入 with 块后才能拿到异常实例，excinfo.value 才是真正的异常对象，它的 args 或 str() 表示错误消息。
常见错误现象：直接打印 excinfo 看到一长串调试信息，误以为是错误文本；或用 excinfo.message（已弃用，Py3.12+ 报错）。
实操建议：
- 用
str(excinfo.value)获取完整错误信息字符串 - 校验时优先用
in判断关键词是否存在，比如assert "timeout" in str(excinfo.value) - 避免用
==全等匹配，因为堆栈、路径、时间戳等可能变化
pytest.raises 和 try/except 在测试里能混用吗？
能，但没必要，而且容易干扰 pytest 的异常处理流程。特别是你手动 try/except 后没 raise 出来，pytest 就收不到异常，raises 会直接报「未捕获预期异常」。
使用场景：仅当你需要在异常发生后做额外检查（比如验证某个临时文件是否被清理），才考虑退出 with pytest.raises(...) 后再补逻辑。
实操建议：
- 95% 的情况只用
with pytest.raises(XXX):包住调用即可 - 如果必须加
try/except，确保异常最终被重新抛出，或改用pytest.fail("expected exception not raised")显式失败 - 不要在
with块里写多个可能抛异常的语句——你只能拿到第一个异常的excinfo
参数 match= 正则匹配 vs str(excinfo.value) 手动判断
match= 是 pytest.raises 的关键字参数，底层用 re.search 匹配异常消息，但它只作用于 str(excinfo.value)，且不支持跨行匹配（异常消息含换行就失效）。
性能影响：正则编译开销极小，可忽略；但兼容性上，match= 在 pytest 3.0+ 才支持，老项目若还在用 2.x 版本会直接报错。
实操建议：
- 简单关键词用
match="timeout"更简洁 - 要匹配多行、或需逻辑组合（比如“包含 A 且不包含 B”），放弃
match=，改用str(excinfo.value)+ 普通 Python 字符串操作 - 注意
match=是正则，特殊字符如.、?要转义，否则行为出乎意料
最常被忽略的一点：断言失败发生在 fixture 里时，pytest.raises 是捕获不到的——得把触发逻辑移到测试函数内部，或者用 request.addfinalizer 配合手动异常捕获。这事没法自动兜底。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
