Web Worker 无法访问 DOM 是浏览器的规范级安全限制，因其运行在独立线程，而 DOM 非线程安全；Worker 全局对象为 self，document 等 API 均未定义；应通过 postMessage、Transferable、OffscreenCanvas 和 fetch 实现合理分工。
因为 Web Worker 运行在完全独立的线程和全局上下文中，浏览器从设计上就禁止它接触 DOM 和 window。
线程隔离是硬性安全机制
主线程负责渲染、响应用户输入、管理 DOM，这些操作必须是单线程且可预测的。如果 Worker 能直接修改 DOM，就可能出现两个线程同时操作同一个元素——比如一个在删节点，另一个在读 innerHTML，结果不可控，还可能引发崩溃或数据错乱。浏览器用隔离来杜绝这种风险。
- Worker 的全局对象是
self（即WorkerGlobalScope），不是window -
document、localStorage、location、history等全部未定义 - 访问
document.getElementById会立刻抛出ReferenceError: document is not defined
DOM 本身不是线程安全的
DOM API 的实现依赖大量内部状态和引用计数，没有加锁机制去支持并发读写。即便技术上能“暴露”给 Worker，也无法保证行为一致或性能可控。所以浏览器不提供接口，也不打算支持。
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 不是兼容性问题，也不是配置错误，而是规范级限制
- 所有主流浏览器（Chrome、Firefox、Safari、Edge）都严格遵守这一规则
- 连
console.dir(document)都会报错，不只是操作失败
可用的替代路径很明确
Worker 不需要 DOM，它该做的事是计算、解析、编码、加密、AI 推理等纯逻辑任务；UI 更新交给主线程更合理、更高效。
- 用
postMessage发送结构化数据（如{ type: 'progress', value: 65 }） - 大数据用
Transferable（如ArrayBuffer）避免拷贝开销 - 图形类任务用
OffscreenCanvas，它专为 Worker 设计，能获取 2D 或 WebGL 上下文 - 网络请求可用
fetch（Worker 中原生支持，无需window.fetch）
这种分工不是妥协，而是现代 Web 多线程的正确打开方式：算得快，画得稳，互不干扰。
