关键在于聪明重试：只对可恢复错误（如网络中断、503/504）重试，禁用4xx及多数500；采用指数退避+抖动控制节奏；单请求限重试3次，全局控并发，并协同后端实现熔断与幂等保障。
避免因频繁重试加重后端压力，关键不是“少重试”，而是“聪明地重试”——只在该重试时重试、用合理节奏重试、并主动为服务端减负。
只对可恢复错误重试
盲目重试所有失败请求是最大误区。必须区分错误类型：
-
可重试：网络中断（
ERR_NETWORK）、超时（ERR_CONNECTION_TIMEOUT）、503/504 等临时性服务不可用 - 不可重试：4xx 错误（如 400 参数错误、401 未授权、404 不存在）、500 内部错误（多数场景下重试无意义）
在 fetch 或 axios 拦截器中显式判断状态码和错误类型，非可重试错误直接抛出，不进入重试流程。
用指数退避 + 抖动控制节奏
连续重试不能固定间隔（比如每次都等 1 秒），否则容易形成请求洪峰。应采用：
- 基础延迟 × 2attempt（如第 1 次等 500ms，第 2 次等 1000ms，第 3 次等 2000ms）
- 叠加随机抖动（如 + 0–300ms），打破客户端同步重试模式，避免大量请求在同一毫秒抵达
这样既给了服务端恢复时间，又分散了重试流量，显著降低雪崩风险。
限制重试总次数与全局并发
单个请求重试不是孤立行为，需从系统层面约束：
- 单请求最多重试 3 次（超过大概率是真故障，再试无益）
- 前端整体并发请求数设上限（如用 PromisePool 或自定义队列），避免多个请求同时进入重试循环
- 对同一接口或同一服务地址，增加短时熔断逻辑（例如 1 分钟内连续失败 5 次，则跳过该节点 30 秒）
配合后端做协同降压
前端重试策略要和后端能力对齐：
- 请求头中带上
X-Retry-Attempt: 2，让后端识别重试请求，可降级日志、跳过部分校验 - 对非幂等操作（如 POST 创建订单），前端重试前先检查是否已成功（例如查本地缓存、读取上一次响应 ID），或依赖后端幂等键（
Idempotency-Key）保障安全 - 服务端返回
Retry-After响应头时，前端应优先遵守其建议的等待时间，而非固执执行本地退避逻辑
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
