structuredclone 拷贝大对象时内存开销取决于是否使用 transfer：未用时 arraybuffer 被复制，内存翻倍；启用 transfer 后主线程 buffer 被分离，worker 独占，总内存几乎不增。可通过 memory inspector、performance 面板及 performance.memory.usedjsheapsize 验证。
评估 structuredClone 拷贝大对象时的内存使用量，核心是区分“复制”与“转移”两种行为在内存层面的真实开销，而不是只看代码行数或数据大小。
看 ArrayBuffer 是否被复制而非转移
ArrayBuffer 是内存占用的“放大器”，它的处理方式直接决定峰值高低：
- 未用 transfer：主线程传
new ArrayBuffer(10MB)给 Worker，默认结构化克隆 → 主线程 + Worker 各占约 10MB，总内存瞬时达 20MB - 用了 transfer：
structuredClone(obj, { transfer: [buf] })→ 主线程 buf 变为 detached（byteLength === 0），Worker 独占该 10MB，总内存几乎不增 - 验证方法：在 Chrome DevTools 的 Memory Inspector 中搜索 ArrayBuffer 实例，若同一逻辑地址出现在两个线程中，说明被复制了
监控内存面板中的双峰现象
结构化克隆会触发瞬时、同步的内存尖峰：
- 在 Performance 或 Memory 面板录制一次 postMessage 调用，观察主线程和 Worker 是否出现高度接近、时间对齐的内存上升尖峰
- 若峰值幅度≈原始 ArrayBuffer 大小 × 2，且持续时间短但陡峭，基本确认是深拷贝导致的翻倍
- 用
performance.memory.usedJSHeapSize在调用前后采样，突增数值可粗略估算拷贝开销
查 Performance 面板里的序列化耗时
StructuredClone 任务的执行时间能反推内存压力：
- 打开 Performance 面板，勾选 “Web Workers” 和 “JavaScript samples”，录制通信过程
- 找到 PostMessage 事件下方紧邻的
StructuredClone或Deserialize任务条 - 该任务耗时随数据量线性增长（如 1MB → ~2ms，10MB → ~20ms），就是复制字节的实际开销；换成 transfer 后，这类长条应消失或缩至 0.1ms 级别
拆分元数据与载荷，分别评估
真实场景中，对象常含轻量元信息 + 大块二进制载荷，需分开看：
- 元数据（ID、时间戳、配置）走 structuredClone：几 KB 到几百 KB，内存开销小，可忽略不计
- 载荷（
Uint8Array.buffer、OffscreenCanvas）必须进 transfer 列表：哪怕只漏一个 buffer，整个 ArrayBuffer 仍会被完整复制 - 错误示例：传
uint8Array进 transfer —— 它不可转移；正确做法是传uint8Array.buffer
