form.submit事件是唯一可靠拦截点，需监听form元素的submit事件批量禁用所有submit按钮，并在e.preventDefault()后、请求前执行；fetch需配AbortController中止上一个请求；submit_token须由后端生成、绑定session且一次性消费。
form.submit 事件才是唯一可靠拦截点
只给按钮绑 onclick 或用 onsubmit 内联写法，漏掉回车提交、form.requestSubmit() 调用、多按钮场景。真正能覆盖所有提交路径的，只有监听 form 元素的 submit 事件。
常见错误包括：
- 只禁用当前点击的按钮，但表单可能有“保存”“保存并关闭”多个
type="submit"控件 - 没调
form.checkValidity()就直接禁用，导致校验失败后按钮卡死，用户无法修改重试 - 用
form.submit()触发提交，它绕过submit事件，禁用逻辑完全失效
正确做法是：在 submit 事件中，用 form.querySelectorAll('button[type="submit"], input[type="submit"]') 批量禁用，且必须放在 e.preventDefault() 后、实际请求前。
fetch 提交时必须配 AbortController
按钮禁用只锁 UI，挡不住快速点击下已发出的多个 fetch 请求。尤其在慢网或接口响应长时，用户点两下，后端就收到两个并发请求。
立即学习“前端免费学习笔记（深入）”；
关键不是“防点”，而是“中止上一个”：
- 声明一个全局变量
currentController，类型为AbortController - 每次提交前先执行
currentController?.abort()，再新建实例赋值 - 把新实例的
signal传进fetch的options -
catch中显式过滤AbortError，避免误报业务异常
注意：AbortController 不支持 IE；老项目需降级用 Promise.race([fetch(), timeoutPromise]) 模拟中止。
后端 submit_token 必须绑定 session 且一次性消费
前端所有控制都可被绕过。真正防重靠后端——但随便生成个 Math.random() 值塞进隐藏字段，等于没做。
有效的 submit_token 需满足：
- 由后端生成（如 UUID），签名不可伪造，有效期建议 5–15 分钟
- 绑定当前用户
session_id和具体表单类型（如user_register_form），不能跨表单复用 - 服务端收到后，先查 Redis/DB 是否存在且未使用；校验通过立即标记为“已消费”，再次提交返回
400 Bad Request - 若用
fetch提交，需手动取document.querySelector('[name="submit_token"]').value拼进body，不能依赖表单自动携带
别信 onclick="this.disabled=true" 这类内联写法
看着省事，实则三处致命缺陷：
- 回车触发表单提交时，
onclick根本不执行 - 多个
type="submit"按钮时，只禁了当前这个，其他仍可点 - 请求失败后没有恢复逻辑，按钮永远灰掉，用户只能刷新页面
更隐蔽的问题是：它违反 HTML/JS 分离原则，后续加校验、埋点、AB 测试都得改 HTML，维护成本陡增。
真正难的不是写几行禁用代码，而是让禁用、中止、token 校验这三层动作在任意失败路径下都能自洽恢复——比如 fetch 被 abort、网络超时、后端返回 500，每种情况都要确保按钮可重试、token 不残留、并发请求不堆积。
