直接用requests.get()调用接口常失败，因网络抖动、服务不可用或限流（如429）会触发connectionerror、timeout或非200状态码；盲目重试可能加剧压力或掩盖401等不可重试错误，应区分错误类型，用urllib3.retry配合session实现可控重试。
为什么直接用 requests.get() 调用接口经常失败？
网络抖动、服务临时不可用、限流响应（如 429 Too Many Requests）都会让单次请求直接抛出 requests.exceptions.ConnectionError、Timeout 或返回非预期状态码。不加控制地重试反而可能加剧服务压力，或掩盖真实错误（比如 401 Unauthorized 不该重试）。
实操建议：
- 区分「可重试错误」和「不可重试错误」：网络层异常（连接超时、拒绝连接）和部分 5xx（如
502、503、504）适合重试；4xx 中除429外，多数（如400、401、403、404）应立即失败 - 避免无休止重试：设置最大重试次数（常见为 3–5 次）和指数退避间隔（如首次 1s，第二次 2s，第三次 4s）
- 不要在测试脚本里手写
while循环重试逻辑——易漏状态码判断、难统一控制、干扰断点调试
用 urllib3.Retry 配合 requests.Session 最简落地
requests 底层基于 urllib3，其内置的 Retry 类已覆盖重试核心逻辑，无需引入额外包。关键是要把重试策略绑定到 Session 实例，而非每次调用都新建连接。
实操示例：
from requests import Session
from urllib3.util.retry import Retry
<h1>定义重试策略：仅对连接错误、读取超时、502/503/504/429 重试 3 次</h1><p>retry_strategy = Retry(
total=3,
status_forcelist=(429, 502, 503, 504),
method_whitelist=frozenset(["GET", "HEAD", "OPTIONS"]), # POST 默认不重试（非幂等）
backoff_factor=1 # 退避因子：1 → 0s, 1s, 3s（实际间隔 = factor × (2^(n-1) - 1)）
)
adapter = HTTPAdapter(max_retries=retry_strategy)
session = Session()
session.mount("http://", adapter)
session.mount("https://", adapter)</p><h1>后续所有 session.get() 都自动带重试</h1><p>response = session.get("<a href="https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca">https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca</a>", timeout=5)
</p>
注意：backoff_factor=1 时，第 1 次重试前等待 0s（立刻重试），第 2 次前等 1s，第 3 次前等 3s。若需首次就等 1s，设为 0.5。
测试中如何验证重试是否生效？
不能只看最终成功——得确认它确实重试了，且没在不该重试的地方乱重试。最可靠方式是用 responses 库 mock 接口行为，构造可控的失败序列。
实操要点：
- 安装：
pip install responses - mock 多次返回不同响应：先返回
503，再返回200，检查最终 response 状态码是否为 200，且请求计数为 2 - mock 返回
401，确认只发 1 次请求并抛出异常（response.status_code == 401） - 避免在测试中依赖真实网络：所有测试用例必须离线可运行
Pytest 中集成重试逻辑要避开哪些坑？
有人会想在 pytest 的 @pytest.mark.parametrize 或 fixture 里封装重试，这容易导致重试逻辑和测试断言耦合，失败时难以定位是接口问题还是断言问题。
更稳妥的做法：
- 重试只发生在「发送请求」环节，保持测试函数本身职责单一：只做请求 + 断言
- 用 fixture 提供预配置好的
session（含重试策略），测试函数直接使用，不感知重试细节 - 禁用 pytest 的
--maxfail对重试测试的影响：某次重试失败后，pytest 可能因错误堆栈长而误判为多个失败，建议配合-v查看完整输出 - 日志中显式记录重试次数：在自定义
HTTPAdapter的send方法里加print(f"Retry #{retry_count} for {url}")（仅调试用）
重试不是万能补丁。真正棘手的是那些偶发的 500 错误——它可能是下游服务状态不一致导致，重试只会把问题掩盖得更深。这类情况，得配合接口可观测性（如响应耗时分布、错误率突增告警）来定位，而不是靠多试几次。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
