performance面板录制可实时观察js堆与dom节点变化，关键看gc后是否回落；memory面板用分配时间线定位异步代码分配源头；task manager辅助验证跨标签页内存增长；需重点关注未取消promise、未移除事件监听器、未清除定时器、未节流流式数据四类高危模式。
直接打开 Performance 面板并启用 Memory 选项，录制异步操作全过程，就能清晰看到 JS 堆与 DOM 节点随任务推进的实时变化。关键不是“看有没有增长”，而是看“涨了之后回落不回落”——真正的泄漏藏在 GC 后仍不释放的残余里。
Performance 面板：录制中观察真实波动
这是最贴近用户行为的实时监控方式。打开 DevTools（F12），切换到 Performance 面板，勾选顶部的 Memory 复选框，再点击左上角圆形录制按钮。
- 开始录制后，立即触发你的异步任务（如点击加载按钮、滚动触发懒加载、WebSocket 收消息、定时器回调执行等）；
- 持续操作 5–10 秒，覆盖多个任务周期（例如连续发起 3 次 fetch 或触发 3 轮 setInterval 回调）；
- 停止录制，查看下方时间轴中的 JS Heap 和 DOM Nodes 两条曲线。
重点关注：JS Heap 是否呈阶梯式上升（每次 GC 后未回到原位）、DOM Nodes 是否在任务结束后未归零。若某次 fetch 完成后 DOM 节点数 +20 且不再下降，就值得深挖那 20 个节点是否被意外保留。
Memory 面板：用分配时间线定位异步源头
堆快照适合查“谁占得多”，而分配时间线（Allocation instrumentation on timeline）更适合查“谁在持续申请”。它能精确到毫秒级，标记出哪段异步代码在反复分配对象。
- 在 Memory 面板中，选择 Record allocation timeline 模式；
- 点击 Start，执行异步操作（比如监听一个 Promise.all 的完成、或反复调用一个返回新数组的 API 解析函数）；
- 停止录制后，时间轴上会高亮显示内存分配密集区，鼠标悬停可看到具体构造函数（如 Array、Object、CustomItem）和调用栈；
- 展开调用栈，往往能直接定位到 async 函数内部、.then() 回调、或事件处理器中创建未清理对象的位置。
例如：你发现大量 new Map() 分配集中在某个 handleMessage 函数里，而该函数由 WebSocket onmessage 触发——这就提示你检查 Map 是否被缓存却从未清除。
Task Manager 辅助验证：跨标签页横向对比
Chrome 自带的任务管理器（Shift+Esc）提供轻量级、低侵入的实时参考值，特别适合判断“是不是这个标签页的问题”。
- 右键表头 → 勾选 JavaScript memory 和 Memory；
- 观察两列数值：JavaScript memory 括号内数字（即 JS 堆实时大小）是否随异步任务稳定爬升；Memory 列（原生内存）是否同步增长——若后者也涨，说明可能有大量 DOM 节点或 Canvas 图像未释放；
- 对比同页面空载状态与高频异步运行后的差值，增幅超过 20MB 且不可逆，基本可判定存在累积性泄漏。
它不告诉你“为什么”，但能快速确认“确实有问题”，避免把偶发抖动误判为泄漏。
结合代码特征，聚焦四类高危异步模式
知道工具怎么用之后，要带着怀疑去看数据。以下异步场景最容易引发 JS 堆或 DOM 波动异常：
- 未取消的 Promise 链：fetch 请求已结束，但 .then() 中创建的大对象（如解析后的完整日志数组）被闭包捕获，且无清理机制；
- 持续注册的事件监听器：每次 WebSocket 收到消息都 addEventListener 给同一个 DOM 元素，但没用 removeEventListener 对应移除；
- 定时器持有引用：setInterval 回调中引用了组件实例或大型数据结构，即使页面跳转、组件卸载，定时器仍在运行并阻止 GC；
- 流式数据未节流/未销毁：ReadableStream 或 EventSource 接收高频数据，但 ondata 回调中不断 push 到全局数组，也不设长度上限或自动清理策略。
一旦在 Performance 或 Allocation 时间线中发现对应构造函数高频出现，立刻回查这类代码模式。
