排查闭包内存泄漏的关键是拍得准、比得清、追得深：先手动gc并拍基线快照，再执行操作—清理—释放闭环后gc并拍对比快照，在comparison视图中按#delta降序查(closure)项的retained size及retainers，顺藤摸瓜分析[[scopes]]和dominators。

排查闭包内存泄漏，关键不是拍快照，而是拍得准、比得清、追得深。Chrome DevTools 的 Memory 面板本身不自动标记“泄漏”，它只如实呈现对象的引用关系和内存占用。真正起作用的是你如何操作、对比和解读。

先手动 GC，再拍基线快照

很多问题源于快照里混入了本该被回收但还没来得及清理的对象。必须主动干预：

• 打开隐身窗口，禁用所有扩展，确保环境干净
• 进入 Memory 面板 → 点击左上角垃圾桶图标（Collect garbage），强制触发一次垃圾回收
• 等页面完全空闲（无定时器运行、无网络请求、无动画）→ 点击 Take heap snapshot 拍下第一张，作为 Baseline

操作闭环后，再 GC 并拍对比快照

不能只执行动作，必须完成“使用—清理—释放”全过程：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 执行典型操作：比如打开弹窗 → 点击关闭按钮 → 等待组件卸载完成（React 中 useEffect 清理函数已执行，Vue 中 onBeforeUnmount 已调用）
• 再次点击垃圾桶图标触发 GC（尤其重要：这一步能滤掉临时浮动对象）
• 立即拍第二张快照

进 Comparison 视图，盯住 Closure 和 Retained Size

别在 Summary 里瞎翻，直接切到 Comparison 视图，选中两张快照做对比：

• 按 # Delta 降序排列，优先看正增长且数量明显变多的项，特别是 Constructor 列显示为 (closure)
• 重点不是 Closure 对象自身大小（Shallow Size 往往只有几十字节），而是它的 Retained Size —— 如果一个闭包 Retained Size 达几百 KB 或 MB，说明它背后拽着大量不该存在的对象
• 点开可疑闭包 → 右侧看 Retainers 树：从下往上找，谁是最后一层还活着的持有者？常见“钉子”包括：
  – window.timerId 指向未 clearTimeout 的定时器
  – document.addEventListener 绑定的未 remove 的监听器
  – 全局缓存 Map 或 EventBus 实例
  – 已卸载组件仍被第三方库回调闭包引用

顺藤摸瓜查 [[Scopes]] 和支配关系

闭包泄漏的本质是作用域变量被意外延长生命周期：

• 点开闭包对象 → 展开 Properties → 找到 [[Scopes]] → 进入 Closure scope → 查看哪些变量被实际捕获（如 data、config、ref）
• 若发现捕获了大型数组、完整响应体或 DOM 节点，就说明闭包设计过重
• 切换到 Dominators 视图，按 Retained Size 排序，跳过 window/document 等宿主，聚焦排在前列的 (closure) 或你项目中的类名（如 ChartView、ApiCache）——它支配的对象树就是泄漏影响范围

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南