检测 javascript 定时器泄漏的核心方法是使用浏览器开发者工具的 performance 面板录制运行过程，并重点观察 heap（堆）快照中是否存在随时间推移持续增长的 timer 对象实例。具体做法是在录制期间执行包含定时器的业务逻辑，停止录制后在左侧的 summary 视图中筛选 timer 类型，若发现实例数量未归零或内存占用持续上升，即可判定存在泄漏。
Performance 面板中如何定位定时器实例
在 Chrome DevTools 的 Performance 标签页中，通过点击录制按钮开始捕捉应用运行状态，执行触发定时器的操作后停止录制。随后在左侧的事件列表下方切换到 "Summary" 视图，在 "Objects" 区域找到 "Timers" 分类，展开该分类可以看到具体的定时器实例及其引用路径。如果这些实例在预期应该被清除的时间点后依然存在于列表中，且其父级引用链指向了全局作用域或未被销毁的 DOM 节点，则说明定时器发生了泄漏。
const timerId = setInterval(() => {
console.log('Running');
}, 1000);
// 模拟业务逻辑结束，但未调用 clearInterval(timerId)
// 此时定时器仍在后台运行，导致内存泄漏
上述代码展示了一个典型的泄漏场景：`setInterval` 创建了一个定时器实例，但由于缺少对应的 `clearInterval` 调用，该实例会一直驻留在内存中。在 Performance 面板中，你可以看到这个定时器实例的 `interval` 属性值以及它关联的回调函数引用。通过检查这些实例的生命周期，可以明确判断是否需要在组件卸载或任务结束时手动清理资源。
立即学习“Java免费学习笔记（深入）”；
Heap Snapshot 中如何验证定时器残留
除了实时性能监控，使用 Heap Snapshot（堆快照）可以更静态地验证定时器是否被正确回收。在 Memory 标签页中选择 "Take Heap Snapshot"，生成快照后在 "Search" 框中输入 "Timer" 或 "Interval"，查看搜索结果中的对象数量。对比两次快照（一次在定时器启动前，一次在预期停止后），如果第二次快照中 Timer 对象的数量没有减少，或者存在从 Global 对象到 Timer 对象的强引用链，则证实了泄漏的存在。
function startLeakingTimer() {
window.myGlobalTimer = setInterval(() => {
// 泄漏源：定时器被挂载到全局对象 window 上
// 即使内部逻辑不再需要，只要不清除，它就会一直存在
}, 5000);
}
startLeakingTimer();
// 假设这里有一个清理函数，但忘记调用
// function cleanup() { clearInterval(window.myGlobalTimer); }
在这个示例中，定时器被显式地赋值给 `window.myGlobalTimer`，这建立了一条从全局对象到定时器实例的直接引用。在 Heap Snapshot 中，你可以清晰地看到这条引用链：`Global -> myGlobalTimer -> Interval Object`。这种显式的全局引用是定时器泄漏的常见原因之一，通过定期清理全局变量或在组件生命周期钩子中调用清除方法，可以有效避免此类问题。
定时器回调中闭包导致的内存保留
定时器泄漏不仅源于未清除定时器本身，还常因回调函数中的闭包引用了大型对象而导致内存无法释放。当定时器回调函数定义在一个作用域内，并引用了该作用域中的局部变量时，即使定时器被清除，如果回调函数本身仍被其他对象引用，那么它所捕获的整个作用域链也将保留在内存中。排查时需关注回调函数内部的变量使用情况，确保在不需要时断开对这些变量的引用。
