排查JS内存泄漏需定位不该持有却强引用目标对象的源头，通过Chrome Memory面板拍堆快照、分析Retainers路径，重点检查window、定时器、事件监听器、Map/Set等高危引用，并在卸载钩子中显式清理。
排查 JS 内存泄漏时，关注变量引用关系的核心不是“看谁引用了谁”，而是**定位谁在不该持有时仍强引用着目标对象**——因为 GC 只回收不可达对象，而“可达”就藏在引用链里。
从堆快照的 Retainers 入手找强引用源头
打开 Chrome DevTools → Memory 面板 → 先点小垃圾箱图标手动触发 GC → 再拍堆快照（Heap Snapshot）。筛选出疑似泄漏的对象（如某组件实例、大型数组、闭包），点击它，在右侧 “Retainers” 栏中查看引用路径：
- 若路径中出现 parent → children → parent 或 el.__vue__ → component → data → hugeList，说明存在强引用闭环
- 重点盯住路径里带 window、globalThis、setTimeout、EventListener、Map/Set 实例 的节点——这些往往是泄漏锚点
- 避免被“设计性循环”干扰：Vue 响应式依赖（如 dep.subs）或 React Fiber 节点间的父子指针是正常结构，不等于泄漏；真正要揪的是 业务代码主动挂载未清理的引用
重点关注四类高危引用模式
变量之间是否构成危险引用，取决于它是否跨生命周期、跨作用域、且未被显式切断：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
-
事件监听器反向锁住上下文：比如
btn.addEventListener('click', () => console.log(this.data))，组件卸载后监听器还在，this就无法释放 -
闭包捕获了不该长期持有的大对象：父组件传入子组件的回调里用了
props.onSave = () => api.submit(largeFormData)，子组件缓存该回调，父组件数据就被焊死 -
DOM 节点反向持有 JS 对象：自定义指令或图表库在
el._instance = this后，没在组件销毁时清掉el._instance -
共享响应式对象意外形成双向绑定：两个组件共用同一个
ref({})，又各自往里面塞对方的引用（shared.child = childRef; shared.parent = parentRef）
用代码手段验证和切断引用链
光看快照不够，得动手验证引用是否真被断开：
- 在组件卸载钩子（如 Vue 的
onBeforeUnmount、React 的useEffect cleanup）中，显式执行：removeEventListener、clearInterval、off()、el._instance = null - 避免用字符串 key 缓存对象：
cache['user-123'] = user是强引用；改用WeakMap且确保 key（如 DOM 元素）本身也不被其他地方强持 - 清理后重新拍快照对比：目标对象的 Retained Size 应归零或大幅下降，且 “Retainers” 列表里不再出现你写的业务变量名
引用关系不是静态图谱，而是动态链条。真正决定泄漏与否的，是你在哪个时机、以什么方式松开了哪一只手。
