JS请求重试需明确失败类型、用指数退避+抖动控制节奏、保证幂等性与请求隔离、暴露可控重试入口；不可重试错误如401/403/400/500，可重试如超时、502/503/429。
JS 请求重试机制不是加个 for 循环或 setTimeout 就完事，真正防坑的关键在于：明确失败类型、控制重试节奏、避免状态污染、兼顾用户体验。下面从设计原则到落地细节，帮你避开常见陷阱。
区分可重试与不可重试的错误
不是所有失败都该重试。网络超时、502/503/429 等临时性错误适合重试；而 401（未登录）、403（权限不足）、400（参数错误）或 500（服务端逻辑异常）通常重试无意义，甚至引发副作用。
- 用响应状态码 + error.name + error.message 综合判断，比如 fetch 抛出的 TypeError 多是网络中断，可重试；AbortError 是主动取消，不应重试
- 对 Axios，可检查 error.response?.status 和 error.request 是否为空来区分响应失败还是请求未发出
- 建议封装一个 shouldRetry(error, attempt) 函数，把判断逻辑收口，便于统一维护和测试
用指数退避 + 随机抖动控制重试节奏
连续重试会加剧服务压力，固定间隔易引发请求洪峰。推荐使用「指数退避 + 随机抖动」策略：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 第 n 次重试延迟 ≈ baseDelay × 2n−1 + jitter（jitter 是 0～100ms 随机值）
- 设置最大延迟上限（如 3s），防止单次等待过久影响体验
- 总重试次数建议设为 3～5 次，超过则直接失败并透出原始错误
- 示例：baseDelay=500ms，第 1 次等 500±100ms，第 2 次等 1000±100ms，第 3 次等 2000±100ms
保证幂等性与请求隔离
重试可能造成重复提交（如创建订单）、状态错乱（如多次调用 toggle 接口）。必须从源头规避：
- 后端接口应支持幂等 key（如 Idempotency-Key header），前端每次重试生成新 key 或复用首次 key（根据语义决定）
- 避免在重试中修改请求体（如自增 version 字段、更新 timestamp），除非业务明确需要
- 每个请求实例保持独立上下文：不要共享 abortController、token 或 loading 状态；重试应新建 AbortSignal
- 对 GET 请求默认可安全重试；POST/PUT/DELETE 必须确认后端幂等支持，否则需 UI 层拦截二次操作（如按钮置灰+防重复点击）
暴露可控的重试入口与用户反馈
自动重试不能替代用户知情权。关键交互点要提供人工干预能力：
- 首次失败后，显示「正在重试…（2/3）」提示，而非静默等待
- 最终失败时，给出明确原因（如「网络不稳定，请重试」或「服务暂不可用」），并附「重试」按钮
- 按钮点击应触发全新请求流程（含新 abortController、新时间戳、新幂等 key），而非简单调用上一次 retry 函数
- 对长耗时操作（如文件上传），考虑支持「取消重试」，而不仅是取消当前请求
重试机制的价值不在“多试几次”，而在“试得明白、试得安全、试得可控”。写好它，既减少白屏和报错，也降低后端压力和用户投诉。不复杂但容易忽略。
