Web Workers 是浏览器唯一原生多线程方案，通过独立线程执行纯计算任务解耦主线程，依赖 postMessage 通信与结构化克隆传递数据，需注意路径、模块、错误处理及逻辑拆分原则。
主线程卡死时，Web Workers 是唯一能真正解耦计算的方案
UI 冻结不是“慢”，而是 JavaScript 单线程被长时间占用导致渲染帧丢弃。Web Workers 是浏览器提供的唯一原生机制，能在独立线程执行 JS 逻辑，不抢占主线程事件循环。它不能操作 DOM、不能访问 window 或 document，但能处理纯计算、数据解析、加密、图像处理等任务——只要逻辑可序列化、无副作用依赖。
postMessage() 是唯一通信方式，别试图共享变量或引用
Worker 和主线程之间没有共享内存，所有数据都通过结构化克隆（structured clone）复制传递。这意味着：
-
postMessage()发送的对象会被深拷贝，function、undefined、Symbol、Promise、RegExp等无法传递，会静默丢弃 - 大数组或嵌套对象会触发明显序列化开销，频繁传 10MB+ 数据反而比不移出主线程更卡
- 想传 ArrayBuffer 避免拷贝？必须用
postMessage(data, [transferList])显式转移所有权，例如postMessage(buffer, [buffer])，之后主线程该 buffer 就变null - Worker 内不能直接调用主线程函数，必须靠
onmessage回调 +postMessage()响应，形成请求-响应闭环
初始化 Worker 的路径和作用域容易踩坑
Worker 构造函数只接受一个 URL 参数，且必须是同源脚本路径：
- 用相对路径如
new Worker('./math-worker.js')时，路径相对于当前 HTML 页面 URL，不是相对于当前 JS 文件位置 - Vite/webpack 等构建工具下，Worker 文件需显式声明为模块（
new Worker('./worker.js', { type: 'module' })），否则无法 import；同时要确保构建配置允许 worker 入口（Vite 中默认支持，Webpack 需worker-loader或asset/resource） - 不能在内联脚本中定义 Worker 逻辑，
new Worker('data:text/javascript,...')在多数浏览器被禁用（CSP 或安全策略限制） - Worker 内部的
importScripts()只支持绝对或相对 URL，不走打包器 resolve，建议统一用 ES 模块import配合构建工具处理
错误不会自动冒泡到主线程，必须手动监听 onerror
Worker 内抛出未捕获异常，只会触发自身 onerror，主线程完全无感知。常见后果是：计算无声失败、UI 一直转圈、onmessage 永远不触发。
- 务必在 Worker 脚本顶部加
self.onerror = (e) => self.postMessage({ type: 'error', error: e.message }); - 主线程创建 Worker 后立即绑定
worker.onerror = (e) => console.error('Worker init failed:', e.message);，捕获初始化阶段错误（如 404、语法错误） - 避免在 Worker 中使用
try/catch吞掉所有错误却不通知主线程——尤其在循环或递归计算中 - 调试时打开 DevTools 的 “Application → Service Workers” 或 “Sources → Workers” 面板，才能看到 Worker 独立的 console 输出和断点
Worker 的价值不在“多线程”这个概念，而在强制你把计算逻辑拆成输入确定、输出纯净、无外部状态依赖的函数。很多卡顿问题，其实改两行代码就能解决：把 for 循环里塞的 DOM 更新挪出去，把 JSON.parse() 后立刻渲染改成先 postMessage 给 Worker 做字段校验和转换。真正的难点从来不是 API 怎么写，而是识别哪些逻辑真的适合移出——比如你正在做 canvas 像素级滤镜，却试图把 requestAnimationFrame 也塞进 Worker，那就走偏了。
