chrome DevTools Memory面板堆快照比对是定位js内存泄漏最直接方式：执行操作后拍三次快照，用Comparison视图查#Delta为正且数量持续上升的对象，再通过Retainers树定位未清理的事件监听、全局变量、定时器或dom引用。
javaScript 内存泄漏不会立刻报错，但会导致页面卡顿、崩溃或持续增长的内存占用——关键不是“有没有泄漏”，而是“怎么确认它正在发生、来自哪段代码”。
用 chrome devtools 的 Memory 面板做快照比对
这是定位泄漏最直接的方式：触发疑似泄漏的操作（比如反复打开关闭模态框），然后手动拍三次堆快照（Heap Snapshot）并比对。
- 打开
DevTools → Memory → Heap Snapshot，点击录制图标拍下Snapshot 1（初始状态） - 执行操作（如渲染列表 → 删除 → 重新渲染），再拍
Snapshot 2和Snapshot 3 - 切换到
Comparison视图，选中Snapshot 3并对比Snapshot 1，重点关注constructor列中数量持续上升且#Delta为正的对象（如Closure、Array、自定义类名） - 点开某行，右侧的
Retainers树会显示谁持有着这些对象——常见泄漏源是未清理的addEventListener、全局变量引用、定时器闭包、DOM 节点被 JS 变量意外保留
用 Performance 面板录制定时器和 DOM 引用异常
某些泄漏不体现在堆快照里（比如频繁创建又丢弃的定时器），Performance 面板能抓到运行时行为模式。
- 在
Performance面板勾选Memory复选框，点击录制，执行操作（如滚动加载），停止后查看内存曲线是否阶梯式上涨 - 展开
Bottom-Up或Call Tree，筛选setInterval、setTimeout、attachEvent等调用，看是否随操作次数线性增加 - 注意
Detached DOM tree条目：表示 DOM 节点已被移除但仍有 JS 引用（比如缓存了document.getElementById('xxx')后没置空），这类节点会持续占内存
用 window.performance.memory 做轻量级运行时监控
适合在测试环境或灰度阶段加一段简单检测逻辑，不依赖 DevTools。
立即学习“Java免费学习笔记（深入）”；
-
window.performance.memory提供usedJSHeapSize、totalJSHeapSize和jsHeapSizeLimit，但仅 Chromium 内核可用 - 不要只看绝对值，要关注相对变化：比如连续 5 次操作后
usedJSHeapSize增长 > 20MB 且未回落，就值得怀疑 - 示例检测逻辑：
let lastUsage = window.performance.memory?.usedJSHeapSize || 0; function checkMemoryLeak() { const current = window.performance.memory?.usedJSHeapSize || 0; if (current - lastUsage > 10 * 1024 * 1024) { // 增长超 10MB console.warn('Possible memory leak detected', { lastUsage, current }); } lastUsage = current; } // 在关键生命周期钩子（如组件卸载后）调用 checkMemoryLeak()第三方工具只起辅助作用，别依赖它们自动报警
像 heapdump（node.js）、memwatch-next 或前端 @airbnb/webpack-plugin-memory-leak-detector 这类工具，要么不适用于浏览器环境，要么只能捕获粗粒度趋势，无法定位具体对象链。
- 浏览器里真正有效的仍是 DevTools 自带工具——其他库多数只是封装了
performance.memory或轮询快照，掩盖了分析过程 - 自动化脚本（如 Puppeteer + heap snapshot 导出）可行，但必须配合人工比对 Retainers，否则一堆
Closure数字毫无意义 - 真正难的是区分“合理缓存”和“泄漏”：比如一个常驻的
map存了 1000 个项，是业务需要还是忘了.clear()？得看代码上下文，工具给不出答案
内存泄漏的本质是引用关系没按预期释放，而 DevTools 的 Retainers 视图是唯一能让你“看见”这个关系的地方。截图、保存快照、比对三次以上——这些枯燥动作没法跳过。