JavaScript AbortController 如何取消 fetch 和事件监听

页面搜索、列表切换或弹窗关闭时，前一个 fetch 往往还在等待。如果不主动取消，旧响应可能覆盖新结果，页面销毁后事件监听器也可能继续持有回调。JavaScript 的 AbortController 可以把这两类清理放进同一套取消模型：把 signal 交给 fetch，再用 controller.abort() 终止请求；把同一个信号交给 addEventListener，取消时监听器会自动移除。

一、先把取消链路分成两个控制器

AbortController 是发出取消指令的对象，controller.signal 是传给异步任务的只读信号。fetch(url, { signal }) 建立关联后，调用 controller.abort() 会让未完成的请求拒绝；如果响应头已经拿到、但响应体还没读完，后续 response.text() 或 response.json() 也可能因取消而失败。

用浏览器原生提供的AbortController接口，你可以统一给fetch请求、各类事件监听、甚至后续的异步任务绑定终止信号，触发终止时所有关联的操作都会被主动中断，不需要额外维护多个独立的取消标识变量。

最容易忽略的边界是信号的一次性：一个信号一旦进入 aborted 状态，之后把它传给新的 fetch 会立即失败。因此搜索框这类“新请求替换旧请求”的场景，应该先终止旧控制器，再创建新控制器，而不是只修改一个共享的 signal 引用。

二、用 signal 同时管理 fetch 与事件监听

请求控制器和页面监听器可以分开管理。这样“用户开始新搜索”只取消旧请求，而“页面销毁”才同时清理请求和监听器。下面的示例展示这两个范围，并用 signal 让事件监听器由浏览器自动解除。

let requestController = null;
const pageController = new AbortController();
const searchInput = document.querySelector("#search");

// 页面级监听器绑定 pageController，页面销毁时统一解除。
searchInput.addEventListener("input", () => {
  loadResults(searchInput.value);
}, { signal: pageController.signal });

async function loadResults(keyword) {
  // 新请求开始前取消旧请求，避免旧响应覆盖当前结果。
  requestController?.abort("replaced-by-new-search");
  requestController = new AbortController();
  const { signal } = requestController;

  try {
    const response = await fetch(`/api/search?q=${encodeURIComponent(keyword)}`, { signal });
    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    const data = await response.json();
    renderResults(data);
  } catch (error) {
    // 只把当前 signal 已取消识别为用户或页面主动取消。
    if (signal.aborted) return;
    throw error;
  }
}

function disposePage() {
  // 同时取消请求并移除 pageController 管理的事件监听器。
  requestController?.abort("page-disposed");
  pageController.abort("page-disposed");
}

这里的两个控制器不是重复设计：请求控制器的生命周期是“一次搜索”，页面控制器的生命周期是“一次页面实例”。如果所有输入事件都共用页面控制器，调用页面级 abort() 后输入监听会消失，后续调用自然不会再触发。

三、从 aborted、reason 和 AbortError 判断结果

不要只写 catch (error) { console.error(error) }。取消是预期分支，网络断开、CORS 失败和非 2xx 响应则是另一类问题。判断时优先使用发起本次请求的那个 signal：

try {
  const response = await fetch(url, { signal });
  // HTTP 404/500 不会自动触发 catch，需要显式判断响应状态。
  if (!response.ok) throw new Error(`HTTP ${response.status}`);
  return await response.json();
} catch (error) {
  if (signal.aborted) {
    // reason 可能是字符串、Error 或其他 JavaScript 值。
    console.info("请求已取消", signal.reason ?? "未提供原因");
    return null;
  }
  // 非取消异常继续抛出，让上层展示真正的错误。
  throw error;
}

signal.aborted 说明取消状态已经发生，signal.reason 则帮助记录是谁触发了取消。若没有自定义原因，平台通常会以 AbortError DOMException 表示。相比只比较 error.name，先检查当前信号更稳妥：业务代码可能传入自定义取消原因，而真正的网络错误不应被静默吞掉。

四、常见坑与复查清单

• 复用旧信号：控制器 abort 后立即作废，下一次任务要重新 new AbortController()。
• 只取消 fetch：请求停止不等于 UI 状态自动恢复，仍要在取消分支中停止 loading、解锁按钮或保留当前结果。
• 忽略响应体阶段：拿到响应对象后仍可能在读取 body 时取消，解析代码也要位于同一个 try/catch 中。
• 共享范围过大：页面控制器适合统一清理，单次请求控制器适合替换请求；不要让一次局部取消误伤整页监听。

相关问题

AbortController 能取消已经完成的 fetch 吗？

不能撤回已经完成的网络工作。若请求已完成但响应体尚未读取，读取阶段仍可能响应取消；调用 abort() 后要以实际的 signal.aborted 状态处理后续逻辑。

为什么新的 fetch 一创建就进入 catch？

最常见原因是复用了已经 aborted 的 AbortSignal。把控制器创建放到每次任务开始处，并确认没有在 fetch 前误调用 abort()。

如何自动移除事件监听器？

注册时传入 { signal: controller.signal }，页面或组件销毁时调用该控制器的 abort()。同一信号绑定的监听器会一起移除。