pytest-rerunfailures重试机制生效的前提是必须显式启用：运行时指定--reruns参数（如pytest --reruns 3），或对用例添加@ pytest.mark.flaky(reruns=n)装饰器，且配置文件中的reruns仅作默认值，仍需命令行传参。
pytest-rerunfailures 重试机制生效的前提条件
pytest-rerunfailures 不会自动重试所有失败用例，必须显式启用。最常见遗漏是没加命令行参数或装饰器，导致看似安装了却完全不触发重试。
- 安装后需在运行时指定
--reruns参数（如pytest --reruns 3），否则默认不启用重试逻辑 - 若只对部分测试用例重试，需配合
@pytest.mark.flaky(reruns=2)装饰器，且该标记必须放在@pytest.mark.parametrize外层（否则可能被忽略） -
pytest.ini或pyproject.toml中配置的reruns仅作为默认值，仍需命令行明确传入--reruns才生效
reruns 参数值为 0 或负数时的行为
很多人误以为 --reruns 0 表示“不重试”，实际它会让插件尝试重试 0 次——也就是直接失败，且不输出重试日志，容易误判为插件未工作。
-
--reruns 1表示最多重试 1 次（即总共执行 2 次） -
--reruns 0是合法参数，但等价于“不重试”，且不会打印任何 rerun 相关信息，调试时建议避免使用 -
--reruns -1是特殊值，表示无限重试（慎用！CI 环境中可能导致超时卡死）
与 pytest-xdist 并发执行的兼容性问题
在多进程模式下（如 pytest -n 4），pytest-rerunfailures 默认无法跨 worker 汇总重试状态，会导致：
- 同一个失败用例可能在不同 worker 中重复重试，浪费资源
- 重试次数统计不准确（各 worker 独立计数）
- 日志混杂，难以定位哪次重试真正通过
解决方法只有两个：
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
立即学习“Python免费学习笔记（深入）”；
- 关闭并发：
pytest --reruns 2不带-n - 或升级到
pytest-rerunfailures>=12.0，并显式启用实验性支持：--reruns-delay 1 --reruns-verbose，但仍需注意重试间隔和日志可读性
重试失败后如何获取原始错误堆栈
默认情况下，pytest-rerunfailures 只显示最后一次失败的 traceback，前几次失败的详细信息会被覆盖，不利于分析 flaky 根因。
- 加上
--reruns-verbose参数，会在报告末尾列出每次重试的完整 traceback - 若用
pytest --tb=short等精简 traceback 模式，重试日志也会被压缩，建议调试 flaky 时统一用--tb=long - 注意：即使启用了 verbose，pytest 的 summary 里仍只显示最终状态（FAIL/PASS），要看历史需翻日志末尾
重试不是掩盖不稳定，而是给非确定性问题留出观察窗口；真正难的是判断哪次失败是环境抖动、哪次是逻辑缺陷——这得靠日志上下文，而不是重试次数本身。
