web worker 无硬性内存上限，但实际受限于浏览器进程、设备内存及主线程竞争；制约大对象处理的主因是结构化克隆导致的复制开销与内存冗余，transferable objects（如arraybuffer）通过所有权移交实现零拷贝，sharedarraybuffer则适用于需线程安全共享访问的场景。
Web Worker 本身没有硬性内存上限，但实际可用内存受浏览器进程整体限制、设备物理内存及主线程竞争影响。真正制约大对象处理的，不是 Worker 线程“不能用多少”，而是数据传递方式带来的复制开销和内存冗余。
结构化克隆是默认陷阱
主线程调用 worker.postMessage(largeObj) 时，浏览器会启动结构化克隆算法：遍历整个对象树，序列化后再反序列化到 Worker 内存空间。对一个 50MB 的 ArrayBuffer 或嵌套深的 JSON 数据：
- CPU 需要逐字段拷贝、类型校验、循环引用检测，耗时明显
- 内存中同时存在两份完整副本（主线程 + Worker），瞬间占用翻倍
- GC 压力增大，尤其在频繁传输场景下易触发卡顿或 OOM
Transferable Objects 是首选解法
适用于 ArrayBuffer、TypedArray、MessagePort、ImageBitmap 等可转移类型。核心是“所有权移交”，而非复制：
- 主线程传入时必须显式提供 transfer list：
worker.postMessage(buffer, [buffer]) - 传输后主线程的
buffer.byteLength变为 0，不可再读写 - Worker 收到的是原生内存块，零拷贝、无 GC 开销，可直接用于
Uint8Array或解码 - 如需回传，Worker 同样用
self.postMessage(buf, [buf])转移回去
SharedArrayBuffer 适合高频共享访问
当主线程与 Worker 需要**同时读写同一块内存**（如实时音视频处理、游戏状态同步），SharedArrayBuffer 提供真正的共享视图：
- 双方通过
new Uint32Array(sharedBuf)创建不同视图，操作同一物理内存 - 需配合
Atomics实现线程安全读写（避免竞态） - 启用前需设置跨域隔离头（
Cross-Origin-Embedder-Policy: require-corp和Cross-Origin-Opener-Policy: same-origin） - 不适用于单向批量传输，更适合持续低延迟协同场景
规避常见误操作
很多性能问题其实源于细节疏忽：
- 忘记写 transfer list ——
postMessage(buf)看似简洁，实则触发完整克隆 - 试图转移普通对象（如
{data: buf}）—— 整个对象无法转移，会报DataCloneError - 在 Worker 中反复创建大数组而不释放 —— 即使不用 transfer，也要主动置 null 或复用 ArrayBuffer
- 忽略主线程内存残留 —— 转移后虽不可用，但若之前有引用未清理，仍可能阻碍 GC
