setinterval未清除会导致内存泄漏，因其回调闭包持续持有组件实例、dom节点等引用，使垃圾回收无法释放；组件卸载后定时器仍运行，叠加触发更加剧泄漏。
它不是“故意咬住”，而是 JavaScript 的引用机制和垃圾回收规则自然导致的结果：只要定时器还在跑，它的回调函数就始终是“活的”，而这个回调一旦捕获了组件数据，那些数据就变成“可达对象”，GC 无法清理。
闭包让销毁的组件继续“在线”
setInterval 的回调函数会形成一个闭包，自动记住它定义时所在作用域里的所有变量。比如在 React 函数组件里写：
useEffect(() => {const timer = setInterval(() => {
setCount(c => c + 1); // 访问了 setCount
console.log(data); // 访问了外部 data 变量
}, 1000);
}, []);
这个回调不仅绑定了 setCount，还可能隐式持有整个组件闭包中的 data、props、甚至 ref.current。组件卸载后，这些值本该被释放，但定时器还在——闭包链没断，GC 就认定“它们还有用”，只能留着。
定时器 ID 不是“开关”，而是“绳索”
setInterval 返回的只是一个数字 ID，它本身不占多少内存；真正卡住内存的是这个 ID 对应的定时器任务在事件队列里的持续存在。只要没调用 clearInterval(id)，V8 就必须维持该任务的执行上下文，包括它的函数体、作用域链、以及所有被闭包捕获的变量引用。
- 组件实例（如 class 组件的 this）被回调引用 → 实例无法回收
- DOM 节点被 ref.current 持有，又被回调读取 → 节点变成 detached 但不释放
- 大型数组或状态快照被闭包捕获 → 占用内存只增不减
组件卸载 ≠ 定时器停摆
框架（React/Vue）卸载组件时，只会清理虚拟 DOM 和响应式依赖，不会自动清除你手动创建的 setInterval。这意味着：
- 定时器继续每秒触发，回调照常执行
- 回调里调用 setState 或操作已移除的 DOM → 控制台报错：“Can't perform a React state update on an unmounted component”
- 错误不中断定时器，反而让问题持续发生，内存缓慢堆积
更隐蔽的叠加效应
如果用户频繁进出同一页面（比如路由复用、v-if 切换），每次挂载都新建 setInterval 却不清旧的，就会出现多个定时器并行运行：
- 第 1 次进入：timerId = 1
- 第 2 次进入（未清旧）：timerId = 2，但 1 还在跑
- 第 5 次后，5 个定时器同时每秒执行 → 内存和 CPU 压力翻倍
这些定时器各自持有不同版本的闭包，可能拽住多套组件实例和状态副本，泄漏呈指数级增长。
