dom节点删除后仍被js持有是内存泄漏最常见场景，需用chrome devtools拍对比堆快照，筛选detached节点并查看retainers引用链，重点排查未解绑事件监听器、全局/缓存变量、定时器回调和闭包捕获的dom引用。
DOM节点删除后仍被JS持有，是内存泄漏最常见也最容易验证的场景。关键不是看“有没有删”，而是看“删了之后还被谁拽着”。Chrome DevTools 的堆快照（Heap Snapshot）能直接告诉你答案。
用堆快照定位 Detached DOM 节点
Detached DOM tree 是泄漏的明确信号——它表示节点已脱离文档，却仍在内存中挂着。
- 打开 Chrome DevTools → Memory 面板 → 点击 “Take heap snapshot” 拍下基线快照（比如页面刚加载完）
- 执行操作：动态创建一个元素、绑定事件、再调用
remove()或innerHTML = ''将其移除 - 点击垃圾桶图标强制触发垃圾回收（GC），再拍第二张快照
- 在第二张快照顶部搜索框输入
detached，筛选出DetachedHTMLElement类型 - 双击任一结果，在右侧 “Retainers” 栏里展开引用链，就能看到哪个变量、闭包或监听器还在强引用它
重点查这四类 JS 持有源
Detached 节点本身不占多少内存，但它背后拖着的 JS 对象图才是真问题。重点关注：
-
未解绑的事件监听器：给节点绑了
addEventListener('click', handler)，但销毁时没调removeEventListener；尤其注意匿名函数、this.bind()或带{ once: true }选项的情况，解绑参数必须完全一致 -
全局或缓存变量：比如
window.nodeRef = document.getElementById('xxx')，或用普通对象做映射缓存cache[id] = node，节点删了但缓存没清，node 和关联数据全卡住 -
定时器回调里的引用：如
setInterval(() => console.log(node.textContent), 1000)，组件卸载后定时器还在跑，node 就永远无法释放 - 闭包捕获的 DOM 引用：函数内部保存了节点引用并返回了闭包，而这个闭包又被长期持有（比如挂到全局或传给第三方库）
靠快照差分确认是否真泄漏
单看一张快照容易误判。必须做对比：
- 执行一次完整流程：打开模块 → 渲染含 DOM 的列表 → 关闭模块
- 等几秒，手动 GC，拍快照 A
- 重复上述流程 2–3 次，再拍快照 B
- 切换到快照 B → 右上角选 “Comparison” → 与快照 A 对比 → 按 Constructor 排序
- 观察
HTMLDivElement、HTMLLIElement等数量是否持续增加，且 Delta 列为正数、Retained Size 不降
日常预防比事后排查更有效
与其等内存涨了再追，不如从编码习惯入手：
- 避免在每个子节点上单独绑定事件，改用事件委托：监听父容器，用
event.target判断来源，删子节点时无需额外清理 - 为可销毁的模块/组件提供明确的
destroy()方法，在 DOM 移除前主动解绑、清缓存、关定时器 - 用
WeakMap存储 DOM 关联数据，节点被 GC 后，对应条目自动失效，不用手动清理 - 开发阶段开启 DevTools 的 “Memory” → “Allocation instrumentation on timeline”，录制交互过程，蓝色长条代表长期存活对象，一眼就能发现异常
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
