chrome devtools 的 heap snapshot 功能可通过对比两次快照的 delta 值并分析 retainers 路径，精准定位因闭包、事件监听器等导致未释放的构造函数实例，从而识别内存泄漏。
JavaScript 中没有直接叫“快照对比法”的内置机制，但你提到的其实是开发者常用的一种内存分析策略：通过 Chrome DevTools 的 Heap Snapshot（堆快照）功能，配合构造函数名筛选与对比，来识别疑似内存泄漏的、未被释放的实例对象——尤其是那些本该被回收却持续存在的构造函数实例。
一、什么是“未释放的构造函数”
这里说的不是构造函数本身（函数是常驻的），而是指由该构造函数创建的对象实例，在逻辑上已完成使命、应被垃圾回收，却因意外持有引用（如闭包、事件监听器、全局缓存、定时器回调等）而长期滞留在内存中。这类对象会拖慢性能，甚至导致 OOM。
二、用堆快照定位可疑构造函数实例
步骤清晰、可复现：
- 在稳定状态下拍第一张快照（Snapshot 1）：打开 DevTools → Memory 面板 → 选择 “Heap snapshot” → 点击 “Take snapshot”。确保此时页面处于空闲、无交互、无轮询的状态。
- 执行目标操作（触发疑似泄漏行为）：比如打开一个模态框、加载一个组件、订阅一个事件，再关闭/销毁它——但怀疑销毁不彻底。
- 强制 GC 后拍第二张快照（Snapshot 2）：点击右上角垃圾桶图标（Collect garbage），稍等片刻再拍快照。这能排除临时对象干扰，聚焦真正残留的。
- 切换到 “Comparison” 视图，选中 Snapshot 2 并对比 Snapshot 1：左侧会显示新增（# New）、删除（# Deleted）和净增（# Delta）的对象数量。重点关注 Delta > 0 且 Constructor 名称是你关心的类（如 MyComponent、DataProcessor）。
三、精准识别“不该存在”的实例
光看数量不够，需进一步验证是否真为泄漏：
- 点开构造函数行，查看右侧 “Retainers”（持有者）：这是关键！它展示哪些对象/变量仍在引用这些实例。常见泄漏源头包括：window.xxx、setTimeout 回调闭包、EventTarget.addEventListener 绑定的 handler、Map/Set 缓存未清理。
- 检查 “Object’s retaining path”（保留路径）：从泄漏实例向上追溯引用链，直到全局对象或根对象。路径中若出现意料之外的变量名或长闭包链，基本就是泄漏点。
-
结合代码逻辑交叉验证：比如你调用了
component.destroy()，但在 Retainers 中仍看到component._eventHandler被某个 document 事件监听器持有着——说明 removeEventListener 没执行或执行错了。
四、辅助技巧提升效率
让快照更有针对性：
-
给构造函数加唯一标识：开发期在类中添加
this.$$debugId = Math.random().toString(36).slice(2, 8)，快照中搜索该字段值，可快速定位特定实例。 - 使用 “Allocation instrumentation on timeline”：开启后录制操作过程，能直观看到某类对象在何时大量分配且未回收，比静态快照更动态。
- 避免快照干扰项：禁用扩展、关闭无关标签页；减少 console.log（尤其打印大型对象，会阻止其回收）；确保测试路径纯净（不混杂其他用户行为）。
不复杂但容易忽略：快照本身不会告诉你“为什么没释放”，它只呈现事实。真正锁定问题，靠的是把 Retainers 路径和你的销毁逻辑逐行对齐——那里藏着最真实的答案。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
