pytest.raises不能直接用于assert，因为它是上下文管理器而非布尔函数；正确用法只有with语句块或装饰器，且需确保目标代码精准抛出指定异常。
pytest.raises 为什么不能直接写成 assert raises(...)
因为 pytest.raises 不是返回布尔值的断言函数，而是一个上下文管理器（也可作装饰器），它要“捕获正在发生的异常”，而不是检查“某个表达式是否曾抛出过异常”。直接写 assert pytest.raises(ValueError) 会报 TypeError: __bool__ not supported —— 这是最常踩的第一个坑。
正确姿势只有两种：with 语句块，或修饰测试函数。
- 用
with pytest.raises(ExcType)包住**实际触发异常的那行代码**，不是包整个函数 - 如果用作装饰器，必须确保被装饰函数**一定会且仅抛出一次**目标异常；多抛、不抛、抛错类型都会导致测试失败
- 别在
with块里放多条语句——除非你明确知道哪一行该抛异常；否则一旦前几行就出错（比如 NameError），pytest.raises根本没机会捕获目标异常
如何获取并检查异常实例的属性（如 message、args）
只确认“抛了 ValueError”往往不够，业务中常需验证错误信息是否含特定关键词，或检查异常携带的数据。这时得把异常对象“抓出来”：
with pytest.raises(ValueError) as exc_info:
risky_function("bad_input")
assert "missing" in str(exc_info.value)
assert exc_info.value.args == ("invalid format",)
-
exc_info是ExceptionInfo对象，其.value属性才是原始异常实例 -
str(exc_info.value)等价于打印异常时看到的 message，比直接访问.args[0]更安全（避免索引越界） - 不要写
exc_info.type is ValueError—— 类型已由pytest.raises(ValueError)保证，重复校验冗余
pytest.raises 和 try/except 在测试里混用会怎样
完全没必要，而且容易翻车。有人想“先 try 再 assert”，写出这样的代码：
try:
risky_function()
assert False, "should have raised"
except ValueError as e:
assert "timeout" in str(e)
这看似能跑通，但问题明显：
- 如果
risky_function()没抛异常，assert False触发，报错信息是 “should have raised”，而非 pytest 原生的清晰异常断言失败提示 - 丢失 pytest 的异常堆栈高亮、重试机制、与 pytest-xdist 兼容性等优势
- 一旦
risky_function()抛出的是TypeError而非ValueError，整个测试就直接崩溃退出，不会进入 except 分支，更不会执行后续断言
结论：坚持用 pytest.raises，别倒退到手写 try/except。
常见误用：传字符串匹配 message 或忽略异常类型
有人试图这样写：pytest.raises("ValueError") 或 pytest.raises(Exception)，前者直接报错（参数必须是异常类），后者虽能运行但严重削弱测试有效性。
-
pytest.raises(Exception)会捕获SystemExit、KeyboardInterrupt甚至你忘了return导致的TypeError，掩盖真实问题 - 想校验 message 内容，请用上面说的
exc_info.value方式，而不是幻想pytest.raises(ValueError, match="timeout")—— 注意：这个match参数**只在 pytest ≥ 3.1 且用正则时才有效**，低版本不支持，且易写错正则（比如忘记 re.escape） - 若真要用
match，务必加import re并对动态内容做转义：match=re.escape("user_id=123")
最稳妥的做法，永远是显式指定异常类型 + 显式检查 exc_info.value 的属性。复杂逻辑的异常校验，值得多写一两行，换来可读性和稳定性。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
