Chrome Performance Monitor 的实时图表通过 JS heap 曲线监测 V8 堆内存动态变化，健康时有节奏起伏并经 GC 回落，异常则基线上升或突增后不降；配合手动 GC 和重复操作可快速识别内存泄漏，但需排除 Canvas/WebAssembly 等干扰，其本质是预警哨而非诊断工具。
Chrome Performance Monitor 的实时图表能直观呈现 V8 堆内存的动态变化，这种波动就像页面的“心跳”——健康时有节奏、有回落、有呼吸感；异常时则僵直、爬升、不归位。
关键不是看绝对数值，而是看它“动得对不对”。
盯住 JS heap 这条线，就是盯住 V8 堆内存的脉搏
它显示的是当前可到达（reachable）JavaScript 对象实际占用的堆内存（单位 MB），括号里的数字就是实时值。这个值会随操作起伏：点击按钮、打开弹窗、加载数据……都会短暂推高；随后垃圾回收（GC）触发，它应明显回落，回到接近原基线的位置。
- 每次手动触发 GC（点浮层里的垃圾桶图标），JS heap 应下降 10–40 MB（视页面规模而定）
- 若连续几次 GC 后，曲线基线持续抬高（比如从 85 MB → 92 MB → 98 MB），说明有对象没被释放
- 若某次交互后 JS heap 突增且 GC 后几乎不动，大概率是闭包持有了 DOM、定时器未清除、或事件监听器未解绑
配合两个简单动作，快速验证“心跳是否失常”
- 在 Console 输入
performance.memory.usedJSHeapSize / 1024 / 1024，直接读取当前 JS 堆使用量（更精确，不含浮层四舍五入） - 反复执行同一操作（如开关一个模态框），观察 JS heap 是否阶梯式上升：每点一次，峰值+3 MB，GC 后只回落 1 MB → 累积泄漏迹象明确
注意几个干扰项，别被“假心跳”带偏
- 页面含大量 Canvas 或 WebAssembly 时，原生内存上涨但 JS heap 不变，此时需打开 Chrome 任务管理器（Shift+Esc）看总内存
-
DOM Nodes数同步上涨，往往和 JS heap 泄漏伴生，但 textNode、commentNode 也会计入，总数偏高属正常 - Performance Monitor 不记录历史、不展示引用链，它只告诉你“现在跳得不对”，下一步要用 Heap Snapshot 定位具体谁在“攥着内存不放”
本质上，这不是一个诊断工具，而是一个预警哨——看到心跳紊乱，就该暂停功能开发，切到 Memory 面板拍快照、比对、下钻了。
