Web Workers 是独立 JS 执行上下文而非真正多线程，与主线程内存隔离、仅通过 postMessage 通信；需用 transferable 实现零拷贝；SharedArrayBuffer 需跨域隔离策略和 Atomics 才能安全共享内存；Worker 应主动 close 而非依赖 terminate。
Web Workers 本质不是“多线程”，而是独立的 JS 执行上下文
JavaScript 主线程永远是单线程的，Web Workers 并没有打破这一点。它只是启动一个**与主线程完全隔离、无法共享内存**的新 JS 环境，靠 postMessage 和 onmessage 通信——这更接近“进程隔离”而非操作系统级线程。理解这点，才能避免踩坑：比如不能直接访问 document、window 或主线程的变量，也不能用 console.log（除非在 Worker 内部调用，且部分浏览器限制其输出位置）。
如何创建并正确通信：从 new Worker() 到 transferable
Worker 文件必须是同源的独立 JS 文件，不能是内联字符串或 blob URL（除非明确用 Blob + URL.createObjectURL，但兼容性需留意）。通信时默认序列化数据，大数组会严重拖慢性能：
- 传
ArrayBuffer或TypedArray时，用postMessage(data, [data.buffer])实现零拷贝转移（data在发送后变为空） - 不要传普通
Array或Object大数据，会触发深拷贝和 JSON 序列化，卡顿明显 - 主线程监听用
worker.onmessage = e => {...}，Worker 内用self.onmessage = e => {...}（不能用this）
SharedArrayBuffer 能否真共享内存？得配 Atomics 和跨域策略
现代浏览器中，SharedArrayBuffer 确实允许主线程与 Worker 共享同一块内存，但它不是“开箱即用”的：
- 必须开启跨域隔离（
crossorigin="anonymous"+ 响应头Cross-Origin-Embedder-Policy: require-corp和Cross-Origin-Opener-Policy: same-origin） - 读写必须用
Atomics.load()/Atomics.store()，裸读写会引发竞态，Atomics.wait()才能实现阻塞等待 - Chrome 92+ 默认禁用
SharedArrayBuffer（防幽灵漏洞），没配好策略会直接报SharedArrayBuffer is not defined
Worker 生命周期与错误处理：别让 terminate() 成为唯一出口
Worker 不会自动销毁，长期运行可能内存泄漏。常见误操作包括：
立即学习“Java免费学习笔记（深入）”；
- 在 Worker 内抛出未捕获异常，只会触发
onerror，不会终止 Worker，后续消息仍可接收 - 主线程调用
worker.terminate()后，Worker 立即停止，所有定时器、fetch、onmessage回调全丢弃——适合强制退出，但不适合优雅关闭 - 推荐模式：Worker 收到
{type: 'exit'}消息后，自行调用self.close()；主线程监听worker.onmessage确认后再释放引用
复杂点在于通信边界模糊时——比如计算中途被取消，Worker 里正在跑的 for 循环无法被中断，只能靠轮询 Atomics 标志位或拆成微任务分片执行。
