核心问题是postmessage默认结构化克隆导致内存翻倍和cpu卡顿；应优先用transferable objects零拷贝传输arraybuffer等可转移对象，转移后原buffer立即失效，支持双向流转。
传输大数据时卡顿，核心问题不在 Worker 本身，而在 postMessage 默认的“复制”行为。10MB 数据一传，内存翻倍、CPU 狂序列化，主线程直接卡住。优化关键就一条：避免复制，改用所有权转移或共享内存。
优先用 Transferable Objects 零拷贝传输
这是最常用、兼容性好、效果立竿见影的方案。只适用于 ArrayBuffer 及其视图（Uint8Array、Float32Array 等）、MessagePort、ImageBitmap 等可转移对象。
- 主线程创建 ArrayBuffer 后，必须在
postMessage第二个参数中显式传入该 buffer（即 transfer list），否则仍会复制 - 转移后，原 buffer 的
byteLength立即变为 0，不能再读写——这不是 bug，是设计使然 - Worker 处理完，可以再把 buffer 转移回主线程，实现双向零拷贝流转
超低延迟场景考虑 SharedArrayBuffer
当需要 Worker 和主线程频繁、实时地读写同一块数据（比如实时音频分析、物理引擎模拟），SharedArrayBuffer 是更优解。它不复制也不转移，而是让双方共享同一段内存地址。
- 启用前需确保跨域隔离策略已设置（
crossOriginIsolated: true），现代浏览器强制要求 - 必须配合 Atomics 使用，防止多线程并发读写导致数据竞争
- 不适合一次性大文件处理，更适合持续高频交互的计算场景
避开结构化克隆的常见陷阱
很多卡顿其实源于误用：把普通对象、函数、Date、RegExp 或包含循环引用的数据直接扔进 postMessage。
- 浏览器会尝试深克隆，遇到不可序列化字段直接报错或静默失败
- 即使能克隆，10MB 的 JSON 对象也会触发长时间 GC，UI 出现明显卡顿帧
- 正确做法是提前剥离业务逻辑，只传纯二进制数据（ArrayBuffer）或扁平化结构体
结合业务做数据分片与流式处理
不是所有大数据都必须“一次全传”。对可分段任务（如 CSV 解析、日志过滤），可将数据切片后逐批发送。
- 主线程分块读取文件 → 每块转为 ArrayBuffer → 用 transfer list 发给 Worker
- Worker 逐块处理并返回结果，主线程边收边渲染，避免长等待
- 配合 AbortController 可随时中断传输，提升用户可控感
