表单提交防重复的核心是前端按钮禁用与后端幂等校验结合：按钮应在 click 时立即禁用并手动 submit，避免依赖不触发事件的 form.submit()；fetch 场景需在失败后恢复按钮；仅前端禁用不可靠，必须配合服务端唯一 token 或数据库约束。
表单提交后立刻禁用 submit 按钮
用户点一次就发多次请求，根本原因是按钮没被及时“锁住”。最直接的做法是在 onclick 里把按钮设为 disabled，但要注意：必须在表单真正提交前执行，否则可能被浏览器忽略。
常见错误是写成 onsubmit="this.disabled=true" —— 这里的 this 指的是 form 元素，不是按钮，会报错或无效。
- 正确写法是给按钮加
onclick="this.disabled=true; this.form.submit(); return false;" - 如果用
addEventListener，记得先preventDefault()，再手动调用form.submit() - 别只靠前端禁用：后端仍需做幂等校验，否则刷新页面再提交仍会生效
fetch 提交时如何防止重复点击
用 fetch 替代原生表单提交时，按钮禁用逻辑要和异步流程对齐。按钮点了就禁用，但请求失败后得恢复，不然用户没法重试。
容易踩的坑是忘记处理 catch 分支，或者在 finally 里盲目恢复按钮状态，导致网络超时后按钮提前可用。
立即学习“前端免费学习笔记（深入）”；
- 推荐模式：
button.disabled = true→fetch(...)→ 成功/失败后根据业务决定是否恢复 - 避免在
finally直接button.disabled = false，除非你明确接受所有失败都允许重试 - 可加个 loading 状态类（如
button.classList.add('loading')），比纯disabled更友好
为什么 form.submit() 不触发 submit 事件
这是个隐蔽但高频的问题：用 JS 调用 form.submit() 方法时，不会触发绑定在 form 上的 onsubmit 或 addEventListener('submit', ...)，也就意味着防重复逻辑（比如按钮禁用）如果只写在 submit 事件里，会失效。
所以不能把禁用逻辑只塞在 submit 事件中，尤其当代码里存在手动调用 form.submit() 的场景（比如某些 UI 库封装）。
- 禁用按钮的操作，优先放在按钮自己的
click处理函数里 - 如果必须依赖
submit事件，请改用form.requestSubmit()—— 它会触发事件且兼容性较好（Chrome 69+、Firefox 69+） - IE11 不支持
requestSubmit()，若需兼容，只能退回到手动绑定按钮 click
服务端没做幂等，前端防重只是掩耳盗铃
前端禁用按钮只是体验优化，不是安全机制。用户禁用 JS、用 curl 重放、或快速双击（在禁用前完成两次点击），都可能绕过。
真正可靠的防线在后端：比如生成唯一 submit_token 放入表单隐藏域，提交后校验并立即作废；或用数据库唯一索引约束关键操作。
- 前端防重 + 后端幂等，才是完整链路
- 别在按钮上写
disabled就以为万事大吉 - 特别注意支付、下单、评论等不可逆操作，前端提示语也要明确（如“正在提交…”而非“已提交”）
