React useEffect 竞态请求的取消方案

我在做一个“输入即搜索”的页面时，最容易忽略的不是 fetch 写法，而是请求返回顺序：用户先输入 r，又很快输入 react，后发出的请求可能先完成，也可能先发出的请求反而最后完成。若两个请求都直接调用 setData，旧结果就会覆盖新结果。

这篇只处理这一类竞态。推荐把每次 useEffect 运行看成一个独立请求单元：清理旧单元时调用 AbortController.abort()，响应回来后再用活动标记保护状态写入。React 官方地址：https://react.dev/reference/react/useEffect。

核心原则：依赖变化先清理旧请求；新请求携带自己的 signal；取消属于正常收尾，只有仍然有效的结果才能写入状态。

为什么 useEffect 会出现竞态

React 会在依赖变化后先运行上一次 Effect 的清理函数，再运行新的 setup。问题在于，清理函数只能表示“这个请求已经不再服务当前参数”，不能自动让已经返回的 Promise 消失。网络响应仍可能进入回调，所以状态提交必须再有一层保护。

这里要区分两件事：取消请求是资源层动作，避免继续消费不需要的响应；丢弃旧结果是状态层动作，避免失效数据进入界面。只做其中一件，另一层仍可能留下问题。

在清理阶段取消上一条 Fetch

每次 Effect 运行都创建自己的控制器，并把 controller.signal 传入 fetch。下一次查询到来时，清理函数调用 abort。MDN 将 AbortController 定义为可以中止一个或多个 Web 请求的控制器，abort() 也能中止响应体和流的消费。

import { useEffect, useState } from 'react';

export function SearchResult({ keyword }) {
  const [data, setData] = useState(null);
  const [error, setError] = useState(null);

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

    async function load() {
      try {
        // signal 让这次请求受当前 Effect 的清理动作控制。
        const response = await fetch(`/api/search?q=${encodeURIComponent(keyword)}`, {
          signal: controller.signal,
        });
        // fetch 遇到 404/500 不一定 reject，所以要显式检查响应状态。
        if (!response.ok) throw new Error(`HTTP ${response.status}`);
        const result = await response.json();
        // 未被取消的请求才允许提交当前查询结果。
        setData(result);
        setError(null);
      } catch (cause) {
        // AbortError 是参数变化或卸载造成的正常收尾，不弹错误提示。
        if (cause.name === 'AbortError') return;
        setError(cause);
      }
    }

    load();
    return () => {
      // 依赖变化或组件卸载时，终止仍属于旧查询的请求。
      controller.abort();
    };
  }, [keyword]);

  return error ? 
加载失败：{error.message}
 : 
{JSON.stringify(data)}
;
}

注意 response.ok 的判断和 AbortError 分支。前者避免把 HTTP 错误当成正常 JSON，后者避免用户每输入一个字符就看到一次“请求失败”。

无法取消时用 active 标记挡住旧结果

不是所有异步工作都接受 AbortSignal。例如某个旧版 SDK 只返回 Promise，或者请求已经进入无法撤回的业务处理。这时仍可以在 Effect 内维护一个只属于本次运行的 active 变量：清理时设为 false，异步结果回来后先判断它，再决定是否调用状态 setter。

useEffect(() => {
  let active = true;
  const controller = new AbortController();

  getLegacyData(keyword, { signal: controller.signal })
    .then((result) => {
      // 即使底层任务不能真正停止，失效结果也不能更新界面。
      if (active) setData(result);
    })
    .catch((cause) => {
      // 取消和失效实例都不应覆盖当前界面的错误状态。
      if (active && cause.name !== 'AbortError') setError(cause);
    });

  return () => {
    // 两层保护：能取消的任务终止，不能取消的结果丢弃。
    active = false;
    controller.abort();
  };
}, [keyword]);

active 不是为了模拟取消网络连接，而是为了限制“谁有资格写状态”。它与控制器可以同时存在：控制器负责尽早释放可取消的请求，标记负责兜底不可取消的异步结果。

依赖和 Strict Mode 要怎么检查

把 Effect 中使用的 keyword 放入依赖数组，不要用空数组掩盖查询变化。React 开发模式的 Strict Mode 可能在首次挂载时额外执行一次 setup/cleanup，这正好能暴露没有清理请求、重复订阅或未重置标记的问题。正确代码应当在每次 setup 创建新的控制器和标记，并让 cleanup 对应撤销它们。

• 输入变化：旧控制器先 abort，新 Effect 再创建控制器。
• 取消异常：直接结束，不写入错误状态。
• HTTP 错误：检查 response.ok 后按真实失败处理。
• 不可取消任务：用 active 阻止旧结果调用 setData。

常见问题

调用 abort 后服务器一定停止了吗？ 不一定。它主要中止浏览器侧请求和响应体消费，服务端已经开始的处理可能仍会继续，因此不要把 abort 当作服务端事务回滚。

只判断 active，不调用 abort 可以吗？ 可以防止旧结果写状态，但不能尽早停止浏览器侧资源消耗。能传 signal 时，优先把取消和结果保护一起做。

为什么不能在 catch 里统一显示失败？ 取消通常会以 AbortError 进入 catch；把它和真实网络故障混在一起，会让正常的输入变化变成错误提示。

这套写法的边界很明确：Effect 管生命周期，AbortController 管可取消资源，active 管状态提交资格。把三者分开后，竞态请求就不再依赖“猜哪个响应先回来”。