应仅对明确由外部抖动引起的网络请求测试用例使用 pytest-rerunfailures，配合 --reruns-verbose 和精准的 @pytest.mark.flaky 装饰器，避免掩盖真实问题或干扰 requests/aiohttp 自身重试逻辑。
直接上结论：用 pytest-rerunfailures 对网络请求类测试加重试，但必须配合 --reruns-verbose 和精准的 @pytest.mark.flaky 装饰器，否则你会掩盖真实问题，甚至干扰 requests/aiohttp 自身的重试逻辑。
为什么不能全局加 --reruns
网络波动只是表象，背后可能是 DNS 解析失败、连接被拒绝、响应超时、SSL 握手失败、服务端返回 503 或乱码 JSON——这些错误类型完全不同，重试价值也不同。全局开启 --reruns 3 会让所有失败用例都无差别重跑，包括那些明显是代码 bug 的断言失败（比如 assert response.status_code == 200 却收到 404），反而拖慢 CI、污染日志、掩盖真问题。
-
--reruns不区分错误类型，ConnectionError、TimeoutError、AssertionError 全部重试 - setup/teardown 阶段失败不会重试，比如
setUp()里requests.get("https://api.example.com")超时，整个用例直接报错退出，不进重试流程 - 高频重试可能触发目标服务限流，尤其在 CI 并行跑多任务时
@pytest.mark.flaky 只能打在 test 函数上，且位置很关键
装饰器必须写在 @pytest.mark.parametrize 外层，否则参数化后的每个子用例都不会触发重试。如果你写成：
@pytest.mark.parametrize("url", ["https://a.com", "https://b.com"])
@pytest.mark.flaky(reruns=2, reruns_delay=1)
def test_fetch(url):
...
那重试根本不会生效。正确写法是：
@pytest.mark.flaky(reruns=2, reruns_delay=1)
@pytest.mark.parametrize("url", ["https://a.com", "https://b.com"])
def test_fetch(url):
...
- 装饰器参数优先级高于命令行参数，适合混合策略：大部分用例不重试，仅少数对外部 API 的测试启用
- 不要和
@pytest.mark.xfail或@pytest.mark.skipif嵌套，行为不可控，容易跳过本该重试的用例 - 如果 fixture 里有网络调用（比如
@pytest.fixture(scope="function")中初始化 client），重试时 fixture 会重新执行——这是对的，但要注意副作用（如 token 刷新、临时资源创建）
--reruns-verbose 是定位问题的唯一可靠方式
默认情况下，pytest-rerunfailures 只输出最后一次失败的 traceback，前面几次失败日志全被吞掉。你看到一个 RERUN 然后直接 FAILED，根本不知道第一次是 ConnectionError，第二次是 ReadTimeout，第三次是 KeyError —— 这种信息差会让你误判为“网络问题”，实际可能是接口字段变更了。
- 必须加
--reruns-verbose才能看到每次重试的完整错误类型和堆栈 - 如果日志里反复出现
WARNING: urllib3.connectionpool: Retrying (Retry())，说明 requests 底层已经在重试（比如配置了Retry(total=3)），此时再套一层 pytest 重试不仅冗余，还可能导致重试次数翻倍或延迟叠加 - 重试成功 ≠ 问题不存在：某次重试通过，但三次日志里分别出现
ConnectionResetError、SSLError、JSONDecodeError，这说明服务端响应不稳定，得推动后端查日志，而不是关掉告警
和 requests / aiohttp 的重试逻辑别打架
requests 和 aiohttp 都自带重试机制，和 pytest 层重试不是互补关系，而是职责重叠。你应该让它们各管一段：
- requests：用
urllib3.Retry控制连接层重试（比如 5xx、连接中断），不处理业务逻辑错误 - aiohttp：用
aiohttp.ClientSession的raise_for_status=False+ 手动判断状态码，再决定是否重试 - pytest-rerunfailures：只覆盖“整个测试函数执行失败”这个粒度，且仅用于明确知道是外部抖动导致的偶发失败（如 CI 环境 DNS 不稳、测试服务器临时丢包）
- 二者同时启用时，建议 requests 最多重试 1 次，pytest 最多重试 2 次，总重试次数控制在 3 次以内，避免雪球效应
真正难搞的从来不是怎么加重试，而是怎么判断哪次失败该重试、哪次该立刻报警——这需要你盯着 --reruns-verbose 输出，看错误类型是否一致、堆栈是否指向同一行、响应内容是否随重试变化。否则，自动化只会帮你更快地忽略问题。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
