分离的 DOM 元素不会自动回收，需手动清除 JavaScript 引用；通过 Chrome DevTools 的“分离的元素”工具定位，结合堆快照对比分析 Retaining Path，针对性清理全局集合、事件监听器、定时器及闭包引用，并验证内存是否稳定。
分离的 DOM 元素（Detached DOM Nodes）本身不会自动被回收，只要还有 JavaScript 引用指向它们，就会持续占用内存。单纯移除元素（如 el.remove() 或 parentNode.removeChild(el)）并不等于清除引用——如果变量、闭包、全局 Map、事件监听器或未清理的定时器仍持有对它的引用，它就变成“分离但存活”的对象，成为内存泄漏的典型源头。
识别分离元素：先用专用工具定位
Chrome / Edge 的 “分离的元素” 工具（在 DevTools → More Tools → Detached Elements）是第一步：
- 点击 收集垃圾 图标（?️），强制运行一次 GC
- 再点击 获取分离的元素，列出当前所有已从 DOM 树断开、却仍未被回收的节点
- 每个条目带 ID 和大小，可直接点击 分析 按钮——它会自动跳转到堆快照中，高亮出保留该节点的“保留者”（retainer）
用堆快照对比确认泄漏路径
分离元素只是表象，真正要解决的是“谁在留着它”。这时需配合堆快照对比：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 在空闲状态拍一个 Before 快照（确保无操作、无定时器活跃、无 pending promise）
- 执行一次完整操作（例如打开并关闭一个弹窗、切换路由、卸载组件），等几秒后手动点 GC，再拍 After 快照
- 切换为 Comparison 模式，筛选
# New > 0且Size Delta > 0的对象类型，重点看HTMLDivElement、Text、Comment等 DOM 类型 - 展开某项，查看 Retaining Path：若路径中出现
window、Module、Map、Set、setTimeout或闭包函数名，就找到了泄漏根因
针对性清除：四类高频泄漏源的清理方式
找到保留者后，按类型清理，不是删 DOM，而是断引用：
-
全局或模块级集合引用：如
const cache = new Map()存了 DOM 节点 → 组件卸载时必须调用cache.delete(key)；改用WeakMap更安全，它不阻止 GC -
未解绑的事件监听器：动态添加的
addEventListener必须配对removeEventListener；React 中写在useEffectcleanup 函数里，Vue 中在beforeUnmount钩子中清理 -
残留定时器或 Observer：
setInterval、MutationObserver、IntersectionObserver都需显式.disconnect()或clearInterval(id) -
闭包意外捕获：避免在事件处理器中直接引用大对象或整个 DOM 树；把需要的数据提前提取成轻量值传入，而不是让 handler 闭包持有
document.querySelector(...)结果
验证是否真正清除
清理代码上线后，不能只看功能是否正常，要闭环验证：
- 重复之前的操作流程（打开→关闭→GC），再进“分离的元素”工具，确认数量归零或稳定在极低基线
- 连续拍 3–5 组前后快照对比，观察 DOM 相关对象的
# New是否不再累积 - 用
window.performance.memory监控usedJSHeapSize，确认多次操作后内存不持续上涨
