web worker 无法访问 dom 是浏览器刻意设计的线程隔离机制，因 worker 运行在无 document/window 的 workerglobalscope 中，调用 document 会立即报 referenceerror；其根本目的是避免竞态条件、渲染不一致及安全模型破坏，确保主线程专注渲染、worker 专注计算。
Web Worker 无法直接访问 DOM，不是功能缺失，而是浏览器刻意设计的线程隔离机制——主线程专责渲染与交互，Worker 线程专注计算，二者物理隔离，避免竞争、保证一致。
根本原因：独立的全局执行环境
Worker 运行在 WorkerGlobalScope 中，而非 Window。这个环境里压根没有 document、window、Element、CSSStyleSheet 等 DOM 相关对象。调用 document.getElementById() 不会延迟报错，而是立刻抛出 ReferenceError: document is not defined。
- self 指向的是 Worker 自己的全局对象，和页面 window 完全无关
- 连
URL.createObjectURL()都不能用，得写成self.URL.createObjectURL() - 试图把页面初始化逻辑整个搬进 Worker，基本都会因访问 DOM 而崩溃
为什么必须这样隔离？
允许 Worker 直接操作 DOM 会引发严重问题：
- 竞态条件（Race Condition）：主线程正在重排重绘，Worker 同时修改同一个元素的 class 或 innerHTML，结果不可预测
- 渲染不一致：DOM 树状态可能在两线程间不同步，导致视觉错乱或布局抖动
- 内存与安全模型破坏：共享 DOM 对象需复杂引用计数和锁机制，违背轻量、确定性执行的设计初衷
哪些 API 受限？哪些还能用？
受限的主要是与渲染和用户界面强绑定的 API：
- ❌ 完全不可用：
document、window、localStorage（同步阻塞，不推荐）、alert、console.log（部分支持，但输出位置不同） - ✅ 可正常使用：
fetch、setTimeout、importScripts、postMessage、Atomics、IndexedDB（必须异步）、self.URL - ⚠️ 有条件可用：
OffscreenCanvas（需主线程移交）、SharedArrayBuffer（需服务端配置 CORP/COOP）
绕不开限制，但可以高效协作
真正的问题不是“怎么让 Worker 操作 DOM”，而是“如何让两者各司其职、低开销协同”：
- Worker 只负责纯计算：校验哈希、解码音视频、处理大数组、运行加密算法
- 主线程只负责呈现：收到结构化数据后，再执行
el.textContent = data.msg或progressBar.value = data.progress - 高频通信要节流或聚合，避免每毫秒发一次坐标拖慢主线程重绘
- 传大体积数据（如图像像素）优先用
transferable参数传递ArrayBuffer，避免拷贝
