浏览器内存泄漏诊断需综合任务管理器、performance面板、performance.memory和堆快照comparison：静置内存应平稳，重复操作后js heap阶梯上升、gc回落微弱、usedjsheapsize增幅超30%、detached节点或闭包持续增加即表明泄漏。
浏览器内存占用报告不是一串数字，而是一份“运行健康证”。关键不在于总值多高，而在于它怎么变、何时回落、和什么操作挂钩。直接看曲线和对比差值，比盯着绝对数值有用十倍。
看任务管理器：先筛出异常趋势
按 Shift + Esc 打开浏览器任务管理器，找到你的页面标签页，盯住“内存”列：
- 静置 10 秒不操作，内存应基本持平或小幅波动（±5MB 内）。如果持续爬升，说明后台有对象在悄悄堆积
- 反复执行同一操作（如打开/关闭弹窗）5 次，每次操作后等待 5 秒再记录数值。若连续上升且单次增长超 20MB，基本可判定泄漏已发生
- 注意区分“内存”和“JavaScript 内存”——前者含渲染层、图片解码等，后者（即 JS Heap）才是排查重点
看 Performance 面板：抓 GC 是否失能
在 Performance 面板录制 15 秒典型操作（含滚动、点击、切换），务必勾选 Memory：
- 关注 JS Heap 曲线形态：阶梯式上升（每次操作后跳一级）、GC 后回落幅度极小（比如只降 1–2MB），就是泄漏在积累的典型特征
- 留意灰色竖线（GC 标记）：如果 GC 频繁但堆大小不降，说明大量对象因被意外引用而无法回收
- 同时观察 Nodes 和 Listeners 曲线：DOM 节点数或事件监听器数只增不减，往往指向 Detached DOM 或未移除监听器
看 performance.memory：量化验证泄漏量级
在控制台执行 performance.memory，重点关注三个字段：
- usedJSHeapSize：当前 JS 堆实际使用量（核心指标）
- totalJSHeapSize：堆总容量（V8 分配的上限，会动态调整）
- jsHeapSizeLimit：堆硬上限（通常约 2GB）
操作前执行一次，操作后立即再执行一次。若 usedJSHeapSize 增长超过初始值 30%，且重复操作后增幅持续扩大，就是泄漏在放大的铁证。
看堆快照 Comparison：定位谁在“锁死”内存
进入 Memory 面板，拍三张快照：
- 刷新页面 → 快照 1（基线）
- 执行疑似泄漏操作（如连开 3 次详情页）→ 快照 2
- 再执行一次同样操作 → 快照 3
选中快照 2 和 3，切到 Comparison 视图，重点扫这几类：
- Closure：数量持续增加，说明闭包持有外部大对象未释放
- Detached HTMLDivElement（或类似 Detached 节点）：DOM 已从页面移除，但 JS 还握着引用
- Array / Object / String：体积大、数量多、Retained Size 高的对象，点开看 Retaining Path，顶端带 @ 符号的就是泄漏源头
Retaining Path 中出现 Window → … → yourComponent → nodeRef 这类链条，基本就能锁定是组件卸载后没清掉 DOM 缓存或事件回调。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
