要精准定位内存泄漏的JavaScript对象，需先录制分配时间线并手动触发垃圾回收，再拍三张堆快照做对比，聚焦#New列持续为正的构造函数，通过Retaining Tree和分配栈追踪强引用源头。
要精准定位到引发内存泄漏的具体JavaScript对象，不能只看内存曲线是否上涨，必须进入堆快照内部，逐层追踪谁在强引用它、为什么没被回收。
先确认存在泄漏趋势
打开 Chrome DevTools（F12）→ 切换到 Memory 面板 → 点击左上角 Record allocation timeline 开始录制 → 在页面执行疑似泄漏的操作（如反复打开/关闭弹窗、切换路由、刷新列表）→ 操作结束后点击停止录制。
观察蓝色内存曲线：如果每次操作后曲线未回落，且整体呈阶梯式上升，说明有对象持续堆积未释放。
【关键前提】录制前务必手动触发一次垃圾回收（点击面板左上角小垃圾箱图标），否则快照会混入本该被回收的临时对象，干扰判断。
立即学习“Java免费学习笔记（深入）”；
用堆快照锁定可疑构造函数
在 Memory 面板中，点击 Take heap snapshot 拍摄三张快照：
- 操作前（Baseline）
- 执行一次泄漏操作后
- 再执行一次相同操作后
全部拍完后，点击第一张快照右侧下拉箭头 → 选择 Comparison → 对比第二张快照 → 再对比第三张快照。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
重点关注 # New 列数值持续为正的条目：比如 (closure)、HTMLDivElement、EventListener、Array 或你自定义的类名（如 DataTable）。这些就是正在异常增长的对象类型。
从构造函数钻进具体实例
在 Comparison 视图中，双击某个高增长的构造函数（例如 (closure)）→ 右侧 Summary 视图会列出所有该类型的实例 → 按 Retained Size 降序排列 → 找到顶部几个 Retained Size 最大的实例。
点击其中一个实例 → 右侧自动切换到 Retaining Tree（保留树）→ 展开最顶层节点，查看是谁在“拽住”它不放。
常见阻断回收的持有者包括：Window（意外全局变量）、setInterval 回调、EventListener、Map 或 Object 的属性值、Detached DOM tree 的父引用。
顺着引用链定位源码位置
方法一：在 Retaining Tree 中找到最靠近叶子节点的 JS 脚本引用（通常显示为 script 后跟文件路径和行号）→ 直接点击该行 → 自动跳转到 Sources 面板对应代码行。
方法二：若某实例右侧有 Allocation stack trace（需在录制 Allocation Timeline 时勾选 “Record allocation stack traces”）→ 展开后可看到对象创建时完整的调用栈 → 点击栈底或中间某一层的 .js 文件链接，直达分配源头。
此时看到的代码，大概率就是泄漏发生的位置：比如 addEventListener 绑定后没配对移除、setTimeout 回调闭包捕获了大数组、或组件卸载后仍把 DOM 节点存进了全局 Map。
