弱网下表单重复提交风险更高，因请求状态不可知导致超时误判、用户刷新或重试；需前端禁用按钮+中止请求+生成Idempotency-Key，后端结合用户标识与业务类型做Redis幂等校验。
为什么弱网下表单重复提交风险更高
弱网不是“慢一点”，而是请求状态不可知：fetch 可能卡在 pending、超时后前端误判为失败、用户手动刷新或重点——这些都会触发第二次请求。浏览器原生 POST 不会自动重发，但 JS 主动提交（fetch 或 XMLHttpRequest）完全没这层保护。更麻烦的是，用户看到“无响应”就猛点提交按钮，而前端若只靠 button.disabled = true，却没处理回车提交、JS 直接调用 form.submit() 或页面 reload，防重就形同虚设。
前端必须做的三件事：禁用 + 中止 + 标记
光禁用按钮只是障眼法，真正要拦住并发和重试，得组合动作：
- submit 事件一触发，立刻禁用所有
button[type="submit"]和input[type="submit"]，包括“保存并继续”这类辅助按钮 - 用
AbortController管理 fetch 请求：每次新提交前调currentController?.abort()，避免上一个未完成请求“幽灵执行” - 生成唯一
Idempotency-Key：推荐crypto.randomUUID()（现代浏览器），fallback 可用Date.now() + Math.random().toString(36).substr(2, 9)，作为请求头传给后端 - 重试逻辑必须满足三个条件同时成立：
navigator.onLine === true、上次请求明确返回错误（非超时）、document.hidden === false；最多重试 1 次，间隔 ≥ 2s
别用 setInterval 轮询重试——它会在弱网下堆积大量 pending 请求，最终集体爆发。
后端幂等校验不能省略任何一环
前端再严密，绕过成本也极低。服务端校验必须绑定业务上下文，不能只存个随机字符串：
立即学习“前端免费学习笔记（深入）”；
- 幂等键必须包含用户标识（如
userId）、业务类型（如"order_create"）和客户端传来的Idempotency-Key，拼成唯一 key 存 Redis，例如idemp:u123:order_create:abc123... - 有效期建议 24 小时以上，覆盖弱网超时重试窗口；太短会导致合法重试被拒，太长增加重放风险
- 校验失败必须返回明确 HTTP 状态码（如
400 Bad Request）和可解析的错误体，前端据此恢复按钮、提示“请勿重复提交”而非静默吞掉 - 不要用内存 Map（如
HashMap）做幂等缓存——单机部署才有效，集群环境下直接失效；必须用 Redis 或带分布式锁的 DB
跳转与刷新场景最容易漏掉的细节
提交成功后跳转，不是加个 window.location.href = '/success' 就完事：
- 跳转必须放在业务成功判断之后，比如
response.data.code === 0 && response.data.isDuplicate === false，否则“已存在”也跳走，用户 F5 就重发 - 服务端返回
303 See Other比前端跳转更可靠——浏览器自动用 GET 访问目标页，天然规避 POST 重发 - 跳转前清空表单（
form.reset()）或重置按钮状态，否则用户回退后看到“提交中…”还点不了，体验断裂 - 绝对不要在
catch块里跳转到错误页的同时保留原始表单数据——这等于鼓励用户再点一次
弱网下的幂等性，本质是把“不确定”变成“可判定”：前端负责让同一份数据最多发出一次，后端负责让同一份标识最多生效一次。两者缺一，防重就只剩一半力气。
