在 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 列降序排列：
- 找出高频分配的 Closure 类型，比如
(closure) handleScroll或(closure) fetchData - 点开堆栈，看它是否在循环或组件初始化中被反复创建
- 若某闭包 Self Size 很小但 Retained Size 超过 200KB，说明它捕获了不该持有的大对象（如整个
document.getElementById('app')或万级数组）
交叉验证：配合 Memory 面板快照
在 Performance 录制中找到内存峰值时间点，暂停并记下毫秒数。切换到 Memory 面板，拍一张快照，筛选 Constructor 为 Closure，按 Retained Size 排序：
立即学习“Java免费学习笔记（深入）”；
- 点击可疑闭包 → 查看右侧 Retainers
- 若显示
window → timer → closure或EventListener → closure → Array，就坐实了闭包长期持有了不该留的对象 - 顺着引用链中的文件链接，直接跳转到 Sources 面板对应代码行，定位问题源
修复后闭环验证
改完代码不能只看“好像不卡了”，要重新走一遍流程：
- 再次录制 Performance，JS Heap 曲线应回落平缓，GC 后内存明显下降
- 拍新快照对比，原来增长的 Closure 数量应下降或归零，Retained Size 明显回落
- 原引用链中的 timer、detached 元素、全局缓存变量，应已从该闭包的 Retainers 中消失
