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”，但定位完全不同，混用会导致严重逻辑错乱。
立即学习“Java免费学习笔记（深入）”；
-
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 的才合适。边界模糊时，先测再拆。
