重试逻辑必须放在响应拦截器中。因为只有收到响应（含网络错误、超时、状态码异常等）后才能判断是否重试；请求拦截器无法感知失败，不适合放置重试控制逻辑。
重试逻辑应放在请求拦截器还是响应拦截器？
重试必须放在响应拦截器中。因为只有收到响应（包括网络错误、超时、状态码异常等）后，才能判断是否需要重试。请求拦截器只在发请求前执行，无法感知失败，也不适合放重试控制逻辑。
用 Axios 实现带次数限制和延迟的重试
Axios 响应拦截器中可通过 config 配置自定义字段（如 retry、retryDelay、retryCount）来控制重试行为。每次失败时检查是否还能重试，若可以，则修改 config 后用 axios.request() 重新发起。
- 首次请求不带 retry 字段；拦截器捕获失败后，给 config 添加或递增 retryCount，并设置 retry = true
- 重试前用 setTimeout 模拟延迟（如指数退避：delay = 2 ** retryCount * 100）
- 超过最大重试次数（如 3 次）则拒绝 Promise，让业务层捕获最终错误
- 注意排除 4xx 类客户端错误（如 401、403），它们重试无意义，应直接 reject
Fetch 实现重试需手动封装，推荐用 async/await + 递归
Fetch 本身无内置拦截器机制，需封装一个 retryFetch 函数，在 catch 中判断错误类型和状态码，决定是否递归调用自身。
- 把 url、options、maxRetries、currentRetry、baseDelay 等作为参数传入
- fetch 失败（网络中断、AbortError）或 response.status >= 500 时触发重试
- 每次重试前 await new Promise(r => setTimeout(r, delay))，delay 可按次递增
- 递归调用时更新 currentRetry，到达 maxRetries 后 throw 原始错误
注意事项与边界情况
重试不是万能的，必须规避副作用和资源浪费。
- 禁止对非幂等请求重试：如 POST /order（重复下单）、PUT /user（重复更新），除非后端支持幂等 Token
- GET 和 HEAD 请求默认可重试；DELETE 一般也可，但需确认语义是否安全
- 手动 AbortController 的信号需透传到重试请求，避免旧请求残留
- 重试日志建议打在拦截器里（如 “Retry #2 for GET /api/data”），方便排查
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
