32.5 异步竞态与请求顺序问题

异步操作是 JavaScript 强大能力的来源，但也是许多隐蔽 bug 的温床。其中最常见又最容易被忽视的一类问题，就是异步竞态（Race Condition）——多个异步操作同时进行，由于完成时间不可控，导致它们的回调执行顺序与发起顺序不一致，最终造成界面或数据状态错乱。

一个让你立刻明白的例子

设想一个搜索框，用户输入“JavaScript”这个单词。每次按键都会触发一次请求，向后端查询搜索建议。网络是不稳定的：第一次请求可能因为网络波动比第二次请求返回得慢。于是：

用户输入“J” → 发起请求 A
用户输入“Ja” → 发起请求 B
请求 B 先返回 → 界面展示“Ja”的建议
请求 A 后返回 → 界面被旧结果覆盖，展示“J”的建议

最终用户看到的是与当前输入完全不匹配的过期数据。这就是典型的异步竞态：请求发起的顺序是 A → B，但因为异步，回调执行的顺序变成了 B → A。

常见竞态场景

搜索建议/自动补全：每次输入都触发请求，旧请求返回晚于新请求
分页切换：快速点击“下一页”“下一页”，后发的请求可能先返回，页面显示的却是前一页数据
页签切换：切换 tab 时每个 tab 独立请求数据，旧 tab 的请求返回较慢，覆盖新 tab 的数据
重复提交：用户快速多次点击“提交”按钮，导致同样数据被创建多次
路由跳转：离开页面后，上个页面的请求才返回，对已卸载组件执行 setState 导致内存泄漏或警告

解决方案

方案一：防抖 + 节流（限制触发频率）

对于搜索建议这类场景，最重要的不是取消请求，而是不要让请求被频繁发出。使用防抖（Debounce）可以让函数在用户停止输入一段时间后才执行，从而从源头减少无效请求的数量。

这里以实用为主，给出一个最精简的防抖概念：

function debounce(fn, delay) {
  let timer = null;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}

但是防抖无法解决网络延迟导致的返回乱序问题——如果用户两次输入间隔超过了设定的延迟，仍然会发出两次请求，后发也可能先至。因此，防抖通常需要搭配请求取消一起使用。

方案二：请求取消（推荐）

现代请求方案普遍支持取消功能。当一个新请求发起时，主动取消上一次还未完成的请求，从根本上消除竞态的可能。

使用 Axios 的 CancelToken（或 signal）

let cancelSource = null;

async function fetchSearch(keyword) {
  // 取消上一个请求
  if (cancelSource) {
    cancelSource.cancel('新请求已发起，旧请求取消');
  }
  cancelSource = axios.CancelToken.source();
  try {
    const res = await axios.get('/api/search', {
      params: { keyword },
      cancelToken: cancelSource.token
    });
    // 更新界面...
  } catch (err) {
    if (axios.isCancel(err)) {
      console.log('请求被取消', err.message);
    } else {
      // 处理真正的错误
    }
  }
}

使用原生 fetch 的 AbortController

let abortController = null;

async function fetchSearch(keyword) {
  if (abortController) {
    abortController.abort();
  }
  abortController = new AbortController();
  try {
    const res = await fetch('/api/search?keyword=' + keyword, {
      signal: abortController.signal
    });
    const data = await res.json();
    // 更新界面...
  } catch (err) {
    if (err.name === 'AbortError') {
      console.log('请求被取消');
    } else {
      // 处理真正的错误
    }
  }
}

请求取消是最干净彻底的解法，不会浪费带宽，也不会产生无效的状态更新。只要场景支持请求取消，就应该使用这一方案。

方案三：过期标记（前端忽略旧响应）

如果某些情况下无法取消请求（例如使用不支持 AbortController 的旧版浏览器或库，或者请求已经发出无法撤回），可以在应用层对响应做一个“当前有效请求”的标记。

let requestId = 0;

async function fetchSearch(keyword) {
  const currentId = ++requestId; // 每次请求生成唯一ID
  const res = await fetch('/api/search?keyword=' + keyword);
  const data = await res.json();
  // 只有当请求ID与最新一致时才更新界面
  if (currentId === requestId) {
    updateUI(data);
  }
}

原则上，只有最新的请求才被认定为有效，旧的响应会被直接丢弃。这种方式虽然不能节省网络开销，但能避免界面展示错误的数据。

方案四：互斥锁/状态锁（针对按钮重复提交）

对于提交类操作，通常只需防止短时间内重复点击即可，不需要复杂的竞态处理：

let submitting = false;

async function handleSubmit() {
  if (submitting) return;
  submitting = true;
  try {
    await submitData();
    // 成功提示...
  } catch (e) {
    // 错误处理...
  } finally {
    submitting = false;
  }
}

结合按钮的 loading 状态，既能防止重复提交，也能给用户明确的视觉反馈，是表单操作的标准实践。

实际开发中的优先级建议

能取消的就取消：axios、fetch 都支持取消，这是第一选择。
高频触发用防抖/节流做预处理：减轻服务端压力，也降低竞态发生概率。
无法取消时用过期标记兜底：保证界面数据正确。
提交类操作加状态锁：避免重复提交。

不止是前端问题

异步竞态也是后端并发中要处理的经典问题，但在前端语境下，核心差异在于：前端直接将状态映射到用户可见的界面上，一旦出现竞态，用户会立刻感知到错误界面——比如瞬间闪过旧数据、列表闪烁、搜索结果跳变。因此，前端开发者必须将竞态处理纳入编码习惯，而不是等到 bug 出现再去排查。