Detached DOM 节点是已脱离文档但仍被 JS 强引用的 DOM 元素，导致内存泄漏；需在 Chrome Heap Snapshot 的 Constructor 视图中搜索其数量变化，并通过 Retainers 定位缓存、Map、闭包或第三方库中的未清理引用。
排查隐藏 DOM 元素保留在内存中的泄漏，关键是识别“已脱离文档但仍在 JS 中被强引用”的 Detached DOM 节点。这类节点不渲染、不可见，却因 JS 变量、闭包、Map 或事件监听器持续持有，导致整个子树无法被垃圾回收。
看 Detached DOM tree 在堆快照中是否异常增长
在 Chrome DevTools 的 Memory 面板录制 Heap Snapshot 后，切换到 Constructor 视图，直接搜索 Detached DOM tree：
- 该类型不是构造函数，而是 V8 标记的特殊对象组，代表已从 document 移除但仍有 JS 引用的 DOM 节点及其后代
- 关注其 # New 数量：执行一次“显示→隐藏→销毁”操作后，若 Detached DOM tree 条目持续新增且不回落，说明有引用未清理
- 点击某条目 → 右侧 Retainers 标签查看谁在“拽住”它（如 globalThis.cacheMap、某个闭包的 Scope、事件监听器、定时器回调）
检查 JS 中对 DOM 节点的强引用位置
Detached DOM 不会自己滞留，一定有 JS 代码显式或隐式地保存了它的引用。重点排查以下几类：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 缓存变量未清空：例如 const el = document.getElementById('modal'); modalEl = el; 后续 el.remove() 了，但 modalEl 仍指向原节点
- Map / Object 键值强引用：用 DOM 元素作普通 Map 的 key（new Map().set(el, data)），会导致 el 永远无法 GC；应改用 WeakMap（key 是弱引用）
- 闭包捕获了 DOM：比如事件回调里用了外层函数定义的 el，而该回调被挂到全局或长期存活对象上
- 第三方库内部持有：图表库、弹窗组件等常缓存 DOM 节点做重绘优化，需确认其销毁 API 是否被调用（如 chart.destroy()、modal.close()）
结合代码与快照交叉验证引用链
在 Retainers 中看到某个 Detached DOM 被 closure 持有时，不要只看“是闭包”，要展开它的 Scope：
立即学习“Java免费学习笔记（深入）”；
- 找到具体哪个变量名（如 node、$el、container）持有了该 DOM
- 特别注意动态创建的元素：innerHTML = '' 或 replaceWith(null) 并不会自动解除 JS 引用，必须手动切断
用对比快照 + 手动 GC 缩小嫌疑范围
避免把临时对象误判为泄漏：
- 拍快照前，先点 DevTools 左上角的垃圾回收图标（?️）强制触发 GC
- 执行“打开弹窗 → 点击关闭按钮 → 等待 1 秒 → GC → 拍快照”，再和初始快照比对
- 在 Comparison 视图筛选 Detached DOM tree，只关注 Delta > 0 且 Retainers 指向你项目代码（非第三方库）的条目
