前端表单重复提交治理实战：请求锁、按钮状态和失败回滚

表单重复提交是很常见的前端问题：用户点了一次没反应，又连续点了几次；网络慢时浏览器还在等待，后端却已经收到了多次请求。它可能带来重复订单、重复保存、重复发送通知。后端当然应该做最终兜底，但前端先把交互和请求链路管住，可以显著减少无效请求。

适合人群：正在开发订单提交、资料保存、评论发布、后台表单的前端同学。本文用原生 JavaScript 示例说明思路，Vue、React、uni-app 等框架都可以按同样方式落地。

目录

• 重复提交是怎么发生的
• 第一层保护：请求锁和按钮状态
• 第二层保护：幂等请求头
• 失败回滚和用户提示
• 常见坑和上线检查

一、重复提交是怎么发生的

重复提交通常不是用户故意的，而是反馈不够明确。比如点击按钮后没有 loading、按钮仍然可点、网络慢时页面没有状态变化、接口失败后状态没有恢复。前端要处理的是“用户能不能再次触发”和“触发后请求会不会重复发出”。

一个典型问题链路是：用户连续点击按钮，浏览器多次触发表单事件，多个请求同时到达后端，后端如果没有幂等约束，就可能写入多条相同数据。

二、第一层保护：请求锁和按钮状态

最基础的做法是给提交动作加一个请求锁：请求开始时锁住，按钮进入不可点状态；请求完成或失败后再释放。这样同一页面内的连续点击会被挡住。

  提交订单
  

const form = document.querySelector("#orderForm");
const button = document.querySelector("#submitBtn");
const message = document.querySelector("#message");

let pending = false;

form.addEventListener("submit", async (event) => {
  event.preventDefault();

  if (pending) {
    message.textContent = "正在提交，请稍等";
    return;
  }

  pending = true;
  button.disabled = true;
  button.textContent = "提交中...";
  message.textContent = "";

  try {
    const payload = Object.fromEntries(new FormData(form));
    const response = await fetch("/api/orders", {
      method: "POST",
      headers: {"Content-Type": "application/json"},
      body: JSON.stringify(payload)
    });

    if (!response.ok) {
      throw new Error("提交失败");
    }

    message.textContent = "提交成功";
  } catch (error) {
    message.textContent = "提交失败，请稍后重试";
  } finally {
    pending = false;
    button.disabled = false;
    button.textContent = "提交订单";
  }
});

这段代码的重点是 `pending` 和按钮状态必须一起改。只加按钮禁用不够，因为提交动作也可能来自键盘回车、脚本触发或框架里的二次调用；只加锁也不够，因为用户看不到状态变化，会以为页面卡住。

三、第二层保护：幂等请求头

前端锁只能处理当前页面内的连续触发。页面刷新、浏览器重试、移动端弱网恢复时，仍然可能产生相同业务请求。更稳的做法是为一次表单提交生成一个幂等标识，放到请求头或请求体里，由后端据此判断是否已经处理过。

function makeRequestId() {
  const bytes = new Uint8Array(16);
  crypto.getRandomValues(bytes);
  return Array.from(bytes, (item) => item.toString(16).padStart(2, "0")).join("");
}

async function postOrder(payload) {
  const requestId = makeRequestId();

  return fetch("/api/orders", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "X-Request-Id": requestId
    },
    body: JSON.stringify(payload)
  });
}

这个标识不是为了替代后端校验，而是让后端有机会识别“同一次提交”。建议在用户点击提交时生成一次，不要在重试同一个请求时重新生成，否则后端就无法把它当成同一次业务动作。

四、失败回滚和用户提示

重复提交治理不能只看成功路径。请求超时、服务端报错、用户主动离开页面时，都要恢复按钮状态，并给出明确提示。否则用户会卡在“提交中”，下一次只能刷新页面。

async function runWithSubmitState(task) {
  if (pending) return;

  pending = true;
  button.disabled = true;

  try {
    await task();
    message.textContent = "保存成功";
  } catch (error) {
    message.textContent = "保存失败，请检查网络后重试";
  } finally {
    pending = false;
    button.disabled = false;
  }
}

如果业务不允许用户重试，例如支付确认、优惠券领取，前端提示要更谨慎：可以引导用户查看结果页或刷新状态，而不是简单让他再点一次。

五、常见坑和上线检查

1. 只禁用按钮，忘记表单回车

桌面端用户可能在输入框里按回车提交表单。请求锁要放在提交函数入口，而不是只绑定按钮点击事件。

2. 失败后没有释放状态

网络异常、接口返回非 2xx、代码抛错都要进入恢复逻辑。最稳妥的位置是 `finally`，保证成功失败都能释放锁。

3. 多个提交按钮共用同一份状态

页面上如果有“保存草稿”和“提交审核”两个动作，应该根据业务决定是否共用锁。它们如果会写同一份数据，通常需要互斥；如果完全独立，可以分别管理状态。

4. 上线前自测清单

• 连续快速点击提交按钮，只产生一次有效请求。
• 按回车提交表单，也会进入同一套请求锁。
• 接口失败后按钮恢复可用，提示文案明确。
• 同一次提交带有稳定的请求标识，后端可以做兜底判断。

总结

前端治理重复提交可以分成三层：请求入口加锁、交互上给出按钮状态、请求里带上幂等标识。再补上失败回滚和上线自测，就能把大部分重复点击、慢网等待和误触发拦在前端，同时也给后端幂等兜底留下清晰上下文。