定时器泄漏是js中最隐蔽的内存泄漏类型，源于未清除的setinterval/settimeout回调长期持有作用域链中的this、props、dom节点或大数组，导致其无法被gc回收。
定时器泄漏是 JS 项目中最隐蔽也最常被忽略的内存泄漏类型之一。它不靠 DOM 节点堆积，也不靠闭包显眼捕获，而是靠一个没被清除的 setInterval 或 setTimeout 回调，悄悄锁住整个作用域链——哪怕组件早已卸载、页面早已切换，回调仍在运行，里面引用的 this、props、DOM 节点、大数组 全部无法回收。
一眼识别定时器是否在“偷偷吃内存”
不用打开堆快照，先做两件事：
- 按 Shift + Esc 打开浏览器任务管理器，盯住目标标签页的“内存”列：静置 10 秒后内存应基本持平；反复触发同一功能（如点击“刷新数据”按钮）5 次，每次操作后内存若稳定上升 15MB 以上，且不回落，高度可疑
- 打开 Performance 面板 → 点录制 → 勾选 Memory → 录制 20 秒含定时器操作的过程；停止后看 JS Heap 曲线：若呈阶梯式爬升，且每次垃圾回收（GC）后回落幅度极小（比如只降 1–2MB），说明有对象持续存活，定时器很可能是源头
快速定位泄漏定时器的三类线索
定时器本身不会占多少内存，但它持有的上下文才是真凶。重点查：
-
全局或长期存活对象里存着未清除的 timer id：比如
window.myTimerId = setInterval(...)，或某个单例类的实例属性this.pollTimer，但销毁时没调用clearInterval(this.pollTimer) -
回调函数里直接访问了外部大对象：例如
setInterval(() => { renderChart(data); }, 3000)，其中data是上万条记录的数组，而renderChart又引用了 DOM 节点 —— 这个闭包一旦被定时器持有，整套数据+节点就锁死了 -
第三方库封装的定时器未暴露清除方法：比如旧版
lodash.throttle或某些轮播图组件，返回的防抖/节流函数内部持有了定时器，但你调用componentWillUnmount时只清了事件，忘了清这个函数本身
用 DevTools 直接揪出泄漏源头
确认有泄漏后，进 Memory 面板拍三张快照：
- 刷新页面 → 拍第一张（基线）
- 执行一次定时器启动操作（如进入某监控页）→ 等 10 秒 → 拍第二张
- 再等 10 秒（让定时器至少跑两轮）→ 拍第三张
- 选中第二、三张 → 切到 Comparison 视图 → 筛选 Closure 和 System / Timeout 类型 → 看 “# New” 是否持续增长
- 点开异常增长的 Closure → 右键 → Retaining tree → 顺着路径往上找，顶部带
@符号的对象（通常是window、Timeout或某个 class 实例）就是泄漏定时器所在位置
修复要到位，不止是 clear
光调 clearInterval(id) 不够，还得确保：
- 清除动作发生在组件卸载、路由离开、模块销毁的准确时机（React 用
useEffect cleanup，Vue 用beforeUnmount） - 定时器回调里避免直接捕获大型数据或 DOM 节点；可改用参数传入或通过状态更新间接触发
- 如果必须缓存数据，优先用
WeakMap关联定时器与数据，而不是用普通对象或 Map 持有强引用 - 用
performance.memory.usedJSHeapSize在清理后手动验证：执行clearInterval+ 手动 GC（点小垃圾箱图标）后，内存应明显回落，否则仍有隐性引用未断
