17370845950

Web Workers 是浏览器提供的后台线程机制，用于在独立线程中运行脚本以避免阻塞主线程；它不改变 JavaScript 单线程本质，不可访问 DOM，仅通过 postMessage 通信，适用于 CPU 密集型任务。

JavaScript 本身是单线程的，Web Workers 不是让 JS 变成多线程语言，而是提供一种**在后台线程运行脚本**的机制，避免阻塞主线程 —— 这是它唯一且核心的作用。

Web Workers 为什么不能直接访问 DOM

因为 DOM 操作必须由主线程控制，这是浏览器的安全与渲染模型决定的。Worker 线程里访问 document、window 或 alert() 都会直接报错：ReferenceError: document is not defined。

• Worker 中可用的全局对象只有 self、console、fetch、setTimeout 等有限 API
• 所有数据通信必须通过 postMessage() 和 onmessage，且传参会被序列化（结构化克隆），函数、DOM 节点、undefined 等无法传递
• 如果需要更新界面，Worker 处理完结果后，必须把数据发回主线程，由主线程操作 DOM

如何正确创建和使用 Dedicated Worker

最常用的是专用 Worker（DedicatedWorker），一个 Worker 实例只对应一个主线程。

• Worker 脚本必须放在独立的 .js 文件中（如 worker.js），不能是内联字符串或 Blob URL（部分旧环境不支持）
• 主线程中用 new Worker('./worker.js') 创建，路径需符合同源策略
• 通信靠消息：主线程用 worker.postMessage(data) 发送，Worker 用 self.onmessage = e => { ... } 接收；反之亦然
• 别忘了错误监听：worker.onerror 或 worker.addEventListener('error', ...)，否则 Worker 内部抛错会静默失败

SharedWorker 和 ServiceWorker 的关键区别

它们名字都带 “Worker”，但定位完全不同，混用会导致严重逻辑错乱。

• SharedWorker 可被**同源多个页面/iframe 共享**，适合跨 tab 协作场景（如实时同步状态），但调试困难，兼容性略差（Safari 曾长期不支持 port.start()）
• ServiceWorker 是网络代理层，主要做离线缓存、推送、后台同步，**生命周期独立于页面**，必须 HTTPS（localhost 除外），注册后需手动激活、跳过等待等步骤，和计算密集型任务无关
• 三者不能互相替代：CPU 密集任务选 Worker，跨页通信考虑 SharedWorker，网络拦截/离线能力用 ServiceWorker

Worker 中处理大数组或 JSON 解析的典型陷阱

很多人以为把 JSON.parse(bigString) 或循环 10 万次塞进 Worker 就万事大吉，其实不然。

• 传入数据过大时，postMessage() 序列化/反序列化本身就有

  

  开销，可能比计算还慢；可改用 Transferable（如 ArrayBuffer）零拷贝传递
• Worker 初始化也有成本（JS 解析、作用域建立），频繁创建销毁 Worker 反而更卡；应复用实例，或用 Worker Pool 管理
• Chrome DevTools 的 Performance 面板里，Worker 线程是独立的 timeline，但默认不显示 —— 需右键 timeline → “Show all threads” 才能看到真实耗时分布

真正难的不是写几行 postMessage，而是判断「这个任务到底值不值得扔进 Worker」：IO 类（如 fetch）、短平快计算（50ms 的才合适。边界模糊时，先测再拆。