前端表单提交如何防止重复点击：HTML formdata 事件、按钮状态与失败恢复

结算页最容易碰到这类典型场景：用户点了一次提交，按钮没有立刻变化，于是又连点了两下，打开 Network 面板能看到三条几乎同时发出的 POST 请求。前端能在操作入口处挡住大部分这类重复操作，但这类前端拦截只能减少不必要的重复请求，完全不能替代服务端的幂等校验机制。

重复提交为什么不是单纯的按钮样式问题

按钮文字从“提交”变成“提交中”只解决了用户是否看见反馈，真正要控制的是同一个表单实例的状态。鼠标点击、键盘回车和脚本调用都可能进入提交路径；如果只在 click 事件里加锁，回车提交仍然可能绕过它。

另一个容易误判的地方是请求失败。网络错误、接口返回业务失败、用户主动取消，三者都不应该让页面永远停在“提交中”。锁的生命周期要跟请求的 finally 对齐，而不是跟某个按钮动画对齐。

用 formdata 事件收拢提交入口

原生表单在触发提交时，可以通过 formdata 事件拿到浏览器根据表单控件组装的 FormData。它适合做统一的字段补充和日志标记，但重复提交锁仍建议放在 submit 事件，因为锁要尽早阻断第二次提交。

const form = document.querySelector('#profile-form');
const submitButton = form.querySelector('[type="submit"]');
let submitting = false;

form.addEventListener('formdata', (event) => {
  event.formData.set('client_version', 'profile-form-v2');
});

form.addEventListener('submit', async (event) => {
  event.preventDefault();
  if (submitting) return;

  submitting = true;
  submitButton.disabled = true;
  submitButton.dataset.label = submitButton.textContent;
  submitButton.textContent = '提交中…';

  try {
    const response = await fetch('/api/profile', {
      method: 'POST',
      body: new FormData(form),
      headers: { 'X-Request-Source': 'profile-form' }
    });
    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    showMessage('保存成功');
  } catch (error) {
    showMessage('保存失败，请检查网络后重试');
    console.error(error);
  } finally {
    submitting = false;
    submitButton.disabled = false;
    submitButton.textContent = submitButton.dataset.label || '提交';
  }
});

这里的核对点有三个：preventDefault() 只出现一次；锁在发请求前设置；无论 fetch 成功还是抛错，finally 都会恢复按钮。不要在 formdata 监听器里再触发提交，否则很容易形成递归。

失败恢复要保留什么，取消又该怎么处理

失败恢复不是把按钮简单改回原文。用户需要知道这次失败是否已经到达服务器，因此建议区分 HTTP 错误、业务错误和网络异常，并保留表单内容。只有确定没有继续价值的请求，才考虑使用 AbortController 取消。

如果页面提供了“取消上传”或者“离开页面”打断操作的能力，可以把控制器和本次提交的请求绑定在一起：

let activeController;

async function sendForm(form) {
  activeController?.abort();
  activeController = new AbortController();
  try {
    return await fetch('/api/profile', {
      method: 'POST',
      body: new FormData(form),
      signal: activeController.signal
    });
  } finally {
    activeController = null;
  }
}

这段代码不能直接当成“重复提交解决方案”单独拿出来用，它更偏向请求侧的资源管理逻辑：只有明确新请求要替换旧请求的场景下，才主动取消旧请求；下单这类核心操作宁可依赖幂等键和最终状态查询，也不要用主动取消请求的方式来猜测服务端有没有已经处理完逻辑。

键盘回车、无障碍和服务端幂等的边界

原生 能让键盘用户按回车提交，别把按钮改成只监听点击的 div。禁用状态要同步到真实的 disabled 属性，提示文本也要让屏幕阅读器能感知；状态变化较复杂时，可以给结果区域加 aria-live="polite"。

更关键的是，浏览器刷新、代理重试、移动端断网重连都可能让同一个动作再次到达后端。前端可以生成一次提交范围内的幂等键，例如放入 Idempotency-Key 请求头；服务端需要按业务动作保存它，并返回第一次处理结果。

const requestId = crypto.randomUUID();
fetch('/api/orders', {
  method: 'POST',
  headers: { 'Idempotency-Key': requestId },
  body: new FormData(orderForm)
});

上线前用四个观察指标验证效果

校验方案是否生效不能只盯着按钮有没有变灰。可以在前端埋点记录表单提交开始、重复事件被拦截、请求结束、状态恢复支持重试这四个关键节点，再去服务端对比同一幂等键的重复请求到达次数。如果前端拦截统计数据很高但后端依然出现了重复订单，说明还有其他没覆盖到的提交入口，或者幂等校验的实现存在缺口。

• 同一个页面实例的并发提交数量能不能始终稳定控制在1以内。
• 请求失败后的按钮状态恢复逻辑，是不是覆盖了所有可能的异常分支。
• 回车触发提交、鼠标点击提交、辅助设备操作提交是不是都走了同一条提交处理路径。
• 同一个幂等键重复到达服务端时，返回的处理结果是不是完全一致。

相关问题

只给按钮加 disabled 就够了吗？

不够。它挡住了部分手动点击，但还要处理提交事件、脚本触发提交和服务端重复请求的兜底逻辑。

formdata 事件能阻止重复提交吗？

不能。它负责读取或补充表单数据，提交锁应该在 submit 入口设置。

请求失败后应该自动重试吗？

普通查询可以按退避策略重试；创建订单等动作必须先有服务端幂等，再决定是否自动重试。

小结

可靠的表单提交防重是三层逻辑的配合：submit 事件入口用状态锁消化用户快速重复的操作，finally 分支保证请求异常后按钮状态能恢复，服务端用幂等键处理超出前端生命周期之外、网络原因产生的重复请求。把这三层逻辑拆开单独验证，才不会把“点完按钮变灰”这种表面效果当成完整的防重方案。