React 定时器为什么越开越多：useEffect 清理怎么写

React 页面里的数字越跳越快、轮询请求越来越密，通常不是 setInterval 自己变快了，而是同一个组件反复创建了多个定时器。最常见的原因是把 setInterval 放进 useEffect 后没有在返回函数里调用 clearInterval，或者依赖数组变化时创建了新定时器，却没有撤掉旧的。

修复原则很简单：每次 Effect setup 创建一个定时器，就必须在同一个 Effect 的 cleanup 中清掉它；依赖数组只写真正参与副作用的响应式值，计数器更新优先使用函数式写法。

先确认：变快的是回调，还是定时器数量

排查时先给每个定时器记录一个本地 ID，并同时记录 setup 和 cleanup。不要只看页面上的数字，因为一次回调里如果更新了同一个状态，视觉上很难判断到底是间隔变短还是回调叠加。

import { useEffect, useState } from 'react';

function RefreshCounter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const timerId = window.setInterval(() => {
      // 使用函数式更新，读取更新前的最新值，避免依赖旧闭包。
      setCount(current => current + 1);
    }, 1000);

    console.log('创建定时器', timerId);

    return () => {
      // cleanup 必须清掉本次 setup 创建的同一个定时器。
      window.clearInterval(timerId);
      console.log('清理定时器', timerId);
    };
  }, []);

  return 刷新次数：{count};
}

如果日志里出现多个“创建定时器”，却没有数量相同的“清理定时器”，问题就在 Effect 生命周期，而不是计时精度。上图把组件、Effect、浏览器定时器和 cleanup 的边界放在一起，便于先找出缺口。

把 setup 和 cleanup 写成一对

React 文档把 Effect 描述为与外部系统同步的过程，浏览器定时器正是外部系统。组件首次提交后执行 setup；依赖发生变化时，React 先用旧值运行 cleanup，再用新值运行 setup；组件从 DOM 移除时还会执行最后一次 cleanup。因此，清理函数不是“组件销毁时的可选优化”，而是定时器副作用的一半。

下面这个写法的问题在于每次 Effect 运行都新增一个 interval，却没有保存并释放它：

useEffect(() => {
  // 错误：每次 Effect 运行都会再创建一个定时器。
  window.setInterval(() => {
    setCount(current => current + 1);
  }, 1000);
});

即使暂时把依赖数组改成空数组，也不能替代 cleanup：组件被隐藏、卸载或重新挂载时，旧资源仍可能存活。正确做法是让创建和销毁靠近书写，并使用同一个 ID：

useEffect(() => {
  const timerId = window.setInterval(() => {
    // 函数式更新不要求把 count 放进依赖数组。
    setCount(current => current + 1);
  }, 1000);

  return () => {
    // 只清理本次 setup 创建的资源。
    window.clearInterval(timerId);
  };
}, []);

依赖数组变化时，先清旧定时器

如果间隔时间或订阅对象由 props、state 决定，就应把它们写入依赖数组。例如定时刷新间隔来自 delay：

function PollingCounter({ delay }) {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const timerId = window.setInterval(() => {
      // 让每次 tick 基于最新状态计算，不依赖旧 count。
      setCount(current => current + 1);
    }, delay);

    return () => {
      // delay 改变前先释放旧 interval，避免两个频率同时运行。
      window.clearInterval(timerId);
    };
  }, [delay]);

  return 刷新次数：{count};
}

这里不能为了“只运行一次”而强行写成空数组。Effect 使用了响应式值 delay，就要声明它；否则代码表达的是“永远使用第一次的间隔”，而不是“跟随当前间隔同步”。同时，setCount(current => current + 1) 让计时回调不必依赖当前的 count，可以避免因每次计数都重建定时器。

Strict Mode 为什么会暴露重复定时器

开发环境启用 Strict Mode 时，React 会在第一次真正 setup 前额外执行一次 setup → cleanup，用来测试清理逻辑是否能撤销 setup 做的事情。一个完整的 Effect 应该让用户分辨不出“只运行一次”和“先创建、清理、再创建”的差异。

所以看到两次创建日志时，先不要加 useRef 标志位阻止第二次。应先确认第一次创建的 ID 是否被清掉。若 setup 连接了定时器，cleanup 就必须清理定时器；若 setup 注册事件，cleanup 就必须移除同一个事件处理函数。把开发检查当成泄漏探测器，通常比把它关闭更容易维护。

发布前用这份清单复查

• 每个 setInterval 是否都对应同一 Effect 内的 clearInterval？
• 依赖数组是否包含 Effect 读取的响应式值？不需要的 count 是否已经改成函数式更新？
• 切换页面、隐藏组件或改变 delay 后，旧 ID 是否出现清理日志？
• Strict Mode 下 setup → cleanup → setup 后，页面是否仍只有一个有效定时器？

常见问题

为什么空依赖数组仍然可能看到两次 setup？

开发环境 Strict Mode 会额外做一次 setup/cleanup 检查。空依赖数组只表示普通更新时不因响应式值变化而重跑，并不关闭这项开发检查。

clearTimeout 能清理 setInterval 吗？

浏览器通常共享定时器编号池，但代码应保持一一对应：setInterval 配 clearInterval，setTimeout 配 clearTimeout，这样意图清楚，也避免换运行环境后产生误解。

为什么不把 timerId 放到 state 里？

定时器 ID 是副作用资源句柄，不需要驱动渲染。放在 Effect 的局部变量里并由 cleanup 关闭，生命周期更短；如果跨多个回调共享句柄，再考虑 useRef，但仍要在 cleanup 中释放。

React 定时器“越开越多”的根因，归根结底是资源生命周期没有和 Effect 生命周期对齐。把创建、依赖和清理放在同一段代码里，再用 Strict Mode 的额外检查验证对称性，通常就能稳定解决。