默认仅对get、head、options等幂等请求自动重试；post/put/delete等非幂等请求重试须携带idempotency-key并由后端幂等校验；400/401/403/404/409等错误不可重试，仅限网络超时及5xx临时错误触发重试。
只对幂等请求默认重试
GET、HEAD、OPTIONS 这类不改变服务端状态的请求，天然满足幂等性，可放心加入自动重试逻辑。比如轮询订单状态、获取配置信息等场景，网络抖动导致失败后重试不会引发副作用。
而 POST、PUT、DELETE 需谨慎对待：
- POST 创建资源（如下单）默认非幂等，重复提交可能生成多笔订单
- PUT 全量更新若目标明确（如 PUT /api/users/123），且数据一致，通常幂等
- DELETE 删除同一资源多次，结果相同，属于幂等操作
非幂等请求重试必须带幂等标识
如果业务确实需要对 POST 等非幂等请求重试（例如用户点击“提交支付”后无响应），必须由前后端协同保障幂等性。前端需生成唯一 Idempotency-Key 请求头，值可为 UUID 或业务唯一 ID（如订单号 + 时间戳）：
- 每次重试都复用同一个 Idempotency-Key，不能每次生成新值
- 后端收到该 Key 后，先查是否已处理过；若已存在，则直接返回上次结果，不再执行业务逻辑
- Key 应设置合理过期时间（如 24 小时），避免长期占用存储
重试前主动过滤不可重试错误
不是所有失败都适合重试。应在重试循环中跳过明确表示“不该再试”的错误类型：
- 400 Bad Request：参数错误，重试无效
- 401 Unauthorized / 403 Forbidden：权限问题，需重新鉴权而非重试
- 404 Not Found：资源不存在，重试无意义
- 409 Conflict：业务冲突（如库存不足），需用户干预
- 仅对 网络超时、502/503/504 等服务端临时错误 触发重试
封装重试函数时内置幂等校验意识
写 fetchWithRetry 类工具函数时，不要只关注“重试次数”和“延迟”，还要留出接口支持幂等控制：
- 增加
isIdempotent: boolean参数，默认true（仅对 GET 等开启） - 对非幂等请求，强制要求传入
idempotencyKey，否则拒绝执行重试 - 在日志中记录是否启用幂等保护、Key 值摘要（脱敏）、重试触发原因，便于问题追溯
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
