Web Workers 是浏览器提供的隔离式后台线程机制，非 JS 多线程；必须用独立同源 JS 文件创建，通过 postMessage 传递数据（结构化克隆），大数组用 Transferable 零拷贝；Worker 内无 DOM、无 localStorage；需显式 terminate() 或 self.close() 防内存泄漏。
Web Workers 不是 JavaScript 的“多线程”（因为 JS 本身仍单线程），而是浏览器提供的隔离式后台线程机制——它让你能把 CPU 密集型任务搬出主线程，避免页面卡死。
new Worker('worker.js') 是唯一可靠启动方式
你不能用字符串、内联函数或 data: URL 创建 Worker（Chrome/Firefox 会直接抛 SecurityError: Failed to construct 'Worker'）。必须把逻辑写进独立的 .js 文件，并确保同源（file:// 协议下多数浏览器拒绝加载）。
- ✅ 正确：
const worker = new Worker('./math-worker.js'); - ❌ 错误：
new Worker('data:text/javascript, self.postMessage(42)');或new Worker(`self.onmessage=...`) - ⚠️ 构建工具友好写法（Vite/Webpack）：
new Worker(new URL('./math-worker.js', import.meta.url))，支持模块导入
postMessage 传参不等于“共享内存”，结构化克隆很关键
主线程和 Worker 之间所有数据都走 postMessage()，但默认不是引用传递，而是用结构化克隆算法（structured clone）深拷贝。这意味着：
- 传
{a: 1, fn: () => {}}→fn字段直接消失（函数不可克隆） - 传
document.body→ 立即报错ReferenceError: document is not defined（Worker 没 DOM） - 传百万级
ArrayBuffer→ 内存翻倍 + 序列化延迟，UI 可能卡顿
大二进制数据请用 Transferable 零拷贝：
const buffer = new ArrayBuffer(10 * 1024 * 1024); // 10MB worker.postMessage(buffer, [buffer]); // 第二个参数移交所有权
移交后，主线程的 buffer 变成 detached，再读会抛 TypeError: array buffer is detached。
Worker 里能用什么？不能用什么？边界必须清楚
Worker 有自己独立的全局对象 self（类似主线程的 window），但 API 集大幅裁剪：
- ✅ 可用：
console（输出在 DevTools → “Workers” 标签页）、fetch、setTimeout、WebAssembly、indexedDB - ❌ 不可用：
document、window、localStorage、XMLHttpRequest（改用fetch）、alert、parent - ⚠️ 注意：
console.log能用，但容易被忽略——别靠它调试，加onerror监听更靠谱
常见错误：在 worker.js 里写 document.getElementById()，运行即崩，报 ReferenceError: document is not defined，这不是 bug，是设计如此。
别忘了 terminate()，否则线程常驻内存
Worker 实例不会自动销毁。哪怕任务做完、onmessage 处理完，线程仍在后台运行，持续占用内存和 CPU 资源。
- ✅ 显式终止：
wor（主线程调用）
ker.terminate();
- ✅ Worker 自毁：
self.close();（Worker 内部调用） - ⚠️ 忘记终止 → 多个 Worker 积累后，页面内存飙升，Chrome 任务管理器里能看到 “Worker” 进程持续存在
尤其在动态创建 Worker 的场景（如用户反复点击“开始计算”），不 terminate() 就等于内存泄漏。
实际用起来最易忽略的，是 transferable 的移交时机和 detached buffer 的二次读取；还有就是以为 console.log 能像主线程一样随时看到输出——它藏在 Workers 标签页里，很多人压根没打开过。
