前端 AbortController 如何取消搜索请求：竞态收口、状态复原与可验证示例

联想搜索最容易暴露一个细小但烦人的问题：用户先输入“redis”，又马上补成“redis stream”，后发出的请求反而先返回，旧结果把新结果顶掉。解决它不需要给每次请求加复杂的全局队列，浏览器原生的 AbortController 就能取消上一条 fetch；再用一个请求序号确认“谁有资格更新界面”，竞态就能收口。

每次输入变化时先取消旧请求，再让最新请求携带自己的序号；只有序号仍然有效的响应才能写入结果区，取消分支要把加载状态恢复干净。

先把搜索竞态缩成一个小项目

示例只保留一个输入框、一个结果区和一个模拟接口。接口用延迟模拟真实网络，故意让短关键词的响应更慢，这样更容易复现旧请求覆盖新请求的现象。页面不依赖框架，保存为 index.html 后直接打开即可。

等待输入

实现时把“请求控制器”和“当前请求序号”放在事件处理器外部。它们代表整个输入框的最新状态，而不是某一次回调的局部变量。

AbortController 如何截断上一条 fetch 调用链

每次 input 事件到来，先调用旧控制器的 abort()，再创建新的控制器，并把它的 signal 交给 fetch。这样“取消旧请求”发生在“发起新请求”之前，网络层和代码层的意图是一致的。

const searchBox = document.querySelector('#searchBox');
const status = document.querySelector('#status');
const results = document.querySelector('#results');

let controller = null;
let requestNo = 0;

searchBox.addEventListener('input', async (event) => {
  const keyword = event.target.value.trim();
  const currentNo = ++requestNo;

  controller?.abort();

  if (!keyword) {
    results.replaceChildren();
    status.textContent = '等待输入';
    controller = null;
    return;
  }

  controller = new AbortController();
  status.textContent = '加载中';

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

    const data = await response.json();
    if (currentNo !== requestNo) return;
    renderResults(data.items);
    status.textContent = '已更新';
  } catch (error) {
    if (error.name === 'AbortError') return;
    if (currentNo !== requestNo) return;
    status.textContent = '请求失败，请重试';
  } finally {
    if (currentNo === requestNo) controller = null;
  }
});

这里的 AbortController 是取消动作，requestNo 是结果资格判断，两者不能互相替代。请求已经完成、响应已经排进任务队列时，abort() 不一定能阻止回调继续执行，所以仍要保留序号检查。只有当前序号对应的数据才能进入 latestResults，旧响应即使抵达也不能写回列表。

用状态转换处理加载、取消和成功

用户看到的状态应该跟请求生命周期一起变化：没有关键词时是 idle，发出最新请求后是 loading，被下一次输入中止的旧请求进入 aborted，新结果真正写入列表后才进入 rendered。取消不是错误，不能把它渲染成红色失败提示。

为了让这个边界可观察，可以在调试阶段把状态集中到一个函数里：

function setSearchState(state) {
  status.dataset.state = state;
  status.textContent = {
    idle: '等待输入',
    loading: '加载中',
    aborted: '已切换关键词',
    rendered: '已更新'
  }[state];
}

// 新请求开始前
setSearchState('loading');

// AbortError 分支
setSearchState('aborted');

// 最新响应写入列表后
setSearchState('rendered');

生产代码可以把“已切换关键词”做成短暂提示，也可以直接回到 loading；关键是不要留下旧请求的红色错误状态。若输入框被清空，则直接回到 idle，同时清空列表。

怎样验证旧结果不会覆盖新结果

打开浏览器开发者工具的 Network 面板，快速输入两个关键词，例如先输入 redis，再输入 redis stream。正常情况下，第一条请求会出现取消标记或触发 AbortError，第二条请求完成后列表只显示第二个关键词对应的结果。

• 检查请求：每次输入变化都会先取消上一条未完成的 fetch。
• 检查状态：取消旧请求不出现“请求失败”，最新请求结束后状态为“已更新”。
• 检查内容：让旧响应故意延迟，结果区仍不能回退到旧关键词。

如果接口无法稳定制造延迟，可以在开发环境给响应加随机等待；验证的重点不是某个固定毫秒数，而是响应先后顺序改变时，界面仍只接受当前序号。

几个容易漏掉的边界

AbortError 要不要记录日志？

可以在调试日志里记录，但不要把它当成服务异常上报。它通常表示用户继续输入，属于正常控制流。

为什么已经 abort 还要判断 requestNo？

取消主要作用于仍在进行的请求；响应完成后的 JavaScript 回调可能已经排队。序号判断能挡住这类“取消太晚”的情况。

controller 为什么在 finally 里不能无条件置空？

旧请求的 finally 可能晚于新请求执行。只有 currentNo === requestNo 时才能清理共享控制器，否则旧回调会把新控制器误删。

相关问题

AbortController 能取消服务端已经执行的查询吗？

它首先取消浏览器侧的请求和响应等待，不等于服务端一定停止已经开始的业务。服务端是否能中止查询，要看后端协议和实现。

输入框防抖和 AbortController 是一回事吗？

不是。防抖减少请求次数，AbortController 收口已发出的请求；搜索场景通常两者一起用。

fetch 被取消后会返回什么状态码？

通常不会得到普通 HTTP 状态码，而是在 Promise 链中以名称为 AbortError 的异常进入捕获分支。

把验收标准留在代码旁边

这段实现的核心不是“让请求消失”，而是让每个异步结果都经过资格检查。取消旧请求可以节省等待和处理，序号判断保证界面不会被旧响应回写，状态复原则让用户知道当前输入仍可继续工作。把这三点放在一起，搜索框的竞态才算真正处理完。