前端 React useEffect 竞态 怎样处理

React 的 useEffect 竞态，通常不是“请求发错了”，而是多个请求的返回顺序和用户最后一次输入顺序不一致。比如用户先输入 re，随后输入 react：后一个请求可能先返回，但前一个请求晚到后又把旧列表写回页面。

更稳妥的处理是分两层：cleanup 中设置失效标记，保证旧响应不能提交；如果请求支持取消，再用 AbortController 在依赖变化或组件卸载时中止旧的 fetch。官方地址：https://react.dev/reference/react/useEffect

判断修复是否有效，不要只看页面“多数时候正常”。至少记录旧响应被拦截次数、请求取消次数和当前响应耗时，才能知道竞态窗口是否真的被关闭。

先识别 useEffect 的竞态窗口

每次依赖变化都会创建一轮新的 Effect。React 会先运行上一轮 cleanup，再运行新一轮 setup；网络响应却可能按自己的顺序回来。真正需要保护的是“这次响应是否仍对应当前输入”，而不是简单给请求加一个延时。

下面的示例把搜索词作为依赖，并把响应写回限定在当前 Effect 仍有效的闭包内：

import { useEffect, useState } from 'react';

function SearchBox({ query }) {
  const [result, setResult] = useState(null);

  useEffect(() => {
    let ignore = false; // cleanup 会让上一轮响应失去写回资格

    setResult(null);
    fetch(`/api/search?q=${encodeURIComponent(query)}`)
      .then(response => response.json())
      .then(data => {
        if (!ignore) { // 只允许仍属于当前输入的响应更新状态
          setResult(data);
        }
      })
      .catch(error => {
        if (!ignore) {
          console.error('搜索失败', error); // 当前请求的错误才展示给用户
        }
      });

    return () => {
      ignore = true; // 依赖变化或卸载时关闭旧响应通道
    };
  }, [query]);

  return 
{JSON.stringify(result, null, 2)}
;
}

用 cleanup 屏蔽旧响应

ignore 解决的是“旧响应已经回来，但不能再改变当前状态”的问题。它不保证旧请求立刻停止，也不会减少服务器已经收到的请求；优点是边界简单，适合任何返回 Promise 的数据源。

这里有三个容易漏掉的点：

• 把 query 放进依赖数组，否则闭包可能一直使用旧查询词。
• 成功和失败分支都要检查失效标记，避免旧错误覆盖当前结果。
• 不要把购买、提交订单等由点击触发的副作用硬塞进 Effect；这类动作应放在事件处理器中。

React 开发模式下的 Strict Mode 还会额外执行一次 setup-cleanup-setup，用来暴露缺少清理的问题。只要 cleanup 与 setup 对称，重复初始化不会改变最终行为。

用 AbortController 取消请求

如果底层是浏览器 fetch，可以把“禁止旧响应写回”和“停止旧请求”一起做。AbortController.abort() 能中止 fetch、响应体消费和相关流；但取消本身会以 AbortError 进入异常分支，所以不要把主动取消误报成业务失败。

useEffect(() => {
  const controller = new AbortController(); // 为本轮请求创建独立取消控制器
  let ignore = false; // 即使取消时机较晚，也阻止旧数据写回

  async function load() {
    try {
      const response = await fetch(`/api/search?q=${encodeURIComponent(query)}`, {
        signal: controller.signal, // 把取消信号交给 fetch
      });
      const data = await response.json();
      if (!ignore) {
        setResult(data); // 只有当前 Effect 才能提交结果
      }
    } catch (error) {
      if (error.name === 'AbortError') {
        return; // 主动取消不是用户可见的请求失败
      }
      if (!ignore) {
        setError(error); // 只上报当前请求的真实错误
      }
    }
  }

  load();
  return () => {
    ignore = true;
    controller.abort(); // 依赖变化或卸载时释放旧请求
  };
}, [query]);

两层保护不要互相替代：AbortController 负责尽早释放浏览器侧资源，ignore 负责兜住取消竞态、非 fetch 数据源和已经进入回调队列的旧结果。

用指标判断修复是否生效

可以在开发环境或可控的埋点层记录四个数：请求开始数、正常响应数、主动取消数、因 ignore 被拦截的响应数。输入变化很快时，取消数和拦截数上升并不一定是坏事，它说明旧请求确实经过了竞态边界。

如果页面使用 TanStack Query、SWR 或框架内置数据获取机制，应优先遵循它们的缓存、去重和取消约定。手写 Effect 适合边界较小的场景，但当请求依赖、缓存和重试不断增加时，自定义 Hook 或数据层通常更容易维护。

相关问题

只写 AbortController 就够了吗？不一定。响应可能已经进入回调队列，或者数据源根本不支持 AbortSignal，仍建议保留有效性标记。

为什么不能把依赖数组写成空数组？因为 Effect 使用了会变化的 query；省略依赖会让请求与页面输入脱节，并掩盖闭包中的旧值。

Strict Mode 导致请求发送两次是不是线上 bug？开发模式的额外 setup-cleanup 是 React 用来检查清理逻辑的机制。重点是让 cleanup 真正断开连接、取消请求或阻止旧响应，而不是删除依赖。

总结

React useEffect 竞态的核心不是让请求“按顺序返回”，而是让旧响应失去写回资格。先用 cleanup 设置 ignore，再为可取消的 fetch 接入 AbortController，最后用取消数和拦截数观察修复效果，页面状态就能稳定跟随最后一次有效输入。