pytest-rerunfailures插件需显式安装且版本兼容，否则--reruns参数不被识别；单个用例应使用@pytest.mark.reruns(3)装饰器，优先级高于命令行参数，支持delay配置。
安装 pytest-rerunfailures 插件后为什么 pytest 命令不识别 --reruns 参数？
插件没正确安装或版本不兼容是最常见原因。pytest 本身不自带重试功能，pytest-rerunfailures 必须显式安装且与当前 pytest 版本匹配。
- 用
pip install pytest-rerunfailures安装（不要用conda，部分镜像源的 conda 包未及时更新） - 检查 pytest 版本：
pytest --version；若为 8.x，需安装pytest-rerunfailures>=12.0（旧版如 7.x 对应 v10.x） - 验证插件是否加载成功：运行
pytest --help | grep reruns，能看到--reruns和--reruns-delay才算生效
如何对单个测试函数设置重试次数而非全局生效？
用 @pytest.mark.reruns 装饰器比命令行参数更灵活，尤其适合 flaky 测试和稳定测试混用的场景。
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 写法是
@pytest.mark.reruns(3)，表示该测试最多重试 3 次（即总共运行 4 次） - 可叠加 delay：
@pytest.mark.reruns(2, delay=1)，每次失败后等 1 秒再重试 - 注意：装饰器优先级高于命令行参数，如果命令行指定
--reruns=1，但某个函数标了@pytest.mark.reruns(3)，仍按 3 次执行 - 不推荐在 fixture 上加这个标记——它只对 test function 生效，对 setup/teardown 无效
重试时 stdout/stderr 和 traceback 怎么看？哪些输出会被覆盖？
默认情况下，只有最后一次运行的结果计入最终报告，但 pytest 会保留所有轮次的日志，只是不默认展示。
- 加
-s（禁用输出捕获）能看到每次重试的 print/print() 输出 - 加
--tb=short或--tb=long可看到每次失败的完整 traceback，但 pytest 默认只显示最后一次的 stack trace - 真正关键的是：如果某次重试成功了，前面失败的 traceback 不会出现在 summary 中，但会写入
--junitxml的<failure></failure>元素里（含message和output），可用于 CI 分析 - 避免在重试测试里依赖全局状态（比如文件写入、数据库插入），否则可能因残留数据导致后续重试行为异常
为什么设置了 --reruns=3，但实际只重试了 1 次就停了？
重试次数不是“最多尝试 N 次”，而是“失败后最多再跑 N 次”——只要有一次成功，就立即终止重试流程。
- 例如
--reruns=3：第 1 次失败 → 重试第 2 次 → 若成功，不再继续；若又失败 → 重试第 3 次；依此类推 - 真正跑满 4 次（1 + 3）的前提是前 3 次全失败
- 如果测试抛出的是
KeyboardInterrupt、SystemExit或被信号中断，pytest 会直接中止，不触发重试 - CI 环境下要注意超时设置：重试会延长总执行时间，Jenkins 或 GitHub Actions 的 job timeout 可能先于重试完成而杀掉进程
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
