Detached DOM内存泄漏源于JS变量引用已移除节点导致无法回收。需用Chrome Memory面板拍快照比对，筛选Detached DOM树，查Retainers定位全局变量、闭包等持有者，并通过isConnected和parentNode验证后置null或改用WeakMap修复。
DOM节点被移除后仍被变量引用，是典型的“Detached DOM”内存泄漏。问题不在于节点没删掉，而在于JavaScript还牢牢抓着它——垃圾回收器一看“还有人引用”，就判定它“可达”，拒绝释放。排查核心就是：找出谁在偷偷持有已脱离文档的DOM节点。
用 Chrome DevTools 捕获 Detached DOM 节点
打开开发者工具 → Memory 面板 → 点击 “Take Heap Snapshot” 录制快照。等页面运行一段时间（比如执行几次移除操作）后，再录第二张快照。切换到 Summary 视图，筛选 Detached DOM tree 类型。如果数量持续增长，说明存在泄漏。
- 点击某条 Detached DOM 条目 → 右侧 Retainers 标签会显示引用链，例如：
window.cacheList、myModule.elementRef或某个闭包的Scope - 重点看引用路径中是否出现全局变量、模块级对象、定时器回调、事件监听器或闭包作用域
- 展开该节点的属性（如
childNodes、parentNode），确认其parentNode === null且不在 document 中，即可断定它是“已脱离但未释放”
检查常见持有 DOM 的代码模式
不是所有 DOM 引用都危险，但以下写法极易导致泄漏：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
全局或模块级缓存 DOM 元素：如
const cachedEl = document.getElementById('app')放在顶层作用域；移除 #app 后，cachedEl 仍指向旧节点 -
闭包中捕获 DOM 变量：函数返回一个闭包，而该闭包作用域里保存了
el，之后这个闭包又被长期存在的对象（如定时器、事件监听器）引用 -
事件监听器绑定在外部容器，但闭包内引用了子节点：比如
window.addEventListener('click', () => { const btn = document.querySelector('.btn'); ... })，每次执行都新建引用，且无清理机制 -
使用 innerHTML 清空容器，却仍保留对原子节点的引用：如先
const child = container.firstChild，再container.innerHTML = ''，child 变量依然有效
验证与修复的关键操作
发现可疑引用后，不能只靠“看起来像”，要实证：
立即学习“Java免费学习笔记（深入）”；
- 在控制台手动执行
console.log(cachedEl.isConnected)—— 返回false且cachedEl.parentNode === null，即为 detached - 在对应代码位置，移除或置空引用：
cachedEl = null，或改用 WeakMap 缓存（以 DOM 元素为键，自动随元素销毁而清理） - 若引用来自闭包，考虑重构：把大对象或 DOM 节点从闭包作用域中剥离，或确保闭包生命周期与 DOM 一致（如组件卸载时主动释放）
- 在 Vue/React 等框架中，利用
beforeUnmount或useEffect cleanup函数统一清空变量引用和定时器
预防比排查更高效
日常编码中守住几条边界，能大幅降低这类问题发生概率：
- 避免直接缓存 DOM 节点，优先缓存数据或 selector 字符串，需要时再查
- 所有对 DOM 的引用，尽量限制在函数作用域内（如事件回调内部创建并使用），避免逃逸到外层
- 使用
WeakMap存储 DOM 相关元数据（如状态、配置），键是 DOM 元素，值不会阻止元素被回收 - 移除节点后，显式切断 JS 引用：
el.remove(); el = null;，尤其在循环、定时器或长期存活对象中
