在 performance 面板排查 javascript 内存泄漏需先排除干扰、录制操作并观察 js heap 是否阶梯式上升；再通过 allocation sampling 定位高频 closure，结合 memory 面板快照分析 retainers 引用链，最终验证修复效果。

在 Performance 面板中排查 JavaScript 内存泄漏，核心是观察内存行为是否异常，并结合分配采样和引用路径定位源头。它不依赖猜测，而是用真实数据验证“对象该释放却没释放”这一事实。

先确认泄漏是否存在

打开 Performance 面板前，做三件事：关掉所有无关标签页和浏览器扩展（尤其 Vue/React DevTools、广告拦截器）；只保留待测页面；清空缓存（Ctrl+Shift+Del → 仅勾选“缓存的图像和文件”）。然后录制 25–35 秒的操作过程，重点看 JS Heap 曲线：

• 如果每次执行相同操作（如打开弹窗 → 等待2秒 → 关闭 → 等待3秒）后，内存都回落到±1MB 范围内，基本无泄漏
• 若第三轮操作结束时 JS Heap 比第一轮同位置高出 5MB 以上，且呈阶梯式抬升，说明有对象持续驻留
• 同步观察 Nodes 和 Listeners 数量轨道：若它们与 JS Heap 同步增长，大概率是事件监听 + 闭包锁住了 DOM 或大数组

用 Allocation Sampling 找闭包源头

录制前，在右上角齿轮中勾选 Allocation sampling。录制完成后，切换到底部 Summary 标签 → Bottom-Up 视图 → 按 Allocations 列降序排列：

javascript-pro

专注现代 ECMAScript、异步编程、性能优化和全栈的 JavaScript 专家，适用于现代开发

下载

• 找出高频分配的 Closure 类型，比如 (closure) handleScroll 或 (closure) fetchData
• 点开堆栈，看它是否在循环或组件初始化中被反复创建
• 若某闭包 Self Size 很小但 Retained Size 超过 200KB，说明它捕获了不该持有的大对象（如整个 document.getElementById('app') 或万级数组）

交叉验证：配合 Memory 面板快照

在 Performance 录制中找到内存峰值时间点，暂停并记下毫秒数。切换到 Memory 面板，拍一张快照，筛选 Constructor 为 Closure，按 Retained Size 排序：

• 点击可疑闭包 → 查看右侧 Retainers
• 若显示 window → timer → closure 或 EventListener → closure → Array，就坐实了闭包长期持有了不该留的对象
• 顺着引用链中的文件链接，直接跳转到 Sources 面板对应代码行，定位问题源

修复后闭环验证

改完代码不能只看“好像不卡了”，要重新走一遍流程：

• 再次录制 Performance，JS Heap 曲线应回落平缓，GC 后内存明显下降
• 拍新快照对比，原来增长的 Closure 数量应下降或归零，Retained Size 明显回落
• 原引用链中的 timer、detached 元素、全局缓存变量，应已从该闭包的 Retainers 中消失

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南