默认pytest全量运行防不住回归，因其不记录历史耗时、不保存覆盖率变化、不校验输出稳定性；须叠加覆盖率兜底、性能基线校验、环境显式声明三重守门机制。
CI 中跑全量 pytest 测试本身不能预防回归风险，关键在于「怎么跑」和「跑完怎么用」。只执行 pytest 命令，不设断言、不存基线、不比对结果，等于把扫描仪当手电筒用——照得到，但看不出异常。
为什么默认 pytest 全量运行防不住回归
pytest 默认行为是“通过即结束”，它不记录历史耗时、不保存覆盖率变化、不校验输出稳定性。一次测试通过，不代表性能没退化、逻辑没漂移、边界没漏掉。
- 没有 baseline：上次
test_user_login耗时 120ms，这次 380ms？pytest 不报错，除非你手动加assert - 覆盖盲区：
--cov=src只统计行覆盖，但新增分支逻辑可能完全没被新测试触达 - 环境漂移：本地 pass 的测试，在 CI 的干净容器里因缺失
os.environ或时区配置而 silent fail
必须加的三个强制约束项
在 CI 的 script 阶段，仅靠 pytest 命令不够，要叠加三重守门机制：
- 覆盖率兜底：
pytest --cov=src --cov-fail-under=85—— 整体覆盖率低于 85% 直接失败，避免“测了但没完全测” - 性能基线校验：
pytest --benchmark-compare=origin/main --benchmark-autosave—— 比对 main 分支最近一次基准，任一用例耗时增长超 15%（默认阈值）则退出 - 环境显式声明：
python -c "import django; print(django.VERSION)"+pip list | grep -E 'pytest|django|requests'—— 在日志中固化依赖版本，防止“本地能过，CI 报错”类问题
如何让全量扫描真正触发回归预警
全量不是目的，可追溯的差异才是。重点不在“跑多少”，而在“记什么、比什么、谁来管”：
- 每次
pytest运行后，必须生成并上传coverage.xml和benchmark.json到制品库，供后续 diff - 用
pytest --lf（last-failed）在 PR 流水线中快速复现上一次失败用例，但主干合并前必须强制全量 - 禁止在 CI 中使用
--tb=short或-q：详细 traceback 是定位回归点的第一手线索，压缩日志等于掩埋证据
最容易被忽略的是「基线不是静态快照，而是动态锚点」。如果 --benchmark-autosave 只存本地，或 coverage.xml 不上传归档，那所谓“对比”就只是空谈。CI 流水线里没有记忆，所有判断依据都得是它当场能读到、能验证、能拒绝的东西。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
