Chrome DevTools 堆快照无法实时观察GC过程，但可通过对比多张快照识别本该被回收却因意外引用而滞留的对象；重点分析Constructor数量增长、retaining path及Detached DOM tree等泄漏信号。
直接用 Chrome DevTools 的内存快照（Heap Snapshot）无法实时观察垃圾回收（GC）的触发时机或过程，但它能帮你识别哪些对象本该被回收却仍被意外持有——也就是内存泄漏的典型迹象。关键不是“看 GC 发生了没”，而是“为什么这些对象没被回收”。
录制并对比多个堆快照定位泄漏对象
这是最常用、最有效的做法：
- 打开 DevTools → Memory 面板 → 选择 Heap snapshot → 点击 Capture snapshot
- 执行一段可能引发泄漏的操作（比如反复打开关闭模态框、切换路由、添加监听器但未移除）
- 再拍一张快照，重复几次（建议至少 3 轮），确保操作可复现
- 在快照列表中选中后一张，顶部下拉选 Comparison，对比前一张（如 “Snapshot 3” 对比 “Snapshot 2”）
- 重点关注 Constructor 列中数量持续增长、且 # Delta 为正的对象（如
Array、Closure、自定义类名、EventListener）
重点查看 retaining path（保留路径）判断引用链
发现可疑对象后，双击它进入详细视图，右侧会显示它的 Retainers（谁在引用它）和完整的 Retaining path：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 路径以
Window或Document开头是正常的；若以Global→closure→ 某个变量名 →Array→ 你的对象结尾，说明闭包持有了不该持有的引用 - 常见陷阱：事件监听器未用
removeEventListener清理、定时器未clearInterval、React 组件卸载后仍调用setState（导致闭包保留组件实例）、全局缓存对象不断push但不清理 - 路径中出现
Detached DOM tree是强信号：DOM 节点已从文档移除，但 JS 仍通过变量、闭包、事件监听器等持有它
配合 Allocation instrumentation on timeline 辅助验证
堆快照是静态切片，而这个功能能动态看对象生命周期：
立即学习“Java免费学习笔记（深入）”；
- 在 Memory 面板切换到 Allocation instrumentation on timeline
- 勾选 Record heap allocations，点击录制，执行操作，停止
- 时间轴上黄色/蓝色小方块代表新分配的对象，灰色表示已被 GC 回收；持续亮着的蓝色块说明没被回收
- 点击某个蓝色块，下方会显示它的构造函数和分配时的调用栈，快速定位创建位置
- 适合验证“某次操作是否真的产生了长期存活对象”，比快照更及时
注意快照本身的局限性
别误以为快照 = GC 日志：
- 快照拍摄前，DevTools 会自动触发一次 GC，所以看到的都是“幸存对象”，不是 GC 过程本身
- 无法得知 V8 何时、为何触发 GC（Minor/Major GC），这属于引擎内部行为，需用
--trace-gc启动 Chrome 才能看到（仅调试用，不推荐日常） - 对象被标记为
(array)或(compiled code)时，需结合上下文判断是否合理；大量(closure)往往意味着作用域链过长或变量捕获不当 - 移动端或 iframe 场景下，快照可能不包含全部上下文，建议在主窗口、无跨域 iframe 的环境下分析
