前端搜索框为什么会被旧请求覆盖：AbortController、竞态与结果验收

搜索框边输入边请求接口时，最容易出现的不是接口报错，而是“结果回到了错误的时间点”：用户已经输入了“react”，旧的“re”请求却最后返回，把新结果覆盖掉。修复这类问题要同时做两件事：用 AbortController 取消已经失去意义的请求，再用请求序号验收回调，确保只有当前输入对应的结果能写回界面。

取消请求可以减少无效工作，但不能单独承担正确性；“取消上一轮 + 只接受最新序号”的组合，才是搜索联想框防旧结果覆盖的可靠边界。

搜索结果被覆盖，真正需要保护的是什么

这里要保护的不是某一个网络连接，而是“当前输入”和“当前结果列表”的对应关系。用户从 go 继续输入到 golang 时，浏览器可能已经发出多次 fetch。网络延迟、缓存命中和服务端负载都可能让返回顺序与发出顺序相反。

例如第 1 次请求查询 go，第 2 次请求查询 golang。如果第 2 次先返回并渲染，随后第 1 次才返回，界面就会重新显示更宽泛的旧结果。这个 bug 往往只在慢网、移动端或接口响应大小差异明显时出现。

旧请求为什么能越过新输入继续写回

异步函数在 await 处暂停，恢复时并不会自动知道输入框已经变了。下面这段代码没有任何“当前性”判断，谁先完成谁就能更新列表：

let timer;

input.addEventListener('input', () => {
  clearTimeout(timer);
  timer = setTimeout(async () => {
    const response = await fetch(`/api/search?q=${encodeURIComponent(input.value)}`);
    const data = await response.json();
    renderResults(data.items);
  }, 180);
});

设置180毫秒的延迟只是减少请求触发次数，并不会改变已发出请求之间的实际返回顺序。也不能把“用户最后一次输入的字符串”当成唯一的校验依据：比如用户先输入一个关键词，删掉之后再重新输入完全相同的内容，前后字符串完全一致，但它们属于两个独立的请求轮次，不能直接判定为重复请求直接丢弃。

AbortController 负责取消，序号负责验收

MDN 对 AbortController 的定义是：把它的 signal 传给 fetch 后，可以通过 abort() 中止请求；被中止的操作通常以名为 AbortError 的异常结束。控制器和 signal 都应按请求轮次创建，因为已经中止的 AbortSignal 不能拿来发起下一次有效请求。

let debounceId = 0;
let requestSerial = 0;
let activeController = null;

input.addEventListener('input', () => {
  const keyword = input.value.trim();
  clearTimeout(debounceId);

  if (!keyword) {
    requestSerial += 1;
    activeController?.abort();
    activeController = null;
    renderResults([]);
    setStatus('请输入关键词');
    return;
  }

  debounceId = window.setTimeout(() => search(keyword), 180);
});

async function search(keyword) {
  const serial = ++requestSerial;
  activeController?.abort();
  const controller = new AbortController();
  activeController = controller;
  setStatus(`正在搜索“${keyword}”`);

  try {
    const response = await fetch(`/api/search?q=${encodeURIComponent(keyword)}`, {
      signal: controller.signal,
      headers: { Accept: 'application/json' }
    });
    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    const data = await response.json();

    if (serial !== requestSerial) return;
    renderResults(data.items);
    setStatus(`已显示“${keyword}”的结果`);
  } catch (error) {
    if (error.name === 'AbortError') return;
    if (serial !== requestSerial) return;
    setStatus('搜索失败，请稍后重试');
    showError(error);
  } finally {
    if (serial === requestSerial) activeController = null;
  }
}

这段最小实现有两个互补的门：abort() 尽量让旧请求停止，serial !== requestSerial 则在最终写回前再次确认。即使服务端已经完成响应、取消来不及阻止解析，序号门仍然有效。

把风险拆成取消、回写和状态三层

取消层：每轮只绑定自己的 signal

不要把一个全局 controller 创建一次后长期复用。第一次调用 abort() 后，旧 signal 已经处于 aborted 状态；下一次 fetch 若继续使用它，会立即失败。新请求要先生成新 controller，再把新 signal 传给请求。

回写层：解析后仍要做当前性检查

请求取消不是数据库事务，也不是对服务器处理的撤销承诺。响应可能已经到达，或者某个缓存适配层没有及时停止工作。因此不能只在 catch 里判断异常，response.json() 完成后也必须检查序号。

状态层：取消不应该显示成失败

用户继续输入时，旧请求被取消是正常路径。若把它当成红色错误提示，快速输入会造成闪烁。状态文本只对当前序号负责；旧请求的 finally 也不能把新请求的 loading 状态提前清掉。

常见实现误区与可回退方案

只使用防抖、只比较关键词字符串、只在 catch 里过滤 AbortError，都不足以构成完整保护。防抖控制的是发出频率，序号控制的是写回资格；两者目标不同。

如果项目还要兼容不支持 AbortController 的旧运行环境，可以保留序号验收作为正确性底线，并把取消能力放到特性检测或 polyfill 中：

const canAbort = typeof AbortController !== 'undefined';
const controller = canAbort ? new AbortController() : null;
const options = controller ? { signal: controller.signal } : {};
const response = await fetch(url, options);
// 无论是否能取消，写回前都要检查 serial === requestSerial。

如果部分旧浏览器不支持AbortController做回退兼容，旧请求仍然会持续消耗网络和服务端资源，所以开发过程中要同时搭配输入防抖、服务端限流、结果缓存这类常规措施，不要为了向下兼容把最关键的序号验收逻辑删掉。

用可观察证据验收搜索框

验收时不要只连续点击几次看“似乎正常”。在浏览器开发者工具的 Network 面板中，把网络切换到 Fast 3G 或增加响应延迟，然后快速输入 g、go、golang。重点看三件事：

• 新一轮请求发出时，旧请求是否进入取消状态，或至少后续不会再修改界面展示结果。
• 最终展示的联想列表对应的查询词，始终是用户最后一次输入的有效内容，而不是网络返回最晚的旧查询结果。
• 旧请求取消后，界面仍能保持当前搜索状态对应的loading提示，不会毫无预期地弹出搜索失败的提示打断用户操作。

还要覆盖空输入、HTTP 非 2xx、JSON 解析失败、快速删除重输和组件卸载场景。组件卸载时调用当前 controller 的 abort()，并让卸载后的回调无法触碰已经移除的 DOM。

相关问题

AbortController 能撤回服务端已经执行的查询吗？

不能把客户端的取消操作等同于服务端的事务回滚。它的核心作用是让浏览器停止后续的等待、解析和渲染处理；至于服务端有没有实际收到请求、有没有跑完查询逻辑，要由服务端的超时机制、取消协议设计、查询链路特性共同决定。

为什么已经 abort 了还要保留请求序号？

请求取消和响应完成本身就可能出现竞态，再加上代理、CDN这类中间层可能已经提前把缓存的响应返回给客户端，光靠取消机制无法完全拦截旧结果。序号作为结果写入资格的独立判断逻辑，能把“旧请求结果不能覆盖当前最新界面”的规则写得更清晰无歧义。

搜索框应该用节流还是防抖？

联想搜索场景更适合用较短的防抖阈值，等用户输入停顿之后再发请求；拖拽、滚动这类高频连续交互场景更常用节流处理。不管你选择哪种交互优化方案，都不能替代请求取消和最新序号验收这两层核心校验。

小结

前端搜索竞态的核心不是让所有请求都按顺序返回，而是让旧请求失去写回资格。防抖减少无效发出，AbortController 主动取消上一轮，递增序号在响应解析后做最后验收；再配合明确的取消状态、错误状态和网络面板复测，搜索结果就不会因为一次慢返回回到过去。