直接打开 chrome devtools 的 memory 面板，通过 allocation instrumentation on timeline 观察堆内存阶梯式上升可确认内存泄漏，再用 heap snapshot comparison 按 # new 或 size delta 排序定位未释放对象及其保留路径，结合事件监听器、闭包、全局变量、定时器等常见泄漏模式验证修复。
直接打开 Chrome DevTools 的Memory面板，选中Heap snapshot或Allocation instrumentation on timeline，录制一段时间的操作（比如反复打开关闭模块），再对比堆快照或查看内存分配时间线，就能定位持续增长且未释放的对象。
确认是否真有内存泄漏：看堆内存趋势图
在 Memory 面板中，选择Record allocation timeline（带小圆点的录制按钮），然后执行疑似泄漏的操作（如点击按钮加载列表、再关闭、再加载……重复 3–5 次）。停止录制后，观察蓝色的堆内存曲线：
- 如果每次操作后内存没有回落到接近初始水平，而是阶梯式上升，说明对象没被回收
- 特别留意“JS Heap”和“Nodes”两行——前者增长说明 JS 对象堆积，后者突增可能意味着 DOM 节点未被移除
- 把鼠标悬停在曲线上，能看到具体时间点的堆大小（如 12.4 MB），方便横向比对
用堆快照定位“谁没被释放”
在相同操作前后各拍一次 Heap Snapshot（点击左上角相机图标）：
- 第一次在操作前（baseline），第二次在多次操作后（疑似泄漏点）
- 切换到第二个快照，在右上角下拉菜单选 Comparison，再选第一个快照作为对比基准
- 按 # New 或 Size Delta 排序，重点关注 Constructor 列中数量猛增或 size 显著变大的类型（如
MyComponent、Closure、Array） - 点开某构造函数，右侧会显示所有实例，点击任一实例可查看其保留路径（Retaining Tree）——从 GC root（如 window、全局变量、闭包引用）到该对象的引用链，这是定位泄漏根源的关键
关注常见泄漏模式对应的线索
很多泄漏不是代码写错，而是引用关系没断干净。通过快照或时间线可发现以下典型信号：
-
事件监听器未解绑：搜索
EventListener，看是否随操作次数增多；检查是否用了addEventListener却忘了removeEventListener，或用了匿名函数导致无法移除 -
闭包持有大对象：展开
Closure构造器，看其上下文（Context）里是否意外保留了 DOM 节点、数组或整个组件实例 -
全局变量或缓存未清理：搜索
window或你定义的全局缓存对象（如cacheMap），看其属性值是否越积越多 -
定时器未清除：查找
setTimeout/setInterval回调中的闭包，确认它们没因组件销毁而继续持有所属对象
配合代码验证与修复
找到可疑引用链后，回到源码针对性处理：
- 组件卸载时（如 React 的
useEffect cleanup、Vue 的beforeUnmount）主动解绑事件、清除定时器、置空缓存引用 - 避免在闭包中直接引用大型对象，改用 ID 或弱引用（如
WeakMap）做映射 - DOM 操作后及时调用
element.remove()或parent.removeChild()，确保节点脱离文档树 - 修复后重新录制 timeline，确认堆曲线回归平稳，不再阶梯上升
不复杂但容易忽略——关键是养成“操作前后对比”的习惯，而不是只看单次快照。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
