识别web worker通信内存峰值的关键是区分结构化克隆（导致瞬时内存翻倍、双峰同步上升、structuredclone耗时线性增长）与零拷贝转移（detached arraybuffer、无复制、总内存不增）。
识别 Web Worker 通信中数据复制引发的内存峰值，关键在于区分「结构化克隆」与「零拷贝转移」两种行为在内存层面的可观测差异。默认用 postMessage(data) 传输大数据时，浏览器会完整复制一份到目标线程，导致瞬时内存翻倍——这正是峰值的根源。
看内存监控工具中的双峰现象
在 Chrome DevTools 的 Memory 面板中录制一次 Worker 通信过程，重点关注以下特征：
- 主线程和 Worker 线程各自出现几乎等高的内存上升尖峰（非叠加，而是同步出现）
- 峰值持续时间短但幅度大，且与
postMessage调用强相关 - 若使用
performance.memory手动采样，可观察到调用前后usedJSHeapSize突增，且恢复缓慢（GC 滞后）
检查 ArrayBuffer 是否被复制而非转移
ArrayBuffer 是最典型的“内存放大器”。若未显式使用 Transferable：
- 主线程创建
new ArrayBuffer(10MB)后调用worker.postMessage(buf)，主线程 + Worker 共占用约 20MB 内存 - 正确做法是
worker.postMessage(buf, [buf])，此时主线程 buf 变为 detached，Worker 独占该 10MB，总内存不翻倍 - 可在 DevTools 的 Memory Inspector 中查看 ArrayBuffer 实例是否在两个线程中同时存在（地址不同即为复制）
分析 Performance 面板中的序列化耗时
在 Chrome 的 Performance 面板录制并勾选 “Web Workers” 和 “JavaScript samples”：
- 查找
PostMessage事件下方是否紧跟着长条状的StructuredClone或Deserialize任务 - 该任务耗时随数据量线性增长（如 1MB → 2.4ms，10MB → ~24ms），是复制开销的直接证据
- 改用 Transferable 后，此类任务应消失或缩为毫秒级调度开销
用 chrome://inspect/#workers 观察 Worker 独立内存
主线程的 Memory 面板看不到 Worker 内存，必须单独调试 Worker：
- 打开
chrome://inspect/#workers，点击对应 Worker 的 “inspect” - 在其 DevTools 中启用 Memory 面板，录制通信过程
- 若 Worker 内存在接收后持续高位、GC 不触发，说明解析后的 DOM 树或大型 TypedArray 未释放（尤其在 DOMParser 场景中）
