Web Workers 不能操作 DOM 或访问 window/document，必须用独立 JS 文件加载，通过 postMessage 通信且仅传可序列化数据，传输大数组可用 Transferable，需手动 terminate 避免内存泄漏，小任务不建议使用。
Web Workers 不能直接操作 DOM，也不能访问 window、document 等全局对象——这是你写完代码却收不到响应、甚至报 ReferenceError: window is not defined 的根本原因。
Worker 文件必须是独立的 JS 脚本，且通过 URL 加载
浏览器强制要求 Worker 脚本需以单独文件形式存在（或用 Blob URL），不支持内联字符串或模块热加载。常见错误是试图这样写：
const worker = new Worker(`console.log('hello')`); // ❌ 报错：Failed to construct 'Worker': Script URL must be of scheme 'http' or 'https'正确做法是把逻辑拆到一个独立文件中，比如 worker.js，再用相对路径加载：
const worker= new Worker('./worker.js');
如果要用 ES 模块语法，得加 type: 'module' 参数：
const worker = new Worker('./worker.js', { type: 'module' });- 路径必须同源，跨域会触发 CORS 错误
- 开发时若用 Vite / Webpack，注意其对
new Worker()的特殊处理（如 Vite 需写成new Worker(new URL('./worker.js', import.meta.url), { type: 'module' })） - 不要在 Worker 文件里引入未声明的全局变量，比如
fetch可用，但localStorage不可用
postMessage() 是唯一通信方式，且只传可序列化数据
主线程和 Worker 之间不能共享内存，所有通信都靠 postMessage() + onmessage。你不能直接赋值、不能传函数、不能传 Promise 或 DOM 元素。
例如以下写法会静默失败（传过去的对象变成空 {}）：
// ❌ 主线程
worker.postMessage({ data: hugeArray, callback: () => {} });应该只传纯数据：
// ✅ 主线程
worker.postMessage({ type: 'PROCESS_DATA', payload: hugeArray.slice(0, 1000) });
// ✅ Worker 内
self.onmessage = ({ data }) => {
if (data.type === 'PROCESS_DATA') {
const result = data.payload.map(x => x * 2);
self.postMessage({ type: 'RESULT', payload: result });
}
};
- 传输大型数组时，考虑用
Transferable（如ArrayBuffer）避免拷贝开销：postMessage(msg, [buffer]) - 频繁通信可能成为瓶颈，建议批量处理、减少调用次数
- 别忘了监听
error事件，Worker 内未捕获的异常不会冒泡到主线程
终止 Worker 要主动调用 worker.terminate()，否则常驻内存
Worker 创建后会一直运行，直到显式终止或页面卸载。忘记调用 terminate() 容易导致内存泄漏，尤其在单页应用中反复创建 Worker 时。
典型场景：用户点击「开始计算」启一个 Worker，点击「取消」就该立刻停掉它：
let worker;
function start() {
worker = new Worker('./worker.js');
worker.onmessage = handleResult;
}
function cancel() {
if (worker) {
worker.terminate(); // ✅ 必须手动调用
worker = null;
}
}-
terminate()后 Worker 立即停止，不会再触发onmessage或onerror - Worker 内部无法自我终止（没有
self.close()的等价物），只能由主线程控制 - React/Vue 组件卸载时，务必在
useEffect或beforeUnmount中清理 Worker
最常被忽略的一点：Worker 不是万能加速器。小任务开 Worker 反而更慢（启动开销约 1–5ms），只有 CPU 密集型、持续 >50ms 的计算才值得用；另外，调试 Worker 的 console.log 输出在浏览器「Console」里默认不显示，得切到「Workers」标签页看。
