在 useEffect 中，如何正确地处理异步请求并避免竞态条件（Race Condition）？

在 useEffect 中正确处理异步请求，告别竞态条件

在 React 开发中，我们经常需要在组件加载后发起异步请求来获取数据，useEffect Hook 是处理这类副作用的理想场所。然而，一个看似简单的操作，却暗藏着一个常见且棘手的问题：竞态条件（Race Condition）。

如果不加以控制，竞态条件会导致组件状态错乱，甚至在组件卸载后尝试更新状态而引发内存泄漏警告。本文将深入探讨这个问题的成因，并提供两种清晰、有效的解决方案。

什么是竞态条件？

想象一个场景：我们有一个搜索框，用户每次输入都会更新一个 query 状态，并触发 useEffect 来根据 query 获取搜索结果。

当用户快速输入 "ab" 时，可能会发生以下情况：

1. 用户输入 "a"，useEffect 触发，向服务器发起对 "a" 的请求（请求 A）。

2. 在请求 A 返回前，用户迅速输入 "b"，query 变为 "ab"。useEffect 再次触发，发起对 "ab" 的请求（请求 B）。

3. 由于网络延迟等不确定因素，请求 B 先于请求 A 返回。此时，组件状态更新，正确显示 "ab" 的搜索结果。

4. 紧接着，请求 A 返回了。它执行了状态更新，用 "a" 的搜索结果覆盖了刚刚才正确显示的 "ab" 的结果。

最终，用户输入的是 "ab"，但界面上却显示着 "a" 的结果。这就是典型的竞态条件。

另一个常见问题是，如果在请求返回前组件就卸载了（例如用户切换了页面），异步操作的回调函数仍然会尝试更新一个已经不存在的组件状态，这会导致 React 报出 "Can't perform a React state update on an unmounted component" 的警告。

错误的尝试：直接使用 async/await

为了处理异步，我们很自然地会想到 async/await。一些初学者甚至有经验的开发者，可能会写出类似下面的代码：

// 这是一个错误示范！
useEffect(async () => {
  const result = await fetchData(id);
  setData(result);
}, [id]);

这段代码无法正常工作，原因在于 useEffect 的第一个参数，它要么不返回任何东西，要么返回一个清理函数（cleanup function）。而一个 async 函数会隐式地返回一个 Promise，这违背了 useEffect 的设计规则。更重要的是，它完全没有解决我们上面提到的竞身问题。

解决方案：利用 useEffect 的清理机制

解决这个问题的关键，在于 useEffect 的清理（cleanup）机制。useEffect 返回的函数会在两个时机被调用：

1. 当组件卸载时。

2. 在下一次 useEffect 即将执行前（当依赖项发生变化时）。

这为我们提供了一个绝佳的机会，来“取消”上一次未完成的异步操作。

方法一：使用布尔标记（isMounted Flag）

一种经典且直观的思路是在组件挂载时设置一个标记，在卸载时取消这个标记。只有当标记存在时，我们才更新状态。

useEffect(() => {
  let isMounted = true; // 1. 设置标记

  fetchData(id).then(result => {
    if (isMounted) { // 3. 更新状态前，检查标记
      setData(result);
    }
  });

  return () => {
    isMounted = false; // 2. 组件卸载或依赖变化时，取消标记
  };
}, [id]);

工作原理：

当 id 变化，准备执行新的 effect 时，上一个 effect 的清理函数会先执行，将其作用域内的 isMounted 变量设为 false。这样一来，即使先前发出的请求现在才返回，由于 isMounted 为 false，setData 也不会被调用，从而避免了用旧数据覆盖新数据的问题。组件卸载时同理。

这种方式虽然有效，但略显繁琐，并且无法真正中止已经发出的网络请求，造成了轻微的资源浪费。

方法二：使用 AbortController（推荐）

一个更现代且推荐的做法是使用 AbortController。这是一个标准的 Web API，专门用于中止一个或多个 Web 请求。

useEffect(() => {
  // 1. 创建 AbortController 实例
  const controller = new AbortController();

  const fetchData = async () => {
    try {
      const response = await fetch(`/api/data?id=${id}`, {
        signal: controller.signal, // 2. 将 signal 传递给 fetch
      });
      const data = await response.json();
      setData(data);
    } catch (error) {
      if (error.name === 'AbortError') {
        // 请求被中止是预期的行为，可以静默处理
        console.log('Fetch aborted');
      } else {
        // 处理其他错误
        console.error('Fetch error:', error);
      }
    }
  };

  fetchData();

  // 3. 在清理函数中调用 abort
  return () => {
    controller.abort();
  };
}, [id]);

工作原理：

1. 在每次 useEffect 执行时，我们都创建一个新的 AbortController 实例。

2. 我们将它的 signal 属性作为 fetch 请求的一个选项。这个 signal 会将 controller 和 fetch 请求关联起来。

3. 当清理函数执行时（组件卸载或 id 变化），controller.abort() 会被调用。浏览器会立即中止这个 fetch 请求。

4. 一个被中止的 fetch 会抛出一个名为 AbortError 的错误，我们可以通过 try...catch 块捕获它，并阻止后续的状态更新。

这种方法不仅优雅地解决了竞态条件，还真正地取消了不必要的网络请求，节约了浏览器和服务器的资源，是目前处理此类问题的最佳实践。

总结

处理 useEffect 中的异步操作时，我们必须时刻警惕竞态条件和组件卸载后的状态更新问题。

• 核心原则：务必利用 useEffect 返回的清理函数来处理副作用的“取消”逻辑。

• 经典方法：使用一个布尔标记（如 isMounted）来决定是否执行状态更新。它简单直观，但无法中止请求。

• 推荐实践：使用 AbortController 来真正地中止 fetch 请求。它更健壮、更高效，是现代 Web 开发的首选方案。

掌握了 useEffect 的清理机制，我们就能更自信地处理各种异步副作用，写出更健壮、更可预测的 React 组件。