Chrome内存泄漏分析核心是控变量、比差异、追引用：先拍干净环境下的Before/After快照，用Comparison模式找New>0且Size Delta>0的构造函数，再通过Retaining Path定位window/EventListener/定时器/闭包等强引用源头，并三次操作交叉验证。
用 Chrome 内存快照分析 JavaScript 内存泄漏，核心是“控变量、比差异、追引用”——不是看单张快照有多大，而是通过前后对比，找出本该被回收却持续存活的对象，并顺藤摸瓜定位强引用源头。
拍对两张关键快照
操作前必须确保环境干净：关闭无关标签页、禁用扩展、在隐身模式下测试。打开 DevTools → Memory 面板 → 选择 “Heap snapshot”：
- 快照 A（基准）：页面加载完成、初始化结束、无动画/定时器运行时立即拍摄，标记为 “Before”
- 快照 B（操作后）：执行一次完整疑似泄漏动作（如打开又关闭弹窗、切换路由、渲染再卸载组件），等待几秒后点击左上角垃圾桶图标手动触发垃圾回收（GC），再立即拍摄，标记为 “After”
用 Comparison 模式聚焦增长对象
在快照 B 列表中，顶部下拉选择 “Comparison”，再选中快照 A 作为基准。此时视图只显示差异项，重点关注：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- # New > 0 且 Size Delta > 0 的构造函数，尤其是你项目中的自定义类（如 MyModal、DataProcessor）、(closure)、EventListener、HTMLDivElement
- Retained Size 明显偏大且不随 GC 下降的对象——说明它被某个长生命周期对象牢牢“拽住”
- Detached DOM tree：已从文档移除但 JS 仍持有引用的节点，常出现在事件监听器或缓存逻辑中
点开实例查 Retaining Path 定位根源
点击某条增长明显的构造函数 → 展开具体实例 → 右侧切换到 “Retainers” 标签页。这里显示的是谁在强引用这个对象，是修复的关键线索：
- 路径以 window 或 globalThis 开头 → 检查是否意外创建了全局变量（如漏写
let直接赋值） - 路径含 EventListener → target → someDOMElement → 绑定监听器后未调用
removeEventListener，尤其注意匿名函数/箭头函数无法解绑 - 路径指向 setTimeout 或 setInterval 回调 → 组件卸载时忘记
clearTimeout/clearInterval - 路径中出现闭包作用域（Scope）捕获了大型数组、响应数据或 DOM 节点 → 回溯该闭包创建位置，检查是否应在销毁时主动设
null或清空引用
交叉验证确认是否真实泄漏
单次对比容易误判，建议做三次操作验证：
- A → B：增长 2 个 MyComponent
- B → C（再执行一次相同操作后拍）：又增长 2 个 → 基本可判定泄漏
- 配合 Performance 面板录制内存曲线，观察 JS Heap 是否阶梯式上升、不回落
- 开启 “Record allocation stack traces”（小齿轮设置中勾选），可直接看到新增对象在哪行代码生成
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
