disabled不是可靠方案，因其无法拦截回车提交、连点仍可能发送多请求，且JS错误会导致按钮永久禁用；应通过submit事件+布尔标记+同步form.submit()控制，并配合服务端幂等校验。
为什么 disabled 不是可靠方案
表单重复提交时禁用提交按钮看似简单，但实际会破坏原生表单行为：比如按回车触发提交时，disabled 的按钮不参与事件冒泡，submit 事件仍会触发；若用户快速连点，可能在禁用前已发出多个请求；更关键的是，禁用后若 JS 报错或未执行完，按钮永远卡死，用户无法重试。
form.submit() 调用前拦截多次触发
原生表单的真正提交入口只有两个：用户点击 <button type="submit">、<input type="submit">，或按回车（前提是表单内有可聚焦的 submit 控件）。所有这些最终都走 form.submit() 方法 —— 但注意：form.submit() 是同步调用且**不触发 submit 事件**，所以不能靠事件监听去防重。
实操建议：
- 给表单绑定
submit事件，在回调里用event.preventDefault()阻止默认提交 - 用一个布尔标记（如
isSubmitting）控制是否允许进入提交逻辑 - 标记设为
true后立即调用form.submit()（此时无事件循环干扰） - 不要在标记为
true后再做异步操作（如fetch），否则无法阻止原生提交
示例关键片段：
立即学习“前端免费学习笔记（深入）”；
let isSubmitting = false;
form.addEventListener('submit', (e) => {
if (isSubmitting) {
e.preventDefault();
return;
}
isSubmitting = true;
// 此处可加 loading 状态，但不可 await
form.submit(); // 原生提交，不触发 submit 事件
});
服务端必须配合幂等校验
前端任何拦截都是“尽力而为”，网络延迟、刷新、开发者工具绕过都可能让重复请求到达后端。所以必须在服务端落地幂等控制：
- 客户端生成唯一
idempotency-key（如 UUID 或基于表单数据的哈希），通过请求头或字段传入 - 服务端收到后先查该 key 是否已处理成功，若是则直接返回上次结果（HTTP 200 + body）
- 注意：不能只靠数据库唯一索引报错来判断，因为失败重试可能因网络超时未收到响应，需明确区分“处理中”和“已完成”状态
常见错误现象：409 Conflict 返回后前端没重试逻辑，用户以为失败而反复提交 —— 这反而加剧问题。
回退/刷新场景下的状态残留问题
用户提交后点浏览器后退，再前进，或刷新页面，isSubmitting 标记会重置，但服务端可能还在处理上一次请求。这时候用户看到的仍是“可提交”状态，极易误操作。
解决方案有限但有效：
- 提交成功后立即
location.replace()跳转，避免用户能返回原表单页 - 若必须留在当前页（如 SPA），提交后清空表单并重置
isSubmitting，同时在 URL 中添加临时参数（如?submitted=1），页面加载时检测并提示“已提交，请勿重复操作” - 不依赖 localStorage 存标记 —— 它跨标签页共享，容易误判
最易被忽略的点：前端防重和后端幂等不是二选一，而是必须共存；且 form.submit() 的调用时机比按钮禁用更可控，但一旦写错顺序（比如先发 fetch 再调 submit），整个防线就失效了。
