JavaScript重试机制关键在于智能判断：只对网络错误、503/504等临时性失败重试，禁用400/401/404等永久错误重试，非幂等POST须配合X-Request-ID；采用指数退避（如500ms→1s→2s，上限5秒）与3次限制，结合AbortController超时控制，并区分核心/非核心请求优先级调度。
在弱网环境下，接口调用失败率显著上升——Google《移动网络稳定性报告》指出，4G 网络中约 12% 的请求因瞬时波动失败，其中 70% 可通过合理重试恢复。JavaScript 中实现重试机制，关键不是“多试几次”，而是“只对可恢复错误智能重试”，同时规避重复提交、雪崩加重、资源争抢等问题。
只重试临时性错误，跳过永久性失败
盲目重试会浪费资源甚至引发副作用（如重复下单）。应根据响应状态码和网络异常类型做精准判断：
-
必须重试：网络层错误（
ERR_NETWORK、ERR_CONNECTION_TIMEOUT）、503（服务不可用）、504（网关超时）——这些大概率是临时问题； - 禁止重试：400（参数错误）、401/403（鉴权失败）、404（资源不存在）、500（需结合日志判断，多数为永久错误）；
-
谨慎重试：非幂等请求（如 POST 创建订单）必须配合
X-Request-ID或服务端幂等键，否则重试即风险。
采用指数退避 + 最大次数限制，避免重试风暴
连续重试会加剧弱网拥塞。推荐使用「指数退避」策略：首次失败后等待 500ms，第二次 1s，第三次 2s……并设上限（通常 3 次）：
- 示例逻辑：
delay = Math.min(1000 * 2 ** attempt, 5000)（最大延迟 5 秒）； - 若 3 次全失败，应降级处理（如展示缓存数据、提示“网络不佳，请稍后重试”）；
- 避免固定间隔（如每次等 1 秒），它在弱网下易形成请求脉冲，加重服务器压力。
与超时控制协同，防止卡死或无效等待
重试必须搭配单次请求超时，否则一次慢请求可能拖垮整个重试流程：
立即学习“Java免费学习笔记（深入）”；
- Fetch 场景：用
AbortController设置单次请求超时（建议 8–12 秒，弱网略放宽）； - Axios 场景：配置
timeout: 10000，并在拦截器中统一捕获AxiosError.ECONNABORTED； - 注意：超时错误属于可重试类型，但需确保 abort 后不残留未清理的连接或监听器。
优先保障核心请求，非核心请求可降级或延后
弱网下浏览器对同一域名仅维持约 6 个并发 TCP 连接。若所有请求平等发起，登录、支付等关键请求可能被埋没在队列中：
- 将请求分为 核心（用户主动操作、阻断流程）和 非核心（埋点、推荐列表、统计上报）；
- 核心请求启用重试 + 较短退避 + 高优先级调度（如用
fetch(..., {priority: 'high'})，Chrome 支持）； - 非核心请求可取消重试、直接返回默认值，或延迟到网络恢复后再触发。
