AbortController：你一直在跳过的异步清理模式

你写的异步代码很可能藏着一个 bug：它在该停的时候停不下来。

用户中途离开了页面，请求还在跑。组件卸载了，请求还在跑。用户输入了新的搜索词，旧的请求还在跑。然后呢？旧的请求完成了，试图更新一个已经不存在的 state。在 React 里，你会看到那个臭名昭著的警告："Can't perform a React state update on an unmounted component." 在普通的 JavaScript 里，它悄无声息地给你塞进来一堆过时的数据，连个提示都没有。

AbortController 是浏览器自带的解决方案。从 2018 年开始，所有主流浏览器都支持它——这都过去多少年了，真的没有理由不用。但现实是：大多数教程跳过它，大多数项目里用得七零八落，大多数开发者只有在被竞态条件折磨到抓狂之后才想起来用它。

今天我们就把它说透，从原理到实战，一步不落。

那个你肯定遇到过的竞态条件

先看一个再常见不过的 React 组件：

function SearchResults({ query }: { query: string }) {
  const [results, setResults] = useState<Result[]>([]);

  useEffect(() => {
    fetch(`/api/search?q=${query}`)
      .then(r => r.json())
      .then(data => setResults(data));
    // 注意：这里没有清理，query 变了之后旧的 fetch 还在跑
  }, [query]);

  return <ul>{results.map(r => <li key={r.id}>{r.name}</li>)}</ul>;
}

用户先输入了 "re"，然后又输入了 "rea"。第一个请求还没回来，第二个请求已经发出去了。现在两个 fetch 同时在跑。

问题来了：网络是不可靠的。请求 "re" 的数据包可能因为路由绕了一圈，反而比请求 "rea" 晚回来。当它终于回来的时候，setResults(data) 会直接把正确的结果覆盖掉——用户看到的是 "re" 的结果，而不是 "rea" 的结果。

这还不是最可怕的。更坑的是：没有任何错误，没有任何警告。用户看到的是错误的数据，但你完全不知道。

这不是理论上的可能性。在慢速网络下、在用户快速打字时、在低端设备上、在演示前五分钟的 staging 环境里——它一定会发生。相信我，我踩过这个坑，而且不止一次。

AbortController：三行代码的救星

AbortController 其实就两个东西：一个控制器对象，一个信号（signal）。你把信号传给任何支持中止的 API，然后在需要的时候调用 abort() 来取消它。

看修复后的代码：

useEffect(() => {
  const controller = new AbortController();

  fetch(`/api/search?q=${query}`, {
    signal: controller.signal
  })
    .then(r => r.json())
    .then(data => setResults(data))
    .catch(err => {
      if (err.name !== 'AbortError') throw err;
      // 主动取消的请求，直接吞掉，不处理
    });

  return () => controller.abort(); // query 变了或者组件卸载时触发
}, [query]);

这里发生了什么？当 query 变化时，React 会先执行上一个 effect 的清理函数，然后再重新运行 effect。controller.abort() 被调用后，上一个 fetch 会立即以 AbortError 拒绝——在它有机会更新 state 之前就被干掉了。新的 fetch 则拿着一个新的 controller 重新开始。

整个模式只有三个步骤：

1. 在 effect 开头创建一个 controller：const controller = new AbortController()
2. 把 signal 传给 fetch：fetch(url, { signal: controller.signal })
3. 在清理函数里调用 abort：return () => controller.abort()

就这三行，其他代码都不用动。简单到令人发指，但效果立竿见影。

那个你绝对不能跳过的 AbortError

这里有个坑，几乎每个人都会踩一次。

当你取消一个 fetch 时，它是以一个错误的形式拒绝的——这个错误的名字叫 "AbortError"。它看起来像失败，但实际上是预期的行为。如果你不处理它，这个错误会一路冒泡到你的错误边界或者 catch 块里，每次组件卸载都触发一次。

用 async/await 写也是一样的道理：

useEffect(() => {
  const controller = new AbortController();

  async function load() {
    try {
      const res = await fetch(`/api/search?q=${query}`, {
        signal: controller.signal
      });
      const data = await res.json();
      setResults(data);
    } catch (err) {
      // 关键：先判断是不是 AbortError
      if (err instanceof Error && err.name === 'AbortError') return;
      // 其他真正的错误才处理
      setError('Something went wrong');
    }
  }

  load();
  return () => controller.abort();
}, [query]);

那个 if (err.name === 'AbortError') return; 看起来不起眼，但它是必须的。跳过这个检查是使用 AbortController 时最常见的错误，没有之一。

为什么？因为如果你不处理，每次组件卸载或者依赖变化，你的 catch 块都会被执行。如果你的 catch 块里调用了 setError 或者别的 setState，那你又回到了起点——试图更新一个已经不存在的组件。

不止是 fetch：用 AbortController 清理事件监听器

AbortController 不是只能用来取消网络请求。你可能不知道，addEventListener 也支持 signal 选项。当 signal 被中止时，所有通过它注册的监听器都会被自动移除。

来看一个实际的例子。假设你有一个自定义 hook，用来注册键盘快捷键：

function useKeyboardShortcuts(handler: (e: KeyboardEvent) => void) {
  useEffect(() => {
    const controller = new AbortController();
    const { signal } = controller;

    window.addEventListener('keydown', handler, { signal });
    window.addEventListener('keyup', handler, { signal });
    window.addEventListener('keypress', handler, { signal });

    return () => controller.abort(); // 一次调用，移除全部三个监听器
  }, [handler]);
}

以前怎么做？你得把每个监听器的引用存下来，然后挨个调用 removeEventListener：

// 老方式
useEffect(() => {
  const onKeyDown = (e: KeyboardEvent) => { /* ... */ };
  const onKeyUp = (e: KeyboardEvent) => { /* ... */ };
  
  window.addEventListener('keydown', onKeyDown);
  window.addEventListener('keyup', onKeyUp);
  
  return () => {
    window.removeEventListener('keydown', onKeyDown);
    window.removeEventListener('keyup', onKeyUp);
  };
}, [handler]);

三个监听器就得写三行清理代码。如果你有十个呢？而且很容易犯一个错：你添加的时候传了一个匿名函数，清理的时候想移除却找不到引用——监听器就永远挂在那里了。

用 AbortController，所有监听器共享同一个 signal，一次 abort() 全部移除。代码更短，更不容易出错。你不用担心忘了移除某个后来添加的监听器，因为它们都绑定在同一个 signal 上。

什么时候该用，什么时候不该用

AbortController 不是万能的，它有自己的适用场景。

应该用：

• 数据获取，尤其是依赖用户输入的场景：搜索框、分页列表、筛选器——任何 effect 会随着依赖变化重新运行的地方。这些场景下，竞态条件是家常便饭。
• 轮询：当你启动了一个 interval 或者递归的 setTimeout，它应该在组件卸载时停止。否则你的应用会在用户离开后还在后台不停地发请求。
• 多个相关的事件监听器：一次性设置，一次性拆除，不会有 add/remove 不匹配的问题。

不应该用：

• 有意识的"发后不管"操作：比如表单提交、发送消息。用户提交了表单，即使他立刻导航到别的页面，你也希望这个请求能完成。中途取消一个支付或者一条消息，后果比一个过时的更新更糟糕。
• 服务端有副作用的写操作：记住，AbortController 只在客户端生效。取消 fetch 只是让你的代码看不到响应，它并不能阻止服务端继续处理这个请求。如果你取消了一个创建订单的请求，服务端可能已经把订单创建好了，只是你不知道而已。

核心原则：读取数据和订阅——可以中止。有副作用的写操作——让它们完成。

总结一下

AbortController 不需要你引入任何第三方库，不需要配置构建工具，也不需要学习新的思维模式。它就是一个构造函数、一个 signal、一个方法。

模式就三行代码，在任何 useEffect 里都能用：

const controller = new AbortController();
// ... 把 signal 传给 fetch 或 addEventListener ...
return () => controller.abort();

如果你在 useEffect 里用 fetch 却没有加 AbortController，你的代码里就有一个竞态条件。用户可能已经看到了——一个闪烁、一个突然跳回之前状态的搜索结果、一个他们说不清楚的控制台警告。

现在你知道了原因，也知道怎么修。花几分钟加上三行清理代码，问题就解决了。

每一个有明确生命周期的异步操作，都需要一个取消机制。浏览器已经免费给了你，别浪费它。