排查闭包内存泄漏的关键是拍得准、比得清、追得深：先手动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 视图，选中两张快照做对比：
立即学习“Java免费学习笔记（深入）”；
- 按 # 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）——它支配的对象树就是泄漏影响范围
