定位堆内存异常最有效路径是分析Retained Size大且操作后不释放的对象，顺引用链查谁“拽着它不放”；需在基准、操作后、等待后三时机拍快照，聚焦Retained Size、Detached DOM、闭包对象数三类指标，用Retaining Tree和Comparison视图揪出泄漏源头。
直接看堆快照里 Retained Size 大、且操作后不释放的对象，再顺引用链往上查谁在“拽着它不放”——这是定位堆内存异常点最有效的路径。
抓准时机拍快照
别随便点一下就完事。先做一次干净的基准快照（比如页面刚加载完、没点任何交互），再执行你怀疑会出问题的操作（如打开又关闭弹窗、切换路由、反复增删列表），操作结束后立刻拍第二张。如果条件允许，可再加一张“等待几秒后”的快照，观察对象是否随时间回落。Chrome 拍快照前会自动触发一次 GC，所以看到的全是“活”对象，真实反映内存驻留状态。
聚焦三类高危指标
打开快照后，切换到 Summary 视图，重点扫以下三项：
- Retained Size 排名靠前的对象：比如某个闭包或组件实例占了几 MB，远超合理范围，它很可能拖着一整片对象无法回收
- Detached DOM trees 数量异常：这类节点已从文档中移除，却仍被 JS 变量引用，是泄漏典型信号
- (closure) 构造函数下对象数持续增长：尤其当它关联着大数组、缓存 Map 或定时器时，说明作用域没被释放
顺着引用链揪出“拽手”
选中一个可疑对象，右侧面板切到 Retaining Tree。从下往上看：
底部是 GC root（比如 window、timer 回调栈）→ 中间是中间层引用者（可能是未清除的 event listener、全局缓存、或某个存活的 Vue/React 实例）→ 顶部是你点的对象。
只要发现某条路径里存在本该销毁却还活着的模块、组件或回调，基本就是泄漏源头。例如：一个已卸载的 React 组件，被某个未 clear 的 setInterval 函数闭包持有着。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
用对比视图锁定增长源
把两张快照切到 Comparison 视图，按 Delta 列排序。重点关注：
- # New > 0 且 # Deleted = 0 的构造函数：说明每次操作都新建但从未释放
- Delta Retained Size 显著为正 的条目：不只是数量多，还占了大量内存
- 重复出现的相同构造函数名（如 MyChartComponent、DataProcessor）：指向特定模块逻辑缺陷
不复杂但容易忽略细节。关键不是找“最大”的对象，而是找“不该存在却一直存在”的对象——结合代码生命周期判断引用是否合理，比单纯看数字更可靠。
