录制前须关闭无关标签页和扩展，仅保留待测页面并禁用所有扩展；录制时按“操作→等待→操作→等待”节奏执行至少3轮相同操作，每轮后手动触发GC；通过Performance面板JS Heap曲线阶梯式上涨判断泄漏，并用Allocation Sampling定位高频分配对象。
录制前必须关掉无关标签页和扩展
Chrome 的 Performance 面板会把整个渲染进程的数据都收进来，包括其他标签页的 JS 执行、扩展注入的脚本、甚至 DevTools 自身的开销。如果你没关掉广告拦截插件或 React DevTools，它们会在后台频繁触发 requestIdleCallback 或 MutationObserver，让堆快照里堆满虚假的“泄漏对象”。
- 只保留待测页面一个标签页
- 用
chrome://extensions临时禁用所有扩展（尤其注意 Live Server、Vue Devtools 这类常驻监听的） - 打开 DevTools 后再点录制，避免初始化阶段被污染
录制时要模拟真实用户操作路径 + 等待稳定
内存泄漏不是“一刷新就爆”，而是多次操作后对象没被回收。单纯点一下按钮然后立刻停止录制，Heap Snapshot 里几乎看不出差异。关键在“操作 → 等待 → 操作 → 等待”这个节奏。
- 至少做 3 轮相同操作（比如打开弹窗 → 关闭 → 等待 2 秒；重复三次）
- 每轮结束后等 3–5 秒，给 V8 的 GC 机会（DevTools 不会自动触发 GC，得手动点
Collect garbage图标） - 录制时间控制在 20–40 秒内，太长会导致内存分配火焰图失真，也难定位具体哪次操作引入了残留
看“内存”轨道里的 JS Heap 曲线是否阶梯式上涨
录制完别急着切到 Memory 面板——先回 Performance 主视图，拖动时间轴，盯着顶部的 JS Heap 轨道。真正的泄漏表现为：每次操作后内存不回落到接近起点，而是像爬楼梯一样一级一级往上抬。
- 如果曲线每次下降后都能回到 ±1MB 以内，基本排除明显泄漏
- 如果第三轮关闭弹窗后，JS Heap 比第一轮同位置高 8MB 以上，且对应时间点的
Event Log显示有大量setTimeout或addEventListener调用，就要重点查事件绑定清理逻辑 - 注意区分“缓存增长”和“泄漏”：比如图片预加载后内存上升是正常的，但
document.addEventListener('click', handler)没removeEventListener就是泄漏
用“分配采样”快速定位高频分配对象类型
Allocation Sampling 比完整堆快照轻量，适合在录制中实时观察“谁在疯狂造对象”。它不会记录每个实例，但能告诉你哪行代码调用了多少次 new XXX()。
- 开启录制前，在
Performance面板右上角齿轮图标里勾选Allocation sampling - 录制结束后，在底部摘要栏切换到
Bottom-Up标签，按Allocations列降序排列 - 重点关注
Constructor列里反复出现的自定义类名（如ModalManager、ChartRenderer），再点进去看Script列定位到具体文件和行号 - 如果看到大量
Array、Object分配集中在某个useEffect或componentDidMount里，大概率是闭包捕获了外部变量没释放
WeakMap 键没被清除、哪条 IntersectionObserver 实例忘了 unobserve。这些细节不会直接写在火焰图里，得靠你对照代码里资源销毁的时机，一帧一帧比对操作前后堆里存活的对象引用链。 
