重试函数核心是可控重试逻辑：只对5xx服务端错误和网络超时等可重试错误触发，采用指数退避（含抖动）延迟，限制最大重试次数（如3次）与总超时，返回结构化结果便于业务处理。
用重试函数包装第三方 API 请求，核心是把一次可能失败的调用封装进可控的重试逻辑里——不是盲目循环，而是有判断、有延迟、有退出条件。重点不在“多试几次”，而在于“什么时候该试、试多久、试多少次、试不成就怎么办”。
只对可重试错误触发重试
不是所有失败都值得重试。网络超时、5xx 服务端错误（如 502、503、504）通常可重试；而 4xx 错误（如 400 参数错误、401 未授权、404 不存在）多数是客户端问题，重试无意义。建议在请求后检查：
-
fetch 场景：用
res.status >= 500 && res.status 判断是否为服务端错误 -
axios 场景：捕获
error.code === 'ECONNABORTED'（超时）或error.response?.status >= 500 - 还要考虑
AbortError（手动中止）、TypeError（网络中断、CORS 失败等）这类非 HTTP 错误
用指数退避控制重试节奏
连续快速重试容易引发雪崩或被限流。推荐用指数增长延迟（1s → 2s → 4s → 8s），再加随机抖动（±100ms）避免请求峰值对齐：
- 第 0 次尝试：延迟
1000 * Math.pow(2, 0) + Math.random() * 100 ≈ 1000–1100ms - 第 1 次尝试：延迟
1000 * 2 + Math.random() * 100 ≈ 2000–2100ms - 第 2 次尝试：延迟
1000 * 4 + Math.random() * 100 ≈ 4000–4100ms
实际代码中，延迟计算可统一写成：baseDelay * (1 （<code> 是位运算，比 <code>Math.pow 更轻量）。
限制最大重试次数并设全局超时
必须设硬性上限，否则可能无限挂起。常见策略：
- 默认最多重试 3 次（即总共发起 4 次请求），覆盖大多数瞬时故障
- 配合单次请求超时（如 10s）和整体重试窗口（如总耗时不超过 15s）双重约束
- 使用
AbortController在超时时主动中止正在进行的请求，防止“幽灵请求”堆积
返回结构要清晰，便于业务层处理
重试函数不应只抛错或只返回数据，而应明确区分结果类型：
- 成功时返回
{ success: true, data: responseJson } - 失败时返回
{ success: false, error: err, attempt: 3, lastStatus: 503 } - 这样业务代码可按需决定：是展示“稍后重试”按钮、降级显示缓存、还是上报监控
不复杂但容易忽略。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
