定时器未清理是前端内存泄漏最常见原因，需通过内存曲线监测、Heap snapshot分析、回调日志验证及代理监控等方式排查并定位泄漏源。
定时器未清理是前端内存泄漏最常见也最容易被忽视的原因之一。它不会立刻报错，但会悄悄拖慢页面、抬高内存水位，直到用户明显感到卡顿甚至崩溃。排查的关键不在于“找代码”，而在于“验证行为”——看定时器是否真的随组件销毁而终止。
看内存曲线是否持续上涨
打开 Chrome 浏览器的 任务管理器（Shift + Esc），找到你的页面标签，观察“内存”列数值：
- 静置页面 20 秒，内存应基本稳定或小幅波动；若每 10 秒上涨 5–10MB 且不停止，高度可疑
- 反复进入退出同一页面（比如点击菜单再返回）5 次以上，每次操作后内存都比前一次高，说明组件实例没释放，背后大概率有残留定时器
用 DevTools 快照定位残留定时器
在 Chrome DevTools 的 Memory 面板中：
- 点击 “Heap snapshot”，记录组件加载后的快照
- 执行路由跳转或关闭弹窗等销毁操作
- 再点一次 “Heap snapshot”，切换到新快照，在左上角搜索框输入 Timeout 或 Interval
- 展开匹配项，查看 retaining path —— 如果路径里出现已卸载的 Vue 组件、React Hook 组件名，或指向某个 this.xxx.timer 的闭包，就是泄漏源
直接检查定时器是否还在运行
组件销毁后，它的定时器回调本不该再执行。你可以快速验证：
- 在定时器回调里加一句
console.log('timer running') - 进入组件 → 看控制台输出 → 退出组件 → 若日志仍在打印，说明 clearInterval / clearTimeout 没生效
- 更进一步：在控制台手动执行
window.performance.memory，多次进出后堆内存值持续增长，且能通过console.dir(window)找到未清除的 timer ID，基本坐实泄漏
用代理方式实时监控定时器数量
在项目入口或开发环境全局注入一层轻量包装：
- 重写
setTimeout和setInterval，把所有生成的 ID 存进一个 Set - 同时重写
clearTimeout和clearInterval，从 Set 中删除对应 ID - 之后在控制台随时输入
timers.size，就能看到当前有多少个未清理的定时器 - 配合组件生命周期打日志（如 Vue 的 onUnmounted、React 的 useEffect cleanup），很容易对上哪段逻辑漏了清理
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
