真正可控的防重入口只有submit事件监听器：用全局布尔变量（如isSubmitting）作守卫，event.preventDefault()后立即同步调用form.submit()，顺序不可错，禁用按钮仅为辅助视觉反馈。
submit事件里用布尔标记拦截，别碰form.submit()异步链
原生表单的重复提交根本拦不住——用户点按钮、按回车、甚至脚本调用form.submit()，都会触发提交。靠disabled按钮只是障眼法，它不阻止submit事件本身，更拦不下回车提交。真正可控的入口只有一个：submit事件监听器。
关键不是“禁用”，而是“截断”：在事件回调里用一个全局布尔变量（如isSubmitting）做守卫，event.preventDefault()阻止默认行为，然后立刻调用form.submit()完成原生提交——注意，这个调用是同步的，且不会再次触发submit事件，所以不会陷入递归或漏判。
- 标记必须在
preventDefault()之后、form.submit()之前设为true，顺序错就失效 - 千万别在标记后加
await fetch()或setTimeout，那会放行原生提交逻辑 - 如果表单有多个
button[type="submit"]，只锁一个按钮没用；布尔标记才是统一闸门
禁用按钮只是辅助，且必须覆盖所有submit控件
视觉反馈对用户很重要，但禁用操作不能替代布尔守卫。用户刷新页面后disabled状态丢失，而布尔变量在事件监听器内每次都是新鲜的。不过，禁用仍有必要——防止连点时按钮文字还在动、用户误以为没响应。
实操上要选中所有可能触发表单提交的元素，不只是第一个按钮：
立即学习“前端免费学习笔记（深入）”；
- 用
form.querySelectorAll('button[type="submit"], input[type="submit"]')批量获取 - 禁用时同步改
textContent或加loadingclass，别只设disabled - 失败后必须显式恢复：服务端返回 4xx 或网络错误时，要重置
disabled = false和文字，否则用户卡死 - 别用
onclick="this.disabled=true"内联写法——它捕获不到回车，也管不了其他 submit 控件
隐藏域传submit_token是HTML层唯一有效配合点
HTML本身没有防重属性，novalidate、autocomplete、甚至disabled静态写死，全都不起作用。唯一能靠纯HTML参与防重的，是把后端下发的一次性令牌塞进隐藏域：
<input type="hidden" name="submit_token" value="f8a2e7d1-9c4b-4f0a-b3e5-1a2c3d4e5f6g">
这个字段本身不防重，但它让token随表单自动发出，前端不用额外JS取值拼请求。前提是：
- value必须由后端生成，绑定当前session + 表单类型，不能前端
Math.random()伪造 - 每次页面加载都得刷新token，缓存或复用等于白搭
- 若你改用
fetch提交，就得手动document.querySelector('[name="submit_token"]').value取值 - token校验失败时，后端必须返回明确错误（如400 + "invalid or consumed submit_token"），前端据此提示刷新
别信“防抖”“节流”能替代submit事件守卫
用debounce包装点击事件听着聪明，实际漏洞百出：它拦不住回车提交，拦不住form.requestSubmit()，也拦不住用户新开标签页粘贴URL重发。而且防抖时间设短了没用，设长了伤害体验。
更危险的是，有人把防抖套在fetch外层，却忘了原生表单提交完全绕过这层——两个机制并存，反而造成逻辑混乱。
- 防抖只适合非表单场景（如搜索框输入）；表单防重必须锚定
submit事件 - 如果用了
fetch而非原生提交，那就要自己维护pending状态 +AbortController，和布尔守卫是两套逻辑，不能混用 - 所有方案都得接受一个事实：前端永远只是“尽力而为”。哪怕JS跑得再稳，用户F5、禁用JS、用curl发包，请求照样能到后端——所以幂等校验不是可选项，是必选项
