内存泄漏本质是该释放的对象未被回收，需通过chrome memory面板对比快照识别持续增长的closure、object、array及自定义缓存类；重点排查全局缓存无边界、闭包持有大对象、dom引用残留、第三方实例未销毁四类问题，并用performance面板和performance.memory验证修复效果。
运行时内存持续增长，不是“用了多少”的问题，而是“该释放的没释放”——关键在识别那些本该被回收却一直被强引用的对象。它不报错、不中断流程，只让页面越用越卡，最终在低配设备或长时间驻留场景（如大屏、直播页）中崩溃。
用 Chrome Memory 面板做对比快照
不能只看单次快照，要捕捉增长趋势：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 打开 DevTools → Memory 面板 → 点击垃圾箱图标手动触发 GC
- 执行一次典型操作（比如进列表页 → 查数据 → 退出），再 GC → 拍 Snapshot 1
- 重复同样操作 2–3 轮，每次操作后都 GC + 拍新快照（得 Snapshot 2、Snapshot 3）
- 选 Snapshot 3 → 切到 Comparison 视图 → 对比 Snapshot 1，重点关注 Delta 列为正且持续增大的项
- 筛选关键词：closure、Object、Array、你自定义的缓存类名（如 ApiCache、userStore）或模块路径
重点盯这四类“静默吃内存”的模式
它们不抛异常，但会让 JS 堆阶梯式上涨：
-
全局缓存无边界：比如
window.cache = {}或模块顶层const cache = new Map()，反复set却从不delete或clear - 闭包长期持有大对象：函数返回一个内部函数，而该函数闭包里引用了万级数组、完整响应体或 DOM 节点，且这个闭包被挂到了事件监听器或定时器里
-
DOM 引用残留：缓存了
document.getElementById('xxx')的结果，后续节点已被移除，但 JS 数组/Map 里还存着它的引用 -
未销毁的第三方实例：比如 hls.js 播放器只调
video.pause()，却漏掉hls.stopLoad()、hls.detachMedia()、hls.destroy()
验证修复是否生效
改完代码不能只信感觉，要用数据确认：
- 在 Performance 面板开启内存录制（勾选 Memory），连续执行目标操作 8–10 次，观察 JS Heap 曲线是否趋于平缓，不再出现明显阶梯上升
- 回到 Memory 面板，再拍三组快照（操作前、中、后），对比确认之前增长明显的类或 closure 数量已稳定甚至回落
- 检查
performance.memory实时值：在控制台轮询performance.memory.usedJSHeapSize / 1024 / 1024，看是否在合理区间波动（例如 80–150MB），而非单向突破
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
