web worker 无法访问 dom 是设计使然，应通过 postmessage 协作：worker 专注计算并传递结构化数据，主线程负责 dom 更新；状态抽象为纯数据模型；图形任务用 offscreencanvas；多模块响应用 customevent 解耦。
Web Worker 无法访问 DOM 不是 bug，而是设计使然——它保障主线程不被阻塞。解决思路不是强行突破限制，而是调整协作方式：让 Worker 专注计算，把 DOM 操作交还主线程，靠清晰的消息约定协同工作。
用 postMessage 传递结构化数据
Worker 和主线程之间只能通过 postMessage 通信，且传输内容必须能被结构化克隆（structured clone）。这意味着：
- 可传：普通对象、数组、字符串、数字、Boolean、Date、RegExp（部分浏览器）、ArrayBuffer（配合
transfer参数更高效） - 不可传：DOM 节点、函数、
window或document引用、Promise、Error 对象 - Worker 中写
document.getElementById会直接报ReferenceError: document is not defined - 主线程收到消息后，自己执行 DOM 更新，例如：
el.innerHTML = data.html或btn.classList.toggle('loading', data.isLoading)
把 UI 状态抽象成纯数据模型
不要让 Worker “知道”页面长什么样，而是定义一套轻量、可序列化的状态契约：
- 比如上传任务，Worker 只返回：
{ id: 'upload-2026', status: 'progress', progress: 73 } - 主线程根据
id找到对应 DOM 元素，更新进度条、文字提示或 class - 错误、完成、取消等状态也统一走字段标识（如
status: 'error'），不依赖 Worker 修改 classList 或 innerText - 避免在 Worker 里拼 HTML 字符串或构造 DOM 片段——那属于主线程职责
高频图形操作可用 OffscreenCanvas
Canvas 是少数需要绕过 DOM 限制的典型场景。OffscreenCanvas 提供了 Worker 可用的替代方案：
- 主线程创建
OffscreenCanvas，调用transferToImageBitmap()或直接postMessage(canvas, [canvas])将控制权移交 Worker - Worker 中可调用
canvas.getContext('2d')绘图，不卡主线程 - 绘制完成后，Worker 把图像数据（如 ImageBitmap）传回主线程，由主线程贴到
<canvas></canvas>或<img>上 - 适用于实时滤镜、粒子动画、游戏帧渲染等对性能敏感的图形任务
用 CustomEvent 解耦多模块响应
当多个业务逻辑需响应 Worker 结果时，避免在主线程硬编码一堆 worker.onmessage 处理器：
- 主线程收到消息后，统一派发自定义事件：
dispatchEvent(new CustomEvent('task:done', { detail: data })) - UI 渲染模块、日志模块、动画控制器各自监听该事件，互不影响
- 配合
AbortController，主线程还能主动向 Worker 发送取消信号，Worker 收到后中断循环并退出 - 这种模式让通信更松散、可测试、易扩展
