AbortController取消搜索请求并避免旧结果覆盖新结果

搜索框最容易出现一种“偶尔错”的问题：用户先输入“redis”，马上又改成“redis stream”，但页面最后显示的却是第一轮结果。原因通常不是接口返回错了，而是多个异步请求完成顺序与输入顺序不同。处理这类竞态，推荐把 AbortController 和请求序号一起使用：新搜索开始前取消旧请求，写入结果前再确认它仍然是最后一轮。

AbortController 负责停止不再需要的网络工作，请求序号负责阻止已经返回、但已经过时的结果更新界面。两层都做，才能同时减少浪费并保持结果一致。

• 每次搜索都创建新的 AbortController，不要复用已经 abort 的 signal。
• 捕获 AbortError 时静默结束，其他异常照常提示。
• 在更新列表前比较请求序号，不能只依赖取消一定及时生效。

先把取消对象放在搜索请求的生命周期里

AbortController 通过 signal 把取消意图传给 fetch。调用 abort() 后，未完成的 fetch 会拒绝；如果响应已经拿到但正文还没读完，读取正文同样可能收到 AbortError。因此控制器应当属于“一轮搜索”，而不是属于整个页面永久复用。

下面的骨架只展示关键关系：保存当前控制器，下一轮开始时先取消它，再创建新的控制器。

let activeController = null;

async function requestSuggestions(keyword) {
  // 新请求只接管本轮任务，先停止已经没有展示价值的旧请求。
  activeController?.abort();
  activeController = new AbortController();

  const response = await fetch(`/api/search?q=${encodeURIComponent(keyword)}`, {
    // signal 把控制器的取消状态传给 fetch。
    signal: activeController.signal,
  });
  if (!response.ok) {
    // HTTP 错误不会自动变成 rejected promise，这里显式抛出。
    throw new Error(`HTTP ${response.status}`);
  }
  // 读取正文也在同一个可取消生命周期内完成。
  return response.json();
}

在新输入到来时取消旧请求，并正确处理异常

真正的输入事件还要考虑空值、加载状态和异常类型。用户快速输入时，旧请求可能已经发送到服务器，前端无法保证服务器端工作立刻停止；但取消客户端 fetch 可以避免继续等待和读取不再需要的响应。

let activeController = null;
let requestVersion = 0;

async function search(keyword, render) {
  const currentVersion = ++requestVersion;
  activeController?.abort();

  const controller = new AbortController();
  activeController = controller;
  const text = keyword.trim();
  if (!text) {
    // 空关键词不请求接口，同时清理旧列表。
    render({ status: "empty", items: [] });
    return;
  }

  render({ status: "loading", items: [] });
  try {
    const response = await fetch(`/api/search?q=${encodeURIComponent(text)}`, {
      signal: controller.signal,
    });
    if (!response.ok) {
      // 把 4xx/5xx 变成可被统一处理的异常。
      throw new Error(`搜索服务返回 ${response.status}`);
    }
    const data = await response.json();
    // 只有最后一次输入仍然有效时，才允许覆盖列表。
    if (currentVersion === requestVersion && !controller.signal.aborted) {
      render({ status: "ready", items: data.items ?? [] });
    }
  } catch (error) {
    if (error?.name === "AbortError") {
      // 主动取消是正常切换，不显示成“搜索失败”。
      return;
    }
    if (currentVersion === requestVersion) {
      // 真实网络或服务端错误只反馈给当前请求。
      render({ status: "error", message: error.message });
    }
  }
}

这里的 requestVersion 是第二道保险。即便旧响应已经越过网络取消窗口，只要它的版本号不是当前值，就没有资格写入结果。

为什么只调用 abort 仍然可能显示旧结果

abort() 解决的是可取消的异步工作，不是所有竞态。旧请求可能已经完成了 fetch，或代码在取消前已经拿到数据；业务层还可能把结果交给另一个不支持 signal 的解析器。此时单靠“我调用过 abort”不能证明旧结果不会被渲染。

排查时可以沿着四个位置看：控制器是否在发起新请求前创建；请求是否真的传入 signal；response.json() 是否在 try/catch 内；最终 render 前是否检查版本号。若使用 debounce，只要定时器尚未触发，它减少的是请求次数，并不等价于取消已经发出的请求。

上线前的边界检查与实现取舍

如果接口支持服务端取消或请求协作，可以进一步把取消原因传到服务端；否则客户端取消主要是停止等待、读取和后续渲染。不要把取消当作权限校验，也不要因为捕获了 AbortError 就吞掉所有异常。

对于搜索建议，通常采用“短 debounce + AbortController + 请求序号”组合：debounce 降低输入抖动带来的请求数量，controller 回收正在进行的请求，序号保证结果顺序。列表为空、接口慢、网络断开和用户连续删除关键词都应该各自有明确状态。

常见问题

AbortController 能撤回已经到达服务器的请求吗？

不能把它理解成事务回滚。它向浏览器侧发出取消信号，服务端是否停止处理取决于服务器、代理和请求阶段；前端仍要用版本号避免迟到结果写入界面。

为什么每次搜索都必须新建 AbortController？

因为一个已经触发 abort 的 signal 会保持终止状态，拿它发起的新 fetch 会立即失败。控制器应与单次搜索绑定，下一次搜索创建新实例。