Memory面板通过“拍快照+看变化+找引用链”定位内存泄漏，支持实时监控JS堆、手动GC、分析detached DOM与闭包，结合时间线和任务管理器判断GC频率异常。
直接用 Memory 面板分析运行时内存泄漏和 GC 频率，核心是“拍快照 + 看变化 + 找引用链”。它不依赖录制过程，适合在页面持续运行中抓取关键瞬间，尤其适合排查单页应用中路由切换、组件反复挂载/卸载引发的泄漏。
实时监控 JS 堆与触发 GC
打开 DevTools → 切到 Memory 面板 → 选择 Heap snapshot 或 Allocation instrumentation on timeline 模式。但若只关心“当前内存状态”和“GC 是否频繁”，最轻量的方式是：
- 点击左上角 Live Heap Size 数字旁的刷新按钮（或按 Ctrl+R / Cmd+R），可手动触发一次堆快照并立即显示当前 JS 堆大小、对象数量、DOM 节点数等实时指标
- 在 Console 面板中输入 gc()（需提前在 DevTools Settings → Experiments 中启用 Disable JavaScript sampling 和 Enable advanced heap snapshot features）→ 回车，强制执行一次垃圾回收
- 观察 Memory 面板中 JS Heap 数值是否明显下降：若 gc() 后几乎不变，说明存在强引用阻止释放；若每次 gc() 后都回落但很快又涨回去，说明泄漏是周期性发生的（比如定时器、轮询、监听未解绑）
用堆快照定位已分离 DOM 和闭包泄漏
堆快照是识别“对象为何没被回收”的最直接证据。重点不是看总量，而是对比和筛选：
- 先在页面空闲状态拍一个基准快照（Take snapshot），再执行疑似泄漏操作（如打开弹窗→关闭→重复三次），再拍第二个快照
- 切换到第二个快照 → 在左上角筛选器中输入 (detached)，查看所有已从 DOM 树移除但仍被 JS 引用的节点；展开任一 detached 节点 → 点击右侧的 Retainers 标签 → 查看完整引用链（例如：window → myGlobalCache → array → element）
- 筛选 Closure 类型对象，按 Shallow Size 降序排列，重点关注生命周期长、Shallow Size 大且多次快照中持续存在的闭包——它们常因事件监听器、setTimeout 回调、React 组件闭包等意外持有了 DOM 或大数组
结合时间线判断 GC 频率是否异常
Memory 面板本身不展示 GC 时间轴，但可通过间接方式判断：
- 切换到 Allocation instrumentation on timeline 模式 → 点击录制 → 操作页面 10–20 秒 → 停止 → 观察下方时间线中蓝色小方块（代表新分配对象）的密度：若密集出现且持续不断，说明频繁创建对象；若同时伴随主线程卡顿（灰色长条），大概率是 GC 在后台高频介入
- 配合 Chrome 任务管理器（Shift+Esc）查看 JavaScript memory 列中的实时值（括号内数字）：若该值在无操作时仍缓慢爬升，或每几秒就剧烈波动（如 120MB → 95MB → 130MB → 90MB），说明 GC 正在频繁尝试回收但收效甚微——这是内存膨胀或弱泄漏的典型信号
- 注意区分：短暂峰值是正常行为（如渲染列表时临时创建节点），真正的问题是“峰值下不去”或“谷值越来越高”
验证泄漏是否真实存在
别只看数字增长，要确认增长的对象是否本该被释放：
- 在快照中选中可疑构造函数（如 Array、Object、HTMLDivElement）→ 右键 → Filter objects allocated between snapshots，仅显示两次快照间新增的对象
- 对这些新增对象逐个点开 → 查看其 Retainers → 如果引用链最终指向全局变量、未清理的事件监听器（EventListener）、或 React/Vue 的响应式代理（如 Proxy、VueComponent），基本可锁定泄漏源头
- 修改代码后（如加 removeEventListener、置空全局缓存、useEffect 清理函数），重新拍快照对比：若对应对象数量归零或稳定，说明修复有效
