js内存泄漏本质是本该不可达的对象被活引用链持续持有；排查应先通过静置内存不回落、操作后阶梯式上涨、gc低效三个信号快速确认，再聚焦事件监听器未清理、意外全局变量、闭包持大对象、定时器未清除、dom引用残留五类高频问题定位并修复。
JS 内存泄漏不是“内存没被回收”，而是“本该不可达的对象，依然被某个活引用链牢牢拽着”。排查关键不在堆大小数字本身，而在找出那条不该存在的引用路径。
快速确认泄漏是否存在
别一上来就开 DevTools 截快照。先用三个可量化信号交叉验证：
- 静置内存不回落：页面空闲 10 秒后，打开 Chrome 任务管理器（Shift+Esc），观察“内存”列——若持续缓慢上涨（如每分钟 +20MB），且无回落趋势，高度可疑；
- 操作后内存阶梯式抬升：重复执行同一动作（如打开/关闭模态框、切换 Tab）10 次，每次操作后等待 5 秒再看内存值。若第 10 次比第 1 次高 30% 以上，说明对象未销毁；
- GC 频繁但收效甚微：Performance 面板录制 15 秒，勾选 “Memory” 和 “Garbage Collection”。若出现 ≥4 次 GC，但每次回收后堆占用仅下降不到 5%，说明大量对象“活着却无用”，即典型泄漏特征。
高频泄漏场景与对应解法
80% 的泄漏集中在以下五类，修复方式明确、见效快：
-
未清理的事件监听器：尤其注意
window、document或第三方组件（如地图、图表）绑定的resize、scroll、message监听。修复必须成对出现：addEventListener后，组件卸载或 DOM 移除时调用removeEventListener；更稳妥的做法是使用{ once: true }或在回调中手动解绑； -
意外全局变量：函数内漏写
let/const（如data = []），或this.xxx在非构造函数中调用，都会把变量挂到window上。加'use strict'可直接报错拦截； -
闭包持有大对象：常见于封装工具函数或状态管理逻辑，例如返回一个内部缓存数组的 getter 函数。只要闭包函数还存活，外部大数组就无法释放。解法是明确生命周期，在不需要时主动将闭包引用设为
null，或改用弱引用结构（如WeakMap缓存）； -
定时器引用外部数据：如
setInterval(() => console.log(userData), 1000)，只要定时器没清除，userData就一直被持有。务必在组件销毁、页面离开前调用clearInterval/clearTimeout； -
DOM 引用残留：移除了 DOM 元素，但 JS 里还存着它的引用（如
const el = document.getElementById('box')）。即使元素已从文档树消失，JS 对象仍存在。解法是移除 DOM 后，同步将相关 JS 变量置为null，或确保引用只存在于当前作用域内。
精准定位泄漏源头的三步法
不用翻几万行代码，靠工具链缩小范围：
-
查监听器：控制台输入
getEventListeners(document)或getEventListeners(window)，对比操作前后新增项，重点盯住未清理的回调函数； -
抓堆快照对比：在 Chrome DevTools 的 Memory 面板，先拍一张基准快照（Heap Snapshot），执行疑似泄漏操作 5 次，再拍第二张。切换到 “Comparison” 视图，筛选
Retained Size排名靠前、且两次快照差值大的构造函数（如Array、Object、自定义类名），点开看“retainers”路径； -
顺引用链溯源：在快照中点击可疑对象 → 查看右侧 “Retainers” 栏 → 层层展开直到找到最上层的根引用（如
window、globalThis、某个长期存活的模块对象）。这条链上的第一个“非预期持有者”，就是泄漏元凶。
经典案例复盘：一个隐藏在 WebSocket 心跳里的泄漏
某后台管理系统上线后，用户停留 2 小时，内存增长至 1.8GB，P95 响应延迟翻倍。排查过程如下：
- 任务管理器显示内存线性上升，排除偶发抖动；
- 快照对比发现
ArrayBuffer占比突增 60%，但业务代码几乎不用 ArrayBuffer； - 顺着 retainers 追溯，发现所有 ArrayBuffer 都被一个
WebSocketHeartbeat实例的this.bufferList数组持有； - 进一步查看该实例的 retaining chain，终点是
window下的一个未清除的onmessage回调 —— 原来 SDK 在重连时反复 new 实例，但旧实例的事件监听未解绑，也未清空 bufferList； - 修复仅一行：
ws.removeEventListener('message', this.handleMsg)，并在实例销毁时清空 bufferList。上线后内存曲线彻底走平。
真正难的不是技术，是建立“引用是否合理”的判断习惯。每次新增监听、定时器、闭包或 DOM 引用，都问自己一句：它什么时候该消失？谁负责让它消失？
