关键在于默认不重试非幂等请求，仅对明确标记幂等（如idempotent: true或含idempotency-key）且服务端确认支持的请求启用重试；get/head/options/put/delete可基础过滤重试，post/patch需业务标识；4xx客户端错误、无key的post/patch、服务端明确拒绝等场景禁止重试。
关键不在“区分”，而在于默认不重试非幂等请求，只对明确可重试的请求启用重试逻辑。HTTP 方法语义和业务意图共同决定是否允许重试，不能仅靠方法名做静态判断。
按 HTTP 方法语义做基础过滤
浏览器和主流请求库（如 axios）默认遵循 RFC 规范：
- GET、HEAD、OPTIONS、PUT、DELETE 被视为天然幂等，网络失败或 5xx 时可安全重试
- POST 和 PATCH 默认不重试——因为它们通常代表“创建”或“部分更新”，多次执行可能产生多条记录或状态错乱
- 但注意：PUT 是否真幂等，取决于后端实现。如果 PUT 是“全量覆盖式更新”（如
PUT /users/123 {name: "Alice"}），那它是幂等的；如果是“追加式更新”（如PUT /cart/items添加商品），那就不是
用业务标识主动标记幂等性
光靠 HTTP 方法不够，必须结合业务上下文。推荐在请求发起前显式声明：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 给请求配置一个
idempotent: true标志位，例如：axios.post('/api/orders', data, { idempotent: true }) - 封装请求函数时，支持传入
idempotencyKey字段。有该字段即表示此请求已按幂等流程设计（含唯一 key、服务端校验、结果缓存） - 没有
idempotencyKey的 POST 请求，即使配置了重试次数，也应跳过重试逻辑
服务端响应反向验证幂等状态
前端不能只信“自己认为幂等”，还要看服务端是否真正履行了幂等承诺：
- 收到
200 OK且响应头含X-Idempotent-Executed: true→ 确认是重放结果，可直接使用缓存响应 - 收到
409 Conflict且响应体含完整业务数据（如订单号、时间戳）→ 表明服务端已处理，本次为重复提交，仍算成功 - 收到
500或超时，但请求没带Idempotency-Key→ 不重试，避免副作用；若带了 key，则按指数退避重试
禁止重试的明确信号
以下情况必须中断重试流程，直接报错或交由用户决策：
- 响应状态码为
400 Bad Request、401 Unauthorized、403 Forbidden、422 Unprocessable Entity—— 这些是客户端错误，重试无意义 - 响应中明确返回
{"error": "non-idempotent-operation"}类业务提示 - 原始请求未携带
Idempotency-Key，且方法为 POST 或 PATCH
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
