--failed-first能大幅缩短调试周期，因为它优先执行上次失败的用例，使修复验证从数分钟降至秒级；依赖.pytest_cache缓存，首次无失败记录则退化为普通执行。
为什么 --failed-first 能大幅缩短调试周期
它不重新跑全部用例，而是把上一次运行中失败的测试用例排在最前面执行。当你改完一行代码想验证是否修好了，不用等 3 分钟全量回归，可能 5 秒就看到结果——前提是上次失败记录还在 .pytest_cache 里。
这个机制依赖 pytest 的缓存系统，不是靠日志解析，所以只要没手动删掉 .pytest_cache 或加了 --cache-clear，就一直有效。
- 默认只对
pytest命令行调用生效，IDE（如 PyCharm）内置测试运行器通常不支持该参数，得配成外部命令运行 - 如果上次运行是用
pytest -x中断的，失败用例仍会被记录；但如果是被Ctrl+C强制终止，部分失败状态可能未写入缓存 - 多进程（
-n）下也能用，但失败顺序只反映“哪个用例挂了”，不保证并行中的精确执行时序
怎么启用 --failed-first 并确认它真在起作用
直接加参数就行：pytest --failed-first。但光加不一定见效，得看有没有历史失败记录。
你可以用这个小技巧快速验证：先故意让一个测试失败（比如在某个 test_xxx.py 里加个 assert False），跑一次 pytest，再删掉那行 assert，接着跑 pytest --failed-first —— 如果终端第一行输出是那个刚修好的测试名，说明缓存命中了。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 首次运行
--failed-first时若无历史失败，会退化为普通顺序执行，不会报错也不会提示 - 想看它到底挑了哪些用例，加
-v：例如pytest --failed-first -v，输出开头会列出 “running N failed tests first” - 缓存路径默认是项目根目录下的
.pytest_cache/v/cache/lastfailed，是个 JSON 文件，可直接打开查看内容
--failed-first 和 --lf 的区别别搞混
--lf（last failed）是更激进的模式：它只运行上次失败的用例，一个不多，一个不少；而 --failed-first 是“失败的放前面 + 其他照常”，适合你既想快速验证修复、又不想漏掉潜在连锁问题的场景。
- 如果你确定只关心“刚才那个错修没修好”，用
pytest --lf更快，甚至比--failed-first少几毫秒启动开销 - 但一旦你改了共享 fixture 或公共工具函数，其他用例也可能悄悄变脆弱，这时
--failed-first能帮你早点暴露新问题 -
--lf不会自动跳过被跳过的用例（比如被@pytest.mark.skip标记的），而--failed-first会尊重所有原本的筛选逻辑
容易被忽略的兼容性细节
这个参数从 pytest 4.6 开始支持，但直到 6.x 才稳定处理参数冲突。如果你用的是旧版（比如 4.0.2），加了 --failed-first 可能静默失效，或者和 --tb=short 之类组合时出异常。
- 推荐最低版本：pytest >= 6.0；检查方式：
pytest --version - 与
--pdb同时用没问题，失败时照样进 pdb；但和--exitfirst (-x)组合要小心——如果第一个失败用例又挂了，整个测试就停了，后面本该跑的用例全被跳过 - CI 环境里慎用：因为 CI 通常是干净容器，
.pytest_cache不存在，--failed-first等价于普通运行；想在 CI 复现本地失败顺序，得用--last-failed配合缓存上传下载
缓存文件本身很小，但它是基于测试节点 ID 生成的，而节点 ID 受测试路径、类名、方法名影响。重命名测试函数或挪动文件位置后，旧的 lastfailed 缓存就匹配不上了——这时候它就自动失效，退回到常规顺序。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
