核心是通过对比操作前后内存快照，定位未卸载的 Detached DOM 节点及其保留路径；重点分析 Retainers 中的全局变量、未清除事件监听器、定时器及第三方库缓存，并经强制 GC 验证后，在卸载逻辑中彻底清理引用。
用 Chrome 内存快照排查 DOM 树未正确卸载，核心是捕获“本该被回收却仍被引用”的 DOM 节点。关键不在快照本身，而在对比和引用链分析。
录制前后快照并做对比
在疑似内存泄漏的操作前（如进入页面、打开弹窗），点击 Chrome DevTools 的 Memory 面板 → 选择 Heap snapshot → 点击 Capture heap snapshot 记录 baseline。执行操作（如关闭弹窗、跳转路由）后，再拍一次。点击第二个快照顶部的 Comparison 视图，筛选 Objects allocated between snapshots，重点关注 Detached DOM tree 和 HTMLDivElement、HTMLSpanElement 等真实元素类型。
定位 Detached DOM 树的保留路径
在快照中搜索 detached，或直接展开 Detached DOM tree 分类。点击任一节点，在右侧 Retainers 面板中查看它为何没被释放。常见保留者包括：
- 全局变量或模块级变量意外持有 DOM 引用（例如
let cachedNode = document.getElementById('xxx')未清空） - 事件监听器未移除，且监听器闭包中捕获了 DOM 元素（尤其使用箭头函数或未绑定 this 的 handler）
- 定时器（
setInterval）回调中持续引用 DOM，而定时器未清除 - 第三方库缓存（如某些 UI 组件库内部保留对已卸载节点的引用）
验证是否真泄漏：强制 GC 后重拍
拍完第二个快照后，先点击 DevTools 左上角的垃圾回收图标（?️）触发一次 GC，再立即拍第三个快照。如果 Detached 节点数量没有明显下降，基本确认存在泄漏。此时回到第二个快照的 Retainers，逐层向上追踪——特别注意标有 closure、system / Context 或你项目源码文件名的引用项，它们往往是泄漏源头。
立即学习“Java免费学习笔记（深入）”；
结合代码清理习惯快速验证
发现可疑保留路径后，不要只改快照里看到的那一行。检查对应组件/模块的卸载逻辑：
- React 中确保
useEffect返回的清理函数里调用了removeEventListener、clearInterval，且不遗漏异步回调中的 DOM 引用 - 原生 JS 中，手动管理的节点要配对调用
element.remove()或parentNode.removeChild()，并置空所有引用（cachedNode = null） - 避免在事件处理器中直接使用
this或外层var声明的 DOM 变量；优先用局部常量 + 显式清理
不复杂但容易忽略。快照只是镜子，真正要动的是代码里那些“以为用完了、其实还攥着”的引用。
