Web Workers 不能直接操作 DOM，因运行在独立上下文，无法访问 document、window 等主线程对象；只能通过 postMessage/onmessage 通信，数据经结构化克隆，支持普通对象、数组等，不支持函数、RegExp 等；Worker 必须从外部 JS 文件创建，路径需同源；可借助 SharedArrayBuffer+Atomics 实现共享内存，但需跨域隔离响应头；需注意生命周期管理，避免内存泄漏，建议显式调用 self.close()。
Web Workers 不能直接操作 DOM
这是最常踩的坑：Worker 线程运行在独立上下文中，document、window、localStorage 等主线程专属对象全部不可用。试图访问 document.getElementById 会直接报 ReferenceError: document is not defined。
只能通过 postMessage() 和 onmessage 与主线程通信，所有数据传递都经过结构化克隆（不支持函数、DOM 节点、RegExp 等）。
- 适合传：普通对象、数组、数字、字符串、
ArrayBuffer、TypedArray - 不适合传：
function、Date（会被转成字符串）、RegExp（变成空对象）、undefined（丢失）、循环引用（抛错）
如何正确创建和通信：主线程 + Worker 文件
Worker 必须从外部 JS 文件实例化，不能内联脚本。路径需符合同源策略，且不能是 data: 或 blob: URL（除非显式启用 allow-scripts 权限，但多数浏览器仍限制）。
主线程中：
立即学习“Java免费学习笔记（深入）”；
const worker = new Worker('path/to/worker.js');
worker.postMessage({ type: 'process', data: [1, 2, 3] });
worker.onmessage = function(e) {
console.log('收到结果:', e.data);
};
worker.onerror = function(e) {
console.error('Worker 执行出错:', e.message, e.filename, e.lineno);
};
对应的 worker.js 中：
self.onmessage = function(e) {
const { type, data } = e.data;
if (type === 'process') {
const result = data.map(x => x * 2);
self.postMessage({ result }); // 注意：用 self.postMessage，不是 postMessage
}
};
// 可选：监听主线程终止请求
self.onmessage = function(e) {
if (e.data.type === 'terminate') {
self.close(); // 主动退出
}
};
SharedArrayBuffer + Atomics 实现真正共享内存？小心跨域限制
默认情况下，Worker 之间、Worker 与主线程之间内存完全隔离。想实现低开销共享，需用 SharedArrayBuffer 配合 Atomics，但现代浏览器强制要求跨域隔离（Cross-Origin Isolation）：
- 页面必须设置响应头：
Cross-Origin-Embedder-Policy: require-corp和Cross-Origin-Opener-Policy: same-origin - 否则
new SharedArrayBuffer()抛TypeError: SharedArrayBuffer is not enabled -
Atomics.wait()在 Safari 中仍不支持，Firefox 需要手动开启javascript.options.shared_memory
简单计数器示例（仅 Chrome/Firefox 安全环境）：
// 主线程 const sab = new SharedArrayBuffer(8); const int32 = new Int32Array(sab); int32[0] = 0;const worker = new Worker('counter.js'); worker.postMessage({ sab });
// counter.js 中 self.onmessage = function(e) { const int32 = new Int32Array(e.data.sab); Atomics.add(int32, 0, 1); self.postMessage({ count: Atomics.load(int32, 0) }); };
Worker 的生命周期和资源管理容易被忽略
Worker 不会自动销毁，长期运行可能造成内存泄漏或 CPU 占用过高。尤其注意以下几点：
- 未移除的
setInterval或事件监听器（self.onmessage是全局的，不会随作用域释放） - 主线程调用
worker.terminate()后，Worker 内部代码立即停止，self.close()不再执行 - Worker 内部不能使用
alert()、confirm()，也不能发起fetch（除非在支持的环境下，且注意 CORS） - 调试困难：Chrome DevTools 的 Sources 面板需手动打开 “Workers” 标签页；Safari 对 Worker 断点支持较弱
复杂计算任务结束后，建议显式调用 self.close()，而不是依赖 GC。
