JavaScript幂等接口的核心是客户端用唯一Idempotency-Key标记业务操作并重试，服务端校验防副作用；需封装请求层缓存Promise、指数退避重试，并配合服务端返回X-Idempotent-Executed或409带原始结果。
JavaScript 中处理幂等性接口的自动重试与去重，核心在于客户端主动控制请求唯一性，配合服务端校验（如 Idempotency-Key），而非仅靠前端“猜”是否成功。关键不是避免重试，而是让重试不产生副作用。
用唯一请求标识（Idempotency Key）标记每次业务操作
每次发起幂等请求前，生成一个全局唯一、可追溯的 key（如 UUID v4），并随请求一起发送（通常放在 HTTP Header 中，如 Idempotency-Key: 8a2b3c...-d1e2）。这个 key 应绑定到具体业务意图（例如“用户提交订单 #123”），而不是单纯绑定到请求时间或随机数。
- 浏览器中可用
crypto.randomUUID()（现代环境）或self.crypto.subtle.digest()+ 时间戳 + 随机盐生成稳定 key - 若需页面刷新后仍可续传（如大表单），可将 key 存入
sessionStorage，并在提交成功后清除 - 避免用 Math.random() 或 Date.now() 单独生成——易重复，且无法跨实例复用
封装请求层，自动注入、缓存与拦截重复请求
在 axios/fetch 封装层统一处理：首次请求时记录 key → 发起请求 → 若失败则按策略重试（带相同 key）→ 若收到 409/422 或服务端返回 “已处理” 状态，则直接返回缓存的成功响应。
- 维护一个内存 Map：
const idempotentCache = new Map<string promise>>()</string>，以 key 为键，缓存对应请求的 Promise - 同一 key 的并发请求自动复用同一个 Promise，天然防重复提交（不是防重试，是防多点触发）
- 重试逻辑建议用指数退避（如 100ms → 300ms → 700ms），并限制最大重试次数（通常 2–3 次）
服务端响应需明确反馈幂等状态，前端据此决策
光靠 HTTP 状态码不够。理想情况下，服务端应在成功响应中返回 X-Idempotent-Executed: true 或在 body 中包含 "idempotent": true 字段；对重复请求，应返回 200（非 4xx）并附带原始结果（RFC 兼容做法），或明确返回 409 Conflict + 原始响应体。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 前端收到 200 +
X-Idempotent-Executed: true，说明是重放结果，可安全使用 - 收到 409 且 response body 含完整业务数据（如订单号、支付状态），也应解析并视为成功
- 避免把 409 当错误 throw，否则重试逻辑会中断，反而破坏幂等保障
用户交互层配合：禁用按钮 + 可见反馈，但不替代技术方案
UI 层禁用提交按钮、显示 loading 是必要体验优化，但它只是辅助手段，不能替代幂等机制——网络延迟、刷新、多标签页等场景下，仅靠 UI 锁无法保证请求唯一性。
- 按钮禁用应基于请求 key 的生命周期，而非单纯 pending 状态（防止 key 冲突导致误放行）
- 若用户强制刷新页面，已有 key 丢失，新请求被视为新操作——这符合预期，无需强行恢复
- 对敏感操作（如支付），可在提交前弹窗二次确认，但确认本身不解决幂等，只降低误触概率
不复杂但容易忽略：幂等性是前后端协作契约，前端负责生成、传递、识别 key 并合理响应；服务端负责存储、比对、返回一致结果。单靠任何一方都无法真正落地。
