React组件里定时器没清理，会导致内存泄漏吗？

这里先说结论：不清理的定时器确实会导致内存泄漏，尤其是在 React 这类组件频繁挂载卸载的场景里，问题会更明显。

我们一步步来拆解原因和解决方案。

首先，浏览器的垃圾回收机制（GC）只负责回收“不可达对象”，也就是说，只有当一个对象不再被任何活跃引用持有时，它才会被回收。但定时器（比如 setInterval）在浏览器内部会持有一个对回调函数的引用，只要这个定时器还没被 clearInterval，它就会一直存在，即使组件已经被卸载了。

举个例子，你写的这个代码：

useEffect(() => {

  const timer = setInterval(() => {

    console.log('fetching data...');

    // 模拟轮询

  }, 5000);

}, []);

当组件卸载后，这个定时器还在继续跑——它每 5 秒执行一次回调，而回调里可能引用了组件里的某个状态、某个 API 实例、甚至整个组件实例（比如闭包捕获了 props 或 state）。只要定时器没停，它就一直持有这个引用，导致整个组件对象无法被 GC 回收。这就是内存泄漏。

更麻烦的是，如果你快速切换路由，比如用户点了好几次导航，组件挂载又卸载，每次都会创建一个新的定时器，但旧的没被清理掉，就会产生多个“幽灵定时器”，内存占用蹭蹭往上涨，过一会儿浏览器可能就卡了。

这里需要注意：React 的 useEffect 清理函数不是可选项，是必选项。你写 return () => clearInterval(timer) 并不是“可能有用”，而是“必须写”，否则就真漏了。

那正确的写法应该是这样的：

useEffect(() => {

  const timer = setInterval(() => {

    console.log('fetching data...');

    // 模拟轮询

  }, 5000);



  // 这里必须返回清理函数

  return () => {

    clearInterval(timer);

  };

}, []);

这个清理函数会在组件卸载前自动执行，把定时器关掉，断开引用链，让 GC 能正常回收。

不过你说“有时候还是漏掉，特别是快速切换路由的时候”——这其实很常见，尤其是当组件卸载逻辑比较复杂、或者有多个异步任务时，容易漏。我建议你用几个小技巧来避免这个问题：

第一个是用 useRef 记录定时器 ID，配合一个 isMounted 标志防止组件卸载后还尝试清理（虽然理论上 useEffect 的清理函数不会在已卸载组件上执行，但如果你在定时器回调里做了异步操作，比如 fetch 后 setState，那就有风险）：

useEffect(() => {

  const timerIdRef = React.useRef(null);



  timerIdRef.current = setInterval(() => {

    // 如果你担心组件已经卸载，可以加个判断

    // （虽然严格来说，useEffect 清理函数会先执行，但防御性编程总没错）

    if (timerIdRef.current === null) return;



    console.log('fetching data...');

    // 比如这里可能有 fetch，然后 setState

  }, 5000);



  return () => {

    if (timerIdRef.current !== null) {

      clearInterval(timerIdRef.current);

      timerIdRef.current = null; // 防止重复清理

    }

  };

}, []);

第二个更省心的办法是：直接封装一个自定义 Hook，专门用来管理定时器，这样每次用的时候就不用再担心漏写清理逻辑了。比如：

function useInterval(callback, delay) {

  const savedCallback = React.useRef();



  // 记住最新的 callback，避免闭包陷阱

  React.useEffect(() => {

    savedCallback.current = callback;

  }, [callback]);



  React.useEffect(() => {

    if (delay !== null) {

      const id = setInterval(() => {

        savedCallback.current();

      }, delay);

      return () => clearInterval(id);

    }

  }, [delay]);

}

然后你用的时候就简单了：

useInterval(() => {

  console.log('fetching data...');

  // 模拟轮询

}, 5000);

这样写一次，后面就再也不用操心清理的事了。

最后说个实际踩过的坑：如果你的定时器回调里做了网络请求，比如轮询接口，即使你清理了定时器，已经发出去的请求还没回来时组件就卸载了，那请求回来后如果直接调用 setState，会报错“Can’t perform a React state update on an unmounted component”。

这种情况除了清理定时器，还得在请求里加个 abort 机制（比如用 AbortController），或者至少在回调里加个 isMounted 标志，或者用 useEffect 返回一个标志位：

useEffect(() => {

  let isMounted = true;



  const timer = setInterval(() => {

    fetch('/api/data')

      .then(res => res.json())

      .then(data => {

        if (isMounted) {

          setData(data);

        }

      });

  }, 5000);



  return () => {

    isMounted = false;

    clearInterval(timer);

  };

}, []);

这种写法虽然老派，但很稳。

总之，总结一下：

- 不清理的定时器 = 明确的内存泄漏源，GC 不会自动帮你清理；
- useEffect 必须写清理函数，这是铁律；
- 快速切换时更容易暴露问题，建议封装自定义 Hook；
- 如果回调里有异步操作，还得额外防卸载后执行。

多写几次清理逻辑，慢慢就成肌肉记忆了。我刚开始也经常漏，后来直接把“return () => clearInterval(timer)”写成模板，每次复制粘贴——虽然有点笨，但至少不会再出问题了。