定时器未清除是前端内存泄漏最常见原因，会导致回调及闭包持续引用组件、DOM或大数据，阻碍垃圾回收；需通过内存曲线分析、堆快照定位、代码生命周期审查及代理监控四步排查。
定时器忘记清除是前端内存泄漏最常见原因之一。它会让回调函数及其闭包持续持有对组件实例、DOM 节点或大型数据的引用，导致这些对象无法被垃圾回收。排查关键在于确认定时器是否真正停止、是否残留引用、以及是否在正确时机清理。
看内存曲线是否异常增长
打开 Chrome DevTools → Memory 面板 → 点击录制（●）→ 反复进入/退出同一页面或组件（比如 5 次）→ 停止录制。观察 JS Heap 曲线：
- 如果每次操作后内存都明显上升，且停止操作后不回落，大概率存在泄漏
- 特别注意：切换路由后内存没下降，但页面已不可见，说明旧组件仍被定时器强引用
用堆快照定位活跃定时器
在疑似泄漏状态（如多次切换后）执行 Heap Snapshot：
- 在快照中搜索关键词：Interval、Timeout、setInterval、setTimeout
- 点击匹配项，查看右侧 “Retaining Path”（保留路径）——若指向已卸载的 Vue 组件、React Fiber 节点或 detached DOM，就是泄漏源头
- 重点关注 Closure 类型对象，检查它是否捕获了 this、$refs、大型数组或 API 响应数据
检查代码中定时器生命周期是否完整
逐个审查所有 setInterval / setTimeout 使用点，确认三点：
- timer ID 是否被可靠保存（避免重复赋值覆盖旧 ID）
- 清除逻辑是否绑定在组件卸载钩子中（Vue 的 onUnmounted / beforeUnmount，React 的 useEffect 清理函数）
- 清除调用是否无条件执行（不要写成 if (isRunning) clearInterval(timer)，否则 isRunning 可能提前 false 却跳过清理）
加一层可追踪的定时器代理
临时在项目入口或开发环境注入包装逻辑，实时监控未清理数量：
- 重写 window.setInterval，用 Set 记录所有活跃 ID
- 重写 window.clearInterval，同步从 Set 中删除
- 在控制台输入 timers.size，切换页面前后对比数值变化
- 配合组件生命周期打印日志（如 “UserList mounted, timer created” / “UserList unmounted, timer cleared”），快速定位漏清理模块
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
