表单防重需前后端协同：前端提交时禁用所有提交按钮并设提示，但不可依赖其恢复；后端须用带签名、有时效、绑定session和表单类型的submit_token校验并标记已消费，配合PRG模式或AbortController确保幂等。
表单提交后按钮立刻禁用
用户点一次就触发多次请求，往往不是后端没防，而是前端按钮没锁住。浏览器里反复点提交按钮，submit事件会照常触发，后端哪怕做了幂等也扛不住高频垃圾请求。
最直接有效的做法：监听表单的 submit 事件，一触发就禁用所有提交按钮（包括 type="submit" 和带 onclick 的 button）：
form.addEventListener('submit', function(e) {
const buttons = form.querySelectorAll('button[type="submit"], input[type="submit"]');
buttons.forEach(btn => {
btn.disabled = true;
btn.textContent = '提交中…';
});
});
- 别只禁用一个按钮——表单可能有多个提交入口（比如“保存”“保存并继续”）
- 禁用后记得恢复？不建议自动恢复。失败时应由 JS 显式重置，否则用户可能误以为成功了
- 注意：禁用按钮不会阻止通过键盘回车触发表单提交，所以核心还得靠服务端校验
后端生成并校验一次性 token
前端禁用只是障眼法，真正防重的关键在服务端。常见错误是只依赖前端 timestamp 或随机数，这些都可被绕过。
标准做法是：每次渲染表单时，后端生成一个带签名、有时效的 csrf_token 或专用 submit_token，存入 session 并嵌入表单隐藏域；提交时校验该 token 是否未使用、未过期、签名正确，且校验通过后立即从服务端标记为“已消费”。
立即学习“前端免费学习笔记（深入）”；
- token 必须绑定用户 session + 表单类型（如
order_form），不能全局复用 - 有效期建议 5–15 分钟，太短影响弱网用户，太长增加重放风险
- 校验失败必须返回明确错误（如
400 Bad Request+"invalid or consumed submit_token"），前端据此提示用户刷新页面
用 POST-Redirect-GET 避免 F5 重复提交
用户填完表单点提交，后端处理完直接返回 302 Redirect 到结果页，而不是直接渲染成功页。这样用户按 F5 刷新的是结果页（GET），不会再次 POST。
- 这是 HTTP 协议层最稳妥的防重机制，和前端 JS 无关，但要求后端逻辑支持跳转
- 注意：重定向前必须确保业务操作已成功落库或完成关键步骤，否则跳转后状态不一致
- 如果业务需要在提交页显示错误信息（比如字段校验失败），就不能跳转，此时必须配合 token + 前端禁用双保险
避免在 AJAX 提交中漏掉 loading 状态管理
用 fetch 或 axios 提交时，很多人只加了个 loading=true，但没处理网络超时、请求被取消、Promise 拒绝等情况，导致按钮卡死或重复触发。
- 务必在
finally块里重置按钮状态，而不是只在then或catch中写 - 对同一表单，建议用
AbortController主动取消上一次未完成的请求，避免旧请求响应回来覆盖新结果 - 不要用
setTimeout模拟防抖来代替真实校验——用户真点了两次，你只发一次，第二次数据就丢了
disabled，而是 token 生命周期怎么管、失败路径怎么兜底、重定向和 AJAX 怎么混用不打架——这些细节一漏，防重就形同虚设。 
