worker 中操作大型二进制数据的关键是零拷贝传输、按需分片处理与轻量返回：必须用 transfer 传递 arraybuffer，避免结构化克隆；处理时切片并控制并发；结果不返传原始 buffer，任务结束及时关闭 worker。
在 Worker 线程中操作大型二进制数据，核心不是“怎么处理”，而是“怎么进来、怎么用、怎么收尾”。关键在于避免复制、明确所有权、及时释放——否则再快的算法也会被通信拖垮。
传输阶段：必须用 transfer，不能只传 ArrayBuffer
主线程读取文件后得到 ArrayBuffer，直接 postMessage(buffer) 会触发结构化克隆，10MB 就可能卡顿 200ms 以上。正确做法是显式声明 transfer 列表：
- 主线程调用：
worker.postMessage(fileArrayBuffer, [fileArrayBuffer]) - 传输后，主线程的
fileArrayBuffer.byteLength立即变为 0，说明所有权已移交 - Worker 收到的就是原始 buffer，可直接用于
new Uint8Array(buffer)或new DataView(buffer) - 切记：transfer 列表里只能放可转移对象（
ArrayBuffer、MessagePort、ImageBitmap），不能传普通对象或包含 buffer 的对象字面量
处理阶段：按需切片，避免一次性加载全量
即使 buffer 已零拷贝进入 Worker，若直接 new Uint8Array(buffer) 并遍历全部元素，仍可能触发 GC 压力。尤其在分片哈希、图像解码等场景，应主动分块处理：
- 用
buffer.slice(start, end)获取子 buffer（返回新 ArrayBuffer，但底层共享物理内存） - 对每个子 buffer 单独构造视图，例如
new Uint8ClampedArray(subBuffer) - 计算密集任务（如 Web Crypto digest）建议控制并发数（通常 4–6 片并行），避免线程争抢
- 每处理完一片，及时释放局部引用（如设为
null），帮助 JS 引擎识别可回收内存
返回与清理：结果轻量化，buffer 不返传
Worker 处理完大型二进制数据，通常不需要把整个 buffer 再传回主线程。多数情况只需返回摘要、元信息或小量结构化结果：
- 例如哈希计算：返回
Uint8Array转成的十六进制字符串，而非原始 buffer - 图像处理：返回 canvas.toBlob() 生成的 Blob，或压缩后的 base64 数据
- 若确实需传回修改后的 buffer（如编辑后的音频帧），同样要用
postMessage(resultBuffer, [resultBuffer])实现零拷贝返还 - 任务结束前调用
self.close()或主线程调用worker.terminate()，防止内存泄漏
避坑提醒：常见误操作
这些看似合理的小动作，实际会破坏零拷贝优势：
- 把 ArrayBuffer 包进普通对象再传：
postMessage({ data: buf })→ 因对象不可转移，整个结构被克隆 - Worker 中用
JSON.stringify序列化二进制数据 → 触发无意义编码，且极大膨胀体积 - 反复
new Uint8Array(buffer)而不复用视图 → 创建大量中间对象，加重 GC - 忘记 transfer 列表却以为“已经零拷贝” → 实际仍在默默复制，性能不升反降
