前端表单提交为什么会重复触发：按钮禁用、请求幂等与恢复时机

订单按钮明明只点了一次，接口日志却出现两条相同的创建请求，通常不是一个单独的“按钮太快”问题。原生表单会触发 submit 事件，代码里的点击监听可能又手动调用一次提交；网络失败后恢复按钮、浏览器重试或用户重新打开页面，还会让同一业务意图再次抵达服务端。

先做一个只会发一次请求的最小提交器

先把入口收拢到 submit。按钮保留 type="submit"，监听器调用 event.preventDefault() 后自行发送请求，这样按 Enter 和鼠标点击走的是同一条路径。

  提交订单


const form = document.querySelector('#order-form');
const submitButton = document.querySelector('#submit-order');
let submitting = false;

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

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

  try {
    const response = await fetch('/api/orders', {
      method: 'POST',
      body: new FormData(form),
      headers: { 'Idempotency-Key': crypto.randomUUID() }
    });
    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    submitButton.textContent = '已提交';
  } catch (error) {
    submitting = false;
    submitButton.disabled = false;
    submitButton.textContent = '重新提交';
    console.error('order submit failed', error);
  }
});

这个版本先解决两个常见重复源：没有再给按钮绑定第二个请求监听，也没有让浏览器的默认提交和 fetch 同时发生。submitting 是页面内的快速闸门，disabled 则把视觉状态同步给用户。

为什么只禁用按钮仍然挡不住重复订单

按钮状态只存在于当前页面实例。用户打开两个标签页、页面在请求完成前刷新，或者同一个请求经过代理重试时，服务端看到的仍然可能是两次 POST。更隐蔽的情况是客户端已经收到超时，但服务端其实完成了写入；此时直接生成新请求就会再创建一条记录。

所以前端锁解决的是“当前交互不要连续发起”，服务端幂等解决的是“同一个业务意图无论到达几次都只产生一个结果”。两层职责不能互换。

把幂等键从一次请求提升为一次业务意图

上面的示例把 crypto.randomUUID() 写在请求表达式里，失败重试会生成新键，这不符合幂等语义。应在用户开始一次提交时创建键，并在同一轮重试中复用：

const requestKey = crypto.randomUUID();

async function createOrder(form, requestKey) {
  const response = await fetch('/api/orders', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Idempotency-Key': requestKey
    },
    body: JSON.stringify({
      sku: form.elements.sku.value,
      quantity: Number(form.elements.quantity.value)
    })
  });

  if (!response.ok) throw new Error(`HTTP ${response.status}`);
  return response.json();
}

// 同一个 requestKey 的重试仍代表同一笔业务
await createOrder(form, requestKey);

服务端可以把幂等键和业务主体、请求摘要、最终响应一起保存。第一次请求创建成功后，后续相同键直接返回已保存的响应；同一个键却携带不同商品或数量时，应返回参数冲突，而不是覆盖原订单。

失败时什么时候恢复按钮，什么时候保持锁

恢复按钮不是越积极越好。确定请求没有离开浏览器的校验错误可以立即恢复；网络断开或请求超时则应该让用户看到“查询结果”或“再次确认”，并继续使用原幂等键。只要服务端已经返回成功，按钮就不能恢复成“提交订单”。

function setSubmitting(value) {
  submitting = value;
  submitButton.disabled = value;
  submitButton.textContent = value ? '提交中…' : '提交订单';
}

async function submitOnce() {
  const requestKey = crypto.randomUUID();
  setSubmitting(true);
  try {
    const result = await createOrder(form, requestKey);
    submitButton.textContent = `订单 ${result.orderNo} 已创建`;
  } catch (error) {
    // 校验失败可恢复；超时应进入查询/确认流程，不能盲目生成新键
    if (error.name === 'TypeError') {
      submitButton.textContent = '网络异常，请查询订单状态';
      return;
    }
    setSubmitting(false);
  }
}

如果业务允许取消，可以用 AbortController 终止仍在浏览器中的等待，但取消只影响客户端等待，不等于服务端回滚。取消后再次提交前，先用原幂等键查询状态。

运行检查：用四个动作复现重复提交

1. 连续快速点击按钮，确认 Network 面板只有一个 POST /api/orders。
2. 光标停在输入框按 Enter，确认它和鼠标点击共用一个 submit 监听器。
3. 在请求挂起时刷新页面，再检查服务端是否按幂等键返回同一个订单号。
4. 把数量改成 2 后重新提交，确认客户端生成新键，服务端创建的是新的业务意图。

验收时不要只看按钮是否变灰。真正的结果应同时包含浏览器请求数、请求头里的幂等键、服务端去重记录和最终订单号。

常见问题

只用 event.preventDefault() 能保证不重复吗？

不能。它只阻止当前页面的默认提交，无法处理刷新、多个标签页、代理重试或服务端已经成功而客户端超时的情况。

失败重试要不要重新生成幂等键？

只要仍是同一笔业务意图，就复用原键；用户修改了表单内容并明确开始新提交时，才生成新键。

按钮禁用后还能用脚本再次提交吗？

可以。disabled 主要影响用户交互和浏览器控件状态，代码仍可能调用提交逻辑，所以还需要布尔提交锁和服务端幂等。

总结

前端重复提交的最小修复是统一 submit 入口、设置提交锁并在成功后保持锁；可靠的业务结果还需要服务端按幂等键保存并复用响应。把“按钮变灰”和“订单只创建一次”分开验收，才能真正覆盖超时、刷新和重试这些页面之外的重复路径。