前端表单重复提交治理完整流程：按钮锁定、请求去重和幂等 key

表单重复提交是前端里很常见的“小问题”：用户连点两下提交按钮，网络慢的时候又点一次，或者页面返回后重新提交一次。轻则多弹几条提示，重则生成重复订单、重复报名、重复扣减库存。

这类问题不能只靠“按钮点完变灰”解决。按钮锁定能挡住大部分重复点击，但挡不住刷新、重试、多个标签页和网络层重复发送。完整做法应该是前端状态防重加接口幂等 key，两层一起兜住。

摘要

前端表单防重复提交可以按四步落地：提交前先校验，提交中锁定按钮和状态，同一业务请求只保留一个 inFlightKey，再把唯一 key 传给后端做幂等判断。前端负责减少重复入口，后端负责保证最终业务只处理一次。

适合人群

• 正在做订单、报名、发帖、支付前置表单的前端开发者。
• 遇到过用户重复点击导致多条数据、多次请求的问题。
• 想把“按钮置灰”升级成完整防重方案的同学。

目标和边界：我们要防住哪些重复提交

先把边界定清楚。前端能控制的是用户界面入口和当前页面内的请求状态，后端才能保证最终业务数据只写一次。所以这篇文章的目标不是“只靠前端绝对防重”，而是做一套前后端配合的防重流程。

全流程总览：一次提交只进入一次业务流程

推荐流程是：表单先校验，通过后立刻进入提交中状态，按钮置为不可点击；发请求前生成本次业务的唯一 key；请求完成后根据结果释放状态或进入成功页。这样用户界面、请求层和业务层都有明确检查点。

这一阶段的检查点是：用户第一次点击后，页面马上给出“提交中”的视觉反馈；同一份表单在请求完成前不会再次发起相同业务请求。

阶段一：提交前先做表单校验

到这一步不要急着发请求。先做本地校验，把明显错误拦在提交前。这样不仅减少无效请求，也避免“错误表单反复点提交”带来的状态混乱。

function checkForm(form) {
  const errors = {};

  if (!form.name || form.name.trim().length 

校验阶段只做一件事：判断当前输入是否可以提交。不要在这里顺手改请求状态，也不要生成业务 key。状态变化放到真正准备发请求的时候更清楚。

阶段二：提交中锁定按钮和请求状态

通过校验后，立即设置 submitting 状态。按钮根据这个状态禁用，同时文案从“提交”切换成“提交中”。用户能看到反馈，就不容易连续点击。

let submitting = false;

async function submitForm(form) {
  if (submitting) return;

  const checked = checkForm(form);
  if (!checked.ok) {
    showErrors(checked.errors);
    return;
  }

  submitting = true;
  renderSubmitButton();

  try {
    const result = await postOrder(form);
    showSuccess(result);
  } catch (err) {
    showError('提交失败，请稍后重试');
  } finally {
    submitting = false;
    renderSubmitButton();
  }
}

这里的关键动作是把 submitting 放在请求之前设置，并在 finally 里恢复。无论成功还是失败，按钮状态都能回到可控状态。

阶段三：用 inFlightKey 做前端请求去重

只有按钮锁定还不够。比如某些组件会触发多次提交函数，或者用户通过快捷键提交。可以增加一个 inFlightKey 集合，让同一业务请求在前端只保留一次。

const inFlightKeys = new Set();

async function runOnce(key, task) {
  if (inFlightKeys.has(key)) {
    return { skipped: true };
  }

  inFlightKeys.add(key);
  try {
    return await task();
  } finally {
    inFlightKeys.delete(key);
  }
}

调用时，把业务类型和核心字段拼成一个稳定 key。比如创建订单可以使用商品 ID、收货地址 ID、用户选择项等字段。

async function submitOrder(form) {
  const frontKey = [
    'create-order',
    form.productId,
    form.addressId,
    form.quantity,
  ].join(':');

  return runOnce(frontKey, () => postOrder(form));
}

这个 key 是前端当前页面内的防重标识。它能拦住短时间重复触发，但不能替代后端幂等，因为刷新页面后这个集合就消失了。

我的推荐流程：前端防重加后端幂等 key

真正要稳，前端还应该给每一次业务提交生成一个唯一 key，并随请求传给后端。后端根据这个 key 判断同一业务是否已经处理过，已经处理过就返回之前的结果，不再重复写入。

function createBizKey(form) {
  const raw = [
    'order',
    form.productId,
    form.addressId,
    Date.now(),
    Math.random().toString(16).slice(2),
  ].join(':');

  return btoa(raw).replace(/=/g, '');
}

async function postOrder(form) {
  const bizKey = createBizKey(form);

  const res = await fetch('/api/orders', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'X-Idempotency-Key': bizKey,
    },
    body: JSON.stringify(form),
  });

  if (!res.ok) {
    throw new Error('request failed');
  }
  return res.json();
}

前端侧要记住一点：唯一 key 不只是为了防点击，它代表一次业务意图。用户改了商品、数量、地址，就应该生成新的 key；同一次提交过程中的重复发送，则应该沿用同一个 key。

容易踩坑

只禁用按钮，不处理快捷键和代码触发

按钮置灰只限制鼠标点击，不一定限制回车提交、组件事件重复触发或代码重复调用。提交函数内部仍然要检查 submitting 或 inFlightKey。

请求失败后没有释放状态

如果只在成功回调里恢复按钮，一旦接口失败，按钮会一直锁住。建议把恢复逻辑放到 finally，保证状态能收尾。

每次重试都生成新 key

同一次业务提交的重试应该尽量复用同一个唯一 key。否则后端会把它当成新的业务请求，幂等效果就会变弱。

落地清单

总结

前端表单防重复提交不要停留在“点完按钮变灰”。更稳的流程是：校验先行、状态锁定、请求去重、唯一 key 交给后端兜底。前端减少重复入口，后端保证业务只处理一次，这样才能覆盖慢网络、重复点击、刷新重试和多标签页提交等真实场景。