DOM内存泄漏本质是JS强引用阻止GC回收，需通过Heap Snapshot查detached节点及Retainers定位闭包、缓存、事件监听器或框架ref等异常引用链，并验证修复后detached节点不再累积。
动态创建的 DOM 元素未移除，本质不是“没调 remove()”，而是 JS 仍持有对它的强引用，导致 GC 无法回收。排查关键在于确认：元素是否已脱离文档树（detached），同时又被哪些 JS 对象持续引用。
确认元素是否真的 detached
打开 Chrome DevTools → Memory 面板 → 拍摄 Heap Snapshot。在快照中用 Class filter 搜索：
• Detached：直接筛选所有已从 DOM 树移除但仍有 JS 引用的节点
• 或具体类型，如 HTMLDivElement、HTMLButtonElement，再结合右侧 “retained size” 判断是否异常偏大
• 点击某 detached 节点，看其 Distance 值：越小说明离根对象（window/document）越近，越可能是泄漏源头
查 Retainers 定位强引用来源
展开该节点的 Retainers 面板，重点识别以下几类引用链：
-
闭包引用：看到类似
closure → renderChart → el，说明某个函数作用域里缓存了这个元素，且该函数实例长期存活（如事件处理器、定时器回调） -
模块/单例级变量：如
myUtils.cacheMap → "key" → el或AppStore.dialogs → [0] → el，检查对应缓存或状态管理逻辑是否在元素销毁后忘记 delete 或置 null -
事件监听器残留：出现
EventListener → handler → el，尤其当 handler 绑定在 document 或长期存在的父容器上，而 handler 内部又捕获了 el -
框架 ref 或实例属性：Vue 中
$refs.xxx、React 中ref.current、第三方图表库的chart.element等，需确认组件卸载时是否清空了这些引用
验证与修复是否生效
改完代码后不能只看一次快照，要走完整闭环：
- 执行操作（如打开弹窗 → 关闭弹窗）
- 手动触发垃圾回收（点击 Memory 面板的垃圾箱图标）
- 再拍一张快照，对比前一张中同类 detached 节点数量和 retained size 是否归零或稳定不增长
- 重复 2–3 轮，观察趋势——真正修复后，detached 节点应不再累积
核心逻辑始终是：GC 不回收，是因为它还能被根对象访问到。找到那个“不该存在却一直存在”的引用路径，就找到了泄漏点。
立即学习“Java免费学习笔记（深入）”；
