前端按钮重复提交怎么办：loading 锁和 AbortController 最小配方

按钮重复提交是前端里很常见的小坑：用户连续点“保存”，浏览器发出多个请求，后发的请求可能先返回，先发的旧响应却在最后回来，把页面状态又改回去了。看起来像后端不稳定，实际很多时候是前端没有管理好“等待中的请求”。

这篇文章给一套最小配方：用 loading 锁住按钮，用 AbortController 取消旧请求，再用递增序号保证只有最新请求可以改 UI。它适合保存按钮、搜索框、分页切换、筛选条件变化等场景。

问题：连续点击会形成一条等待链

假设用户在 1 秒内点了两次保存。第一次请求 A 先发出，第二次请求 B 后发出。如果 B 先返回，页面显示“保存成功”；过一会儿 A 才返回，旧响应又把页面改成旧数据，用户就会看到状态闪回、按钮卡住或者提示重复出现。

这个问题的关键不只是“防抖”。防抖能减少触发次数，但不能处理已经发出去的旧请求。更稳的做法是把等待链拆开：按钮进入等待态后禁止重复点击；如果场景允许新请求覆盖旧请求，就主动取消上一次请求；最后再用序号兜底，确保旧响应没有资格更新页面。

最小配方：锁按钮、取消旧请求、只认最新结果

这个配方包含三层保护：

• loading 锁：请求进行中禁用按钮，让用户知道当前动作还没结束。
• 取消旧请求：用 AbortController 取消上一轮还没完成的 fetch。
• 最新序号：每次提交生成一个递增序号，只有当前最新序号能更新 UI。

三层保护的意义不同：按钮锁负责交互体验，取消信号负责减少无意义等待，最新序号负责避免竞态。实际项目里不要只靠其中一层，尤其是搜索和筛选场景，用户可能主动发起新的请求，旧请求就应该退出。

关键代码：让旧响应无法改 UI

下面是一段不依赖框架的写法。重点不是代码多复杂，而是三个变量的职责要清楚：loading 管按钮，currentController 管取消，requestSeq 管最新结果。

const saveButton = document.querySelector("#save");
const statusBox = document.querySelector("#status");

let loading = false;
let requestSeq = 0;
let currentController = null;

async function saveProfile(payload) {
  if (loading) return;

  loading = true;
  saveButton.disabled = true;
  statusBox.textContent = "正在保存...";

  if (currentController) {
    currentController.abort();
  }

  const seq = ++requestSeq;
  const controller = new AbortController();
  currentController = controller;

  try {
    const response = await fetch("/api/profile", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(payload),
      signal: controller.signal
    });

    if (!response.ok) {
      throw new Error(`保存失败：${response.status}`);
    }

    const data = await response.json();

    if (seq !== requestSeq) return;
    statusBox.textContent = `保存成功：${data.updatedAt}`;
  } catch (error) {
    if (error.name === "AbortError") return;
    if (seq === requestSeq) {
      statusBox.textContent = error.message || "保存失败，请稍后重试";
    }
  } finally {
    if (seq === requestSeq) {
      loading = false;
      saveButton.disabled = false;
      currentController = null;
    }
  }
}

这段代码里有一个容易忽略的点：finally 里也要判断序号。如果旧请求在最后进入收尾逻辑，却直接把按钮恢复可点，就可能打断新请求的等待态。让“最新请求”统一负责 UI 收尾，页面状态会稳定很多。

变体：搜索、保存、分页各有侧重点

保存按钮通常更适合严格锁住：用户点一次就等待结果，避免重复写入。此时可以直接在 loading 为真时返回，不让第二次点击继续发请求。

搜索输入框更适合“新请求覆盖旧请求”：用户继续输入关键词，旧关键词对应的请求就没有展示价值。可以不使用强按钮锁，而是每次输入后取消旧请求，并只展示最新序号的结果。

分页和筛选要注意“结果和条件一致”。如果用户从第 1 页快速切到第 3 页，旧响应回来时必须检查当前页码和请求序号，否则列表会显示成错误页的数据。

兼容坑：disabled、取消信号和异常提示

第一，disabled 只管当前按钮，不管快捷键、回车提交、其他入口按钮。如果一个动作有多个触发入口，最好让它们共用同一个提交函数和同一份 loading 状态。

第二，取消请求不等于后端一定停止处理。AbortController 会让前端停止等待响应，但服务端是否已经收到并处理请求，要看接口设计。所以涉及订单、支付、扣库存等动作，还要让后端做幂等保护。

第三，不要把取消当作普通错误弹给用户。用户主动发起新搜索时，旧请求被取消是正常流程；只有最新请求失败，才需要展示错误提示。

完整片段

如果是普通表单，可以把提交事件和按钮点击都收束到同一个函数：

const form = document.querySelector("#profile-form");

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

  const formData = new FormData(form);
  const payload = Object.fromEntries(formData.entries());

  saveProfile(payload);
});

这时无论用户点按钮还是按回车，都会走同一份等待态、取消逻辑和序号判断。后续迁移到 Vue、React 或其他框架时，也只需要把这三个状态放进组件状态或组合函数里。

总结

前端按钮重复提交的核心不是“用户点太快”，而是页面没有管理好正在等待的请求。一个稳妥配方是：进入请求前锁按钮，发新请求前取消旧请求，响应回来后用最新序号判断是否能改 UI，最后只让最新请求恢复按钮状态。这样处理后，重复点击、旧响应覆盖、错误提示乱跳这些问题都会少很多。