Pytest断言重写机制本身不直接导致第三方库报错，但会与依赖原始AssertionError堆栈、自行AST操作或动态修改assert行为的库冲突，尤其当库被误收集进测试路径时。
Pytest 的断言重写机制本身不会直接导致第三方库报错，但会与某些特定代码模式或库的内部实现冲突——尤其是当第三方库自己也做 AST 操作、动态修改 assert 行为，或依赖原始 AssertionError 的堆栈结构时。
pytest 的 assert 重写发生在导入阶段
Pytest 在收集测试模块时，会用自定义的 AST 重写器扫描所有 assert 语句，把它们替换成带上下文信息的等价逻辑（比如展开变量值、生成差异对比）。这个过程发生在模块被 import 时，且只对测试文件及其直接导入路径生效。
- 不是运行时 hook，不修改 Python 解释器行为
- 只重写测试模块（匹配
test_*.py或*_test.py）里的assert - 如果第三方库的源码里写了
assert，且该库被 pytest 自动收集（比如放在测试目录下），就会被重写——这通常不是设计意图，可能破坏其内部校验逻辑
常见冲突场景：assume、soft assert 类库
像 pytest-assume 这类库，本意是提供“软断言”（失败不中断执行），它需要在运行时拦截并捕获 AssertionError。但 pytest 的 AST 重写会让原始 assert 变成调用私有函数（如 __pytest_assertion__），导致：
-
pytest-assume的异常捕获逻辑找不到原始assert位置，抛出AttributeError: module 'pytest' has no attribute 'assume' - 即使安装了
pytest-assume，它的 hook 也没法覆盖 pytest 已经重写过的 assert 结构 - 错误不是来自 pytest 本身，而是插件与重写机制的协作缺失
如何避免这类报错
关键不是关掉断言重写（不推荐，会丢失调试信息），而是隔离作用域：
立即学习“Python免费学习笔记（深入）”；
- 确保第三方库代码不在测试目录中，也不被
pytest自动发现（检查pytest.ini的testpaths和python_files配置） - 不要在测试文件里
from somelib import *引入含 assert 的工具模块——改用显式函数调用 - 使用
pytest_plugins正确注册插件，而不是手动 patchpytest模块 - 若必须用 soft assert，优先选已适配新版 pytest 的实现（如
pytest-soft-assertions，而非已停止维护的pytest-assume）
真正容易被忽略的是：断言重写不是黑盒魔法，它依赖模块导入顺序和 AST 解析时机。一旦第三方库在 pytest 开始收集前就完成了自己的 assert 改写（比如通过 sys.settrace 或 importlib.abc.Loader），两者就会打架——这种底层冲突很难靠加 -p no:assertion 解决，得从包结构和加载链路入手。
