DOM节点移除后仍被JS引用会形成Detached DOM树导致内存泄漏；可通过Performance面板观察JS Heap阶梯式上升初步判断，再用Heap Snapshot筛选detached节点并查看Retaining Tree定位强引用源头，结合getEventListeners和闭包分析确认泄漏点，最后通过对比快照与手动GC验证修复效果。
DOM 节点未移除本身不会直接导致内存泄漏，真正的问题是：节点已被移除（remove()、innerHTML = '' 或 removeChild），但 JS 仍持有对它的引用——这类节点会变成 Detached DOM tree，长期滞留在内存中。
看 Performance 面板确认泄漏趋势
这是最快的第一步判断：
- 打开 DevTools → Performance 面板 → 勾选 Memory 复选框
- 录制一段典型操作（例如：打开弹窗 → 点击关闭 → 重复 4–5 次）
- 停止录制后，观察 JS Heap 曲线：
✅ 正常情况：每次关闭后内存明显回落，呈波浪形
❌ 泄漏信号：曲线呈阶梯式上升，GC（灰色/黄色小块）频繁但回落极少，每次操作后基线持续抬高
用 Heap Snapshot 定位 Detached 节点
确认趋势后，精准抓出“被拽住”的 DOM：
- 刷新页面，进入 Memory 面板 → 点击 Take snapshot（命名为“快照1：初始”）
- 执行疑似泄漏操作（如连续打开/关闭模态框 3 次）
- 再拍一张快照（“快照2：操作后”）
- 在快照2筛选框输入 detached，重点关注：
•HTMLDivElement (detached)
•HTMLButtonElement (detached)
• 其他带(detached)标记的节点 - 双击任一 Detached 节点 → 右侧看 Retaining Tree：
→ 顶层带@符号的对象就是强引用源头（比如某个全局变量、闭包、定时器或事件监听器）
查事件监听器和全局引用链
Detached 节点往往不是孤立存在的，而是被其他对象“拉住”：
- 在控制台执行
getEventListeners(document)或getEventListeners(某个节点)，检查是否残留未清除的click、scroll等监听器 - 回到堆快照，筛选 Closure 或 Global，看是否有函数闭包捕获了该 DOM 节点
- 搜索你代码里常见的变量名（如
modal、chartEl、btnRef），确认它们是否在节点移除后仍非null或undefined
验证清理是否生效
改完代码后，别只信逻辑，要亲眼看见内存释放：
- 再次录制 Performance → 观察 JS Heap 是否恢复波动回落模式
- 拍新快照 → 搜索
detached→ 数量应与“快照1”接近，不再倍增 - 手动触发 GC：Memory 面板点垃圾桶图标，或控制台输入
if (global.gc) global.gc()（需启动参数支持）→ 若 Detached 节点消失，说明引用已断开
