根本原因是闭包长期持有外部大对象且定时器未清除，导致对象始终可达无法回收；需保存定时器id并在销毁前清除，避免闭包捕获冗余引用。
定时器函数闭包引发的内存增长，根本原因不是“用了setInterval”，而是闭包长期持有外部大对象，且定时器未被清除，导致这些对象始终可达、无法被垃圾回收。
为什么定时器里的闭包容易卡住内存
JavaScript 垃圾回收基于“可达性”：只要某个对象能从根（如 window、活动调用栈、全局闭包环境）被引用到，它就不会被释放。定时器回调一旦启动，就成为长期存活的闭包——只要没被 clear，它和它捕获的所有变量（this、DOM 节点、大型数组、组件实例等）就一直挂在内存里。
- 闭包捕获了整个组件实例（比如 Vue 的 this 或 React 的 props/state），而组件已卸载，但定时器还在跑
- 回调中直接访问 document.querySelector('#report') 或 this.tableData，哪怕 DOM 元素已被移除或数据已废弃
- 使用 var 声明循环变量，多个定时器共享同一个变量引用，造成意外强持有
- 定时器 ID 没保存，或者保存在局部作用域里，销毁时根本找不到它来清除
如何快速定位是不是定时器闭包在吃内存
打开 Chrome DevTools → Memory 面板：
- 点击 “Take heap snapshot” 拍第一张快照（空闲状态）
- 执行一次触发定时器的操作（如打开某模块、开始轮询）
- 等待几秒，再拍第二张快照；重复操作 2–3 次后拍第三张
- 切换到 Comparison 视图，筛选 Constructor 列为 Closure，重点关注 Retained Size 明显增长的项
- 点开可疑闭包 → 查看右侧 Retainers 树 → 如果看到 setInterval、setTimeout 或 Timer 直接出现在链顶端，基本就是它
实用修复方式：让定时器“有始有终”
不追求禁用定时器，而是确保它的生命周期可控、引用精简：
- 启动定时器时，一定把返回的 ID 保存在可访问位置（如 class 实例字段、React ref、Vue data）
- 在组件卸载、页面离开、模块关闭前，明确调用 clearInterval(id) 或 clearTimeout(id)
- 避免在回调里直接读取 this.xxx 或 document.getElementById —— 提前提取必要字段（如 el.id、data.length），让闭包只持轻量值
- 用 AbortController 统一管理：创建 signal，绑定到定时器清理逻辑，一处 abort 即可终止所有关联定时器
- 轮询类场景优先考虑 requestIdleCallback + 显式开关控制，比 setInterval 更易中断
预防建议：写法上减少隐患
很多泄漏其实在写定时器那一刻就埋下了：
- 不用匿名函数写 setInterval：() => {...} 无法被精准清除，改用命名函数或保留引用
- 避免在闭包内持续访问响应式数据源（如 Vue 的 computed、React 的 useMemo 结果），它们可能隐式携带大量依赖
- 如果必须缓存数据，用 WeakMap（以 DOM 节点为 key）或带 TTL 的 Map，而不是让定时器闭包自己 hold 一份副本
- 在 useEffect / onUnmounted / componentWillUnmount 中检查是否有遗漏的 clearInterval —— 尤其注意条件分支、异常路径、异步延迟注册等情况
