定位内存泄漏需先确认JS heap不回落，再通过堆快照对比锁定未清除的定时器及其捕获的外部引用，最后在组件卸载钩子中配对清理。
定位未清理定时器引发的内存泄漏，关键不是找“定时器本身”，而是找到“谁在持续持有不该存在的引用”。定时器只是导火索，真正泄漏的是它回调函数所捕获的外部变量（比如组件实例、DOM 节点、大型数组等）。
用 Chrome Memory 面板确认泄漏模式
打开 DevTools → Memory 面板 → 点击 Record allocation timeline：
- 执行一次目标操作（如进入某个页面或模块）
- 等待几秒，再执行退出操作（如路由跳转、组件卸载）
- 停止录制，观察时间线中 JS heap 曲线是否回落
- 若 heap 持续抬高，尤其在操作结束后仍缓慢上升，说明有对象未被回收——这时要怀疑长期存活的定时器
通过堆快照对比锁定可疑 setInterval/setTimeout
拍两张堆快照做对比：
- 操作前拍一张（Baseline）
- 进入模块 → 启动定时器 → 执行若干轮次 → 完全离开模块（确保组件已卸载）→ 再拍一张
- 切换到 Comparison 视图，筛选 Closure 或 System / Timeout / Interval 类型
- 关注 Delta 列为正、且 Retained Size 较大 的条目
- 点开一个 Closure 实例，在右侧 Retainers 中查看引用链：如果发现它被 Timer 或 setInterval 直接持有，且该 Timer 没有被清除，基本可确认
检查代码中定时器的生命周期管理
重点排查以下写法：
立即学习“Java免费学习笔记（深入）”；
- 在 React useEffect、Vue onUnmounted 等钩子里启动了 setInterval，但返回的清理函数没调用 clearInterval
- 定时器 ID 被定义在闭包外（如全局变量或模块级 const），但清理逻辑缺失或条件不触发
- 回调里访问了 this、props、state、ref.current 或大型缓存对象，而这些值本应在组件卸载后释放
- 使用了 setTimeout 模拟 setInterval（递归调用），却只 clear 了一次，后续调用仍持续
快速验证与修复建议
临时加一行日志辅助判断：
- 在定时器回调开头加 console.log('tick', Date.now())，然后手动离开页面——如果日志还在打印，说明定时器真没被清掉
- 修复时统一用 useEffect 返回清理函数（React）或 onBeforeUnmount（Vue），确保每次 mount 都配对 clear
- 避免在回调中直接读取大型数据；改用 useCallback 缓存回调，并依赖数组明确声明哪些值会触发重创建
- 对纯轮询场景，考虑用 AbortController + fetch + signal 轮询替代 setInterval，便于统一中断
