当前位置：首页 > 文章列表 > 文章 > 前端 > 前端 React useEffect 竞态怎样处理

前端 React useEffect 竞态怎样处理

来源：17golang原创 2026-10-22 19:29:19 0浏览收藏

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)};
}

React useEffect 竞态中 query、cleanup、ignore 标记与 setResult 的静态结构关系 — 图1：React useEffect 竞态防护的静态结构说明图，cleanup 让旧响应失去写回资格，不是运行截图。

用 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、signal、fetch 和 AbortError 的静态依赖关系 — 图2：AbortController 与 fetch 的资源边界说明图，展示取消信号和异常分支，不是浏览器截图。

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

用指标判断修复是否生效

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

现象	优先检查	处理方向
旧结果偶尔覆盖新结果	cleanup 是否设置失效标记	成功与失败回调都检查 ignore
网络面板仍有大量旧请求	是否把 signal 传给 fetch	创建独立 controller 并在 cleanup 中 abort
取消请求被当成报错	是否区分 AbortError	主动取消直接结束异常分支

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