Fetch AbortController 取消后为什么仍然有业务回调

搜索框里连续输入关键词时，开发者经常会先取消上一条 Fetch，再启动下一条请求，但界面仍出现旧结果、旧错误，甚至看到取消后的业务回调。原因通常不是 AbortController 失效，而是“取消 Fetch”和“撤销已经排队的 JavaScript 回调”是两件事。

先分清取消、异常和业务回调

controller.abort() 会让绑定的 Fetch 操作进入中止路径；如果响应体还在读取，读取响应体也可能抛出 AbortError。但 Promise 的拒绝仍然要经过既有的异步链，所以 catch 用来处理拒绝，finally 用来做无论成功失败都要做的清理，它们不会因为请求被取消而凭空消失。

真正危险的是下面这类写法：catch 里把所有错误显示出来，finally 里无条件关闭 loading，或者 then 里不检查请求是否已经过期。取消只保证 Fetch 的结果不再正常交付，不保证你的业务闭包没有下一行代码。

把 controller 生命周期收在一次请求内

每次搜索都创建一个新的 controller。旧 signal 一旦 aborted，就不应该拿给新 Fetch 复用；把 controller 放在模块级变量只用于“记录当前 controller”，而不是让所有请求共用同一个 signal。

let currentController = null;

async function loadSuggestions(keyword) {
  // 新请求独占一个 controller，避免复用已经 aborted 的 signal。
  currentController?.abort();
  const controller = new AbortController();
  currentController = controller;

  try {
    const response = await fetch(`/api/suggest?q=${encodeURIComponent(keyword)}`, {
      signal: controller.signal,
    });
    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    return await response.json();
  } catch (error) {
    // 用户取消不等于接口故障，避免把正常取消显示成错误。
    if (controller.signal.aborted || error.name === "AbortError") return null;
    throw error;
  } finally {
    // 只清理本次请求留下的引用，不误伤后来启动的请求。
    if (currentController === controller) currentController = null;
  }
}

这里的 finally 仍然执行，但只做引用清理。条件判断很重要：如果新请求已经替换了 currentController，旧请求的 finally 不能把新 controller 清空。

用请求代次挡住旧回调

即使调用了 abort()，竞态窗口里仍可能有已经完成或已经排队的业务 continuation。最稳妥的做法是给每次请求分配递增序号，并在每个会写状态的 await 之后检查两件事：序号是否还是最新，以及当前 signal 是否已取消。

let requestVersion = 0;
let currentController = null;

async function search(keyword, setState) {
  const version = ++requestVersion;
  currentController?.abort();
  const controller = new AbortController();
  currentController = controller;
  setState({ loading: true, error: null });

  // 旧请求即使走到回调，也不能提交新请求之后的状态。
  const isCurrent = () => version === requestVersion && !controller.signal.aborted;

  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 (isCurrent()) setState({ loading: false, data });
  } catch (error) {
    // 取消属于竞态控制，不覆盖当前请求的结果或错误。
    if (!isCurrent()) return;
    setState({ loading: false, error: error.name === "AbortError" ? null : error });
  } finally {
    // finally 只处理本次请求的收尾，不能无条件关闭后来请求的 loading。
    if (isCurrent()) setState({ loading: false });
    if (currentController === controller) currentController = null;
  }
}

注意 response 到手不代表响应体已经读完；await response.json() 之后再做门禁，才能覆盖“响应已兑现、读取过程中又被取消”的情况。若应用只关心最后一次搜索，这种代次检查比只在按钮点击时调用 abort 更可靠。

排查时按四个边界逐项核对

先确认 fetch(url, { signal }) 真的接收了本次 controller 的 signal；再确认请求体读取也在 try 范围内。随后检查 catch 是否把 AbortError 当成普通错误，最后检查所有 setState、loading 和错误提示是否都经过“当前请求”判断。监听 abort 事件时要用具名函数，并在 finally 中移除自定义监听器；只写 { once: true } 不能覆盖“信号一直未中止”的正常完成路径。

常见问题

AbortController.abort() 后为什么 finally 还会执行？

因为 finally 监听的是 Promise settle，而不是“请求是否成功”。它正适合做清理，但清理动作也要判断请求代次。

只判断 error.name === "AbortError" 够吗？

处理 Fetch 默认取消通常够用，但业务代码更应结合本次 signal 的 aborted 状态，避免把别的 AbortSignal 或自定义取消原因误判。

一个 AbortSignal 能连续用于多次 fetch 吗？

不能把已中止的 signal 当成可复用令牌。每次独立请求创建新的 AbortController，旧 controller 只负责终止旧请求。

这类问题的落点不是让回调“完全不运行”，而是让回调运行后也没有资格提交过期状态：取消负责传递中止意图，代次和 signal 门禁负责守住业务状态边界。