当前位置：首页 > 文章列表 > 文章 > 前端 > React useEffect 清理函数为什么会在开发模式执行两次

React useEffect 清理函数为什么会在开发模式执行两次

来源：17golang原创 2026-09-09 01:00:53 0浏览收藏

看到 useEffect 的清理函数在开发环境执行两次，通常不是 React 把组件错误地挂载了两遍，而是 StrictMode 在首次真实同步前主动做了一次压力检查。开发期可能出现 setup → cleanup → setup，生产构建按正常挂载只执行一次 setup。正确处理方式是让 cleanup 完整撤销 setup 做过的事，而不是用 useRef 把第二次执行藏起来。

如果一个 Effect 在“连接—断开—再次连接”后仍能得到和只连接一次相同的用户可见结果，它就能同时适应 Strict Mode、依赖变化和组件卸载。

要点速览

开发模式多出来的是一次 setup+cleanup 检查，不能据此判断生产会发送两次请求。
事件监听、定时器、WebSocket 等外部资源必须在返回的 cleanup 中成对移除或关闭。
请求要处理过期响应；依赖数组应描述真实读取的响应式值，不要用防重标记掩盖设计问题。

先看清 setup、cleanup 和 Strict Mode 的边界

useEffect(setup, dependencies) 用来让组件与外部系统同步。setup 可以返回 cleanup；依赖改变时，React 会先用旧值执行 cleanup，再用新值执行 setup；组件从 DOM 移除时还会执行最后一次 cleanup。开发 Strict Mode 额外插入的正是一次完整的 setup 与 cleanup，用来验证两者是否对称。

现象	实际含义	应该检查什么
控制台出现 setup、cleanup、setup	开发期 Strict Mode 压力测试	cleanup 是否撤销全部外部副作用
依赖变化后先清理再重建	组件正在同步到新输入	依赖是否包含 Effect 读取的响应式值
生产请求只出现一次	额外检查不属于生产行为	业务是否把副作用错误放进 Effect

React useEffect 开发检查与生产挂载的生命周期边界关系图 — 图1：用开发检查边界和生产挂载边界区分 setup、cleanup 的静态关系；重点看 cleanup 是否能撤销 setup。

让订阅、定时器和连接严格成对

最容易暴露问题的是事件监听。下面的 Effect 在窗口尺寸变化时订阅，在清理时移除同一个函数引用。定时器、WebSocket、第三方实例也遵循同一原则：setup 创建什么，cleanup 就销毁什么。

useEffect(() => {
  const handleResize = () => {
    // 读取最新布局并更新组件需要的状态
    setWidth(window.innerWidth);
  };

  window.addEventListener('resize', handleResize);
  const timerId = window.setInterval(() => {
    // 定时任务只负责触发同步，不在这里累积监听器
    refreshPreview();
  }, 30_000);

  return () => {
    // 移除同一个函数引用，避免监听器残留
    window.removeEventListener('resize', handleResize);
    // 清除本次 setup 创建的定时器
    window.clearInterval(timerId);
  };
}, [refreshPreview]);

这里的关键不是让回调“只进来一次”，而是让每个 setup 都有独立的资源集合。若 refreshPreview 在组件内每次渲染都会生成新函数，Effect 也会重新同步；可以通过稳定回调或把不必要的依赖移出组件解决，但不能直接删掉依赖。

请求响应要防止旧结果覆盖新状态

请求的难点不同：网络响应无法仅靠 cleanup 让 Promise 消失，组件切换后旧响应仍可能回来。可以用 AbortController 取消支持取消的 fetch，同时在 catch 中忽略主动取消；对不支持取消的客户端，则至少保留一个失效标志，禁止旧结果写入当前状态。

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

  async function loadUser() {
    try {
      // 依赖变化或卸载时由 cleanup 发出取消信号
      const response = await fetch(`/api/users/${userId}`, {
        signal: controller.signal
      });
      const data = await response.json();
      if (active) {
        // 只接收当前 userId 对应的响应
        setUser(data);
      }
    } catch (error) {
      if (error.name !== 'AbortError' && active) {
        // 真正的网络错误才进入错误状态
        setError(error);
      }
    }
  }

  loadUser();
  return () => {
    // 先阻止迟到响应，再取消底层请求
    active = false;
    controller.abort();
  };
}, [userId]);

这段写法不承诺任何接口“绝不收到两次请求”：开发期的第一次 setup 可能已经发出请求，取消发生在随后 cleanup。它保证的是旧响应不会污染当前状态。若项目使用框架或客户端缓存，优先采用其数据获取机制，避免把缓存、预加载和竞态控制全部手写在 Effect 里。

React useEffect 订阅定时器请求与 cleanup 资源边界关系图 — 图2：把事件监听、定时器和请求放在各自的资源边界内，理解 cleanup 如何撤销监听、计时器与过期响应。

不要用 ref 把第二次执行藏起来

常见的“修复”是设置 const ran = useRef(false)，第二次进入时直接 return。这样虽然让日志暂时安静，却破坏了依赖变化时重新同步的能力，也无法清理第一次 setup 已经创建的资源。只有在确实表达“组件生命周期外的单例资源”时，才应把它提升到合适的模块或缓存层；普通订阅和请求不属于这种情况。

排查时按这张清单走：第一，确认是否包在内；第二，列出 setup 触碰的每个外部系统；第三，逐项对应 remove、clear、close、abort 或失效标记；第四，检查依赖数组是否包含实际读取的 props、state 和组件内函数；第五，分别用开发构建和生产构建观察日志。React 文档也提醒，如果没有要同步的外部系统，很多场景根本不需要 Effect。