chrome devtools 的 memory 和 performance 面板可精准定位定时器内存泄漏：performance 面板通过 timer fired 事件和火焰图识别未清除的活跃定时器；memory 面板对比堆快照，筛选 interval、detached dom 和持续增长的构造函数，确认残留引用；sources 面板启用 timers 断点快速溯源闭包捕获对象；console 命令辅助排查活跃定时器。

直接用 Chrome DevTools 的 Memory 和 Performance 面板就能定位，不用猜、不靠日志。关键是看“定时器是否还在跑”和“它拽着哪些对象不放”。

Performance 面板抓活跃定时器触发

打开 DevTools → Performance 面板 → 勾选 Memory 和 Timers（可在录制设置里展开更多选项）→ 点击录制 → 做一段操作（比如进入页面、打开弹窗、再关闭）→ 停止录制。

回放时重点关注：

• 时间轴下方的 Timer Fired 事件条：如果在页面已离开或组件已卸载后，仍有密集、规律出现的 Timer Fired，说明定时器没停
• 点开某个 Timer Fired 事件 → 查看 Call Stack → 能直接看到是哪行代码调用了 setInterval 或 setTimeout
• 配合 Main 线程火焰图，看回调函数是否引发长任务（>50ms），这往往是泄漏叠加性能卡顿的信号

Memory 面板拍快照查残留引用

这是确认内存泄漏最可靠的一步：打开 Memory 面板 → 点击 Take heap snapshot → 操作（如打开又关闭一个模块）→ 再拍一张 → 对比两次快照。

在第二张快照中筛选：

Wjs Uploading Video

将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。

下载

• 搜索 Interval 或 setInterval：如果结果里 JSFunction / Closure 数量明显多于第一张，且持有大量闭包变量，就是未清理的定时器在作祟
• 筛选 Detached DOM tree：若这些脱离 DOM 的节点被某个 Interval 回调引用着，说明定时器正锁住整片 DOM 内存
• 按 Constructor 排序，关注持续增长的类名（如 VueComponent、ReactRoot、ChartInstance），再往上追溯到它们被哪个 Closure 持有

Sources 面板设断点快速溯源

想立刻知道某个定时器从哪来？打开 Sources 面板 → 左侧边栏点 Event Listener Breakpoints → 展开 Timers → 勾选 setTimeout 和 setInterval。

刷新页面或触发相关逻辑，执行流会在定时器注册那一刻自动中断。此时：

• 看右侧 Scope 面板，能直观看到闭包捕获了哪些变量（尤其是 this、vm、data、refs 等大对象）
• 看 Call Stack，逐层点进去，就能定位到原始调用位置（比如某个 useEffect 或 mounted 钩子）
• 配合右键某帧 → Reveal in Overview，可跳转到 Performance 时间轴对应时刻，交叉验证

命令行辅助排查（适合高频怀疑场景）

在 Console 中输入以下命令，能快速列出当前所有活跃定时器及其回调源码位置：

getEventListeners(window).setTimeout || []
getEventListeners(window).setInterval || []

注意：这个 API 并不直接返回定时器 ID 列表，但结合 Performance 录制 + 断点，可以快速锁定可疑 ID。更实用的是：

• 手动运行 debugger; setInterval(() => {}, 1000);，然后立即在 Timers 断点处暂停，观察上下文
• 在关键生命周期钩子（如 React 的 cleanup 函数）里加 console.log('clearing timer:', id)，确认清除逻辑是否真被执行