AbortController不只是取消请求，还能给状态管理减负

提到 `AbortController`，很多人的第一反应是「取消 fetch 请求」。它确实因此出名，但如果只把它当成 fetch 的配套工具，就浪费了这个 API 最值钱的部分：`signal` 本质上是一个通用的、可组合的、一次性的生命周期信号。而状态管理里最难的恰恰不是「怎么存数据」，是「什么时候该停下来别写了」。这两件事天然契合。

被低估的其实不是 Controller，是 signal

先理清一件事：`abort()` 是动作，`signal` 才是契约。任何接受 `signal` 的 API，都等于承诺「你让我停，我就停，并且告诉你我为什么停」。它自带三样东西：

- `signal.aborted`：同步可读的布尔状态
- `signal.addEventListener('abort', ...)`：事件通知，而且可以用 `{ once: true }`
- `signal.reason`：取消原因，配合 `AbortSignal.timeout()` 和 `AbortSignal.any()` 能区分「用户主动取消」和「超时」

现代浏览器里，`fetch`、`addEventListener`、`ReadableStream`、`WebSocket` 都已经原生接受 `signal`。这意味着你不需要自己造 `isCancelled` 标志位、不需要维护一套「已销毁」的布尔值——这些手写的状态，正是状态管理里最容易腐烂的部分。

竞态：状态管理里最常见的隐形 bug

搜索框输入「abc」，依次发出三个请求，返回顺序是 c、a、b。如果没有取消机制，最后写进状态的会是 a 的结果，而用户看到的是 abc 的输入框——数据错了，而且错得毫无声息。

常见写法是维护一个 `requestId`，用 `if (id !== latestId) return` 来挡住过期响应。能用，但每加一个异步源就要复制一遍。换成 signal 之后，逻辑从「判断该不该写」变成「根本不让它走到写的这一步」：

let controller;
async function search(keyword) {
  controller?.abort();
  controller = new AbortController();
  const res = await fetch(`/api/search?q=${keyword}`, {
    signal: controller.signal,
  });
  const data = await res.json();
  setState(data); // 能走到这里，说明它一定是最新的
}

后置的守卫变成了前置的约束，代码少一层嵌套，也不会有人忘记加判断。

把 signal 接进框架的清理时机

在 React 里，`useEffect` 的清理函数是最好的落点。一个容易被忽略的细节是：一个 effect 只需要一个 controller，而不是每个请求一个。让同一个 signal 贯穿这次 effect 里所有的请求和数据加载，清理时统一 `abort()`，语义更清晰：

useEffect(() => {
  const controller = new AbortController();
  loadDetail(id, controller.signal);
  return () => controller.abort();
}, [id]);

这顺手解决了那个老问题：组件卸载后异步回调仍然 `setState`。不是靠 `isMounted` 标志位去堵，而是从源头上让任务不再有继续执行的理由。

进一步说，可以把 signal 提升到「作用域」这一层。一个路由页面、一个弹窗会话、一次表单编辑，各自持有一个 controller，页面离开就 abort。所有挂在这个作用域下的请求、轮询、流式读取、甚至自定义的异步任务，一次全部停掉。这比在每个模块里散落地写 `dispose()` 要可靠得多。

让自定义异步逻辑也遵守这个契约

signal 真正发挥威力的地方，是你自己的异步函数也接受它。约定一个 `{ signal }` 参数，成本很低：

function wait(ms, { signal } = {}) {
  return new Promise((resolve, reject) => {
    const timer = setTimeout(resolve, ms);
    signal?.addEventListener('abort', () => {
      clearTimeout(timer);
      reject(signal.reason);
    }, { once: true });
  });
}

轮询、防抖等待、并发池、重试退避，都可以套这个模板。当所有异步操作共享同一套取消语义，状态管理里那些 `pending / cancelled / stale` 的自定义标志位就会一个一个消失。

组合能力才是它真正的加分项

`AbortSignal.timeout(3000)` 给你一个超时信号，`AbortSignal.any([a, b])` 把多个信号合成一个——任意一个触发，整体就 abort，而 `reason` 会告诉你到底是谁先动的手：

const signal = AbortSignal.any([
  userController.signal,
  AbortSignal.timeout(3000),
]);

这样「用户点了取消」和「服务端太慢」在 catch 分支里可以分开处理，UI 上也能给出不同的提示。以前实现这套逻辑要写不少样板代码，现在基本是零成本。

两个容易踩的坑

一是把 `abort()` 当成错误处理。取消是正常的控制流，`AbortError` 通常应该被静默吞掉，而不是弹一个「请求失败」的 toast。

二是忘了 signal 只能触发一次。复用已经 abort 的 signal 去发新请求，会立刻失败。所以「一个作用域一个 controller」是比较稳妥的默认策略。

另外，`signal.addEventListener` 建议显式带上清理逻辑，或者用 `{ once: true }`。虽然 signal 和 controller 通常随作用域一起被回收，但在长时间存活的 signal 上挂监听器仍然是内存泄漏的常见来源。

小结

`AbortController` 表面上是个取消工具，实际上提供的是一套标准化的生命周期协议：谁发起、谁负责结束、为什么结束。当你把它从「fetch 的附属品」提升为「异步作用域的信号源」，会发现状态管理里少了一大半的布尔标志位和防御性判断。真正需要被管理的状态变少了，剩下的状态自然就更好管。