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

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

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

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

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

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

最容易暴露问题的是事件监听。下面的 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 里。

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

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

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

常见问题

关闭 Strict Mode 就能解决重复请求吗？

只能隐藏开发检查，不能修复请求竞态、重复订阅或缺失清理。应先确认 setup 与 cleanup 对称，再决定是否调整开发配置。

依赖数组写空数组就只执行一次吗？

它表示没有响应式依赖变化时不再重跑，但开发 Strict Mode 仍可能进行额外的 setup-cleanup 检查；空数组也不能掩盖对 props 或 state 的读取。

cleanup 一定只在卸载时执行吗？

不是。依赖改变时会先执行旧 Effect 的 cleanup，随后执行新 Effect 的 setup；Strict Mode 的开发检查也会提前触发一次。

为什么请求取消后仍能在网络面板看到一次记录？

取消发生在请求发出之后，网络面板可能保留已发出的记录。需要关注取消后的状态更新和服务端副作用，不能仅以记录条数判断 Effect 是否正确。