WebWorker 不能直接使用 WebSocket，因其依赖主线程 DOM 环境和事件循环，而 Worker 运行在隔离上下文中；替代方案是主线程管理 WebSocket 连接，Worker 负责消息解析与计算，并通过 postMessage 协作。
在 HTML5 中，WebWorker 本身不能直接创建或使用 WebSocket 实例——这是浏览器的明确限制。虽然 Worker 线程支持网络请求（如 fetch、XMLHttpRequest），但截至 2026 年主流浏览器（Chrome、Firefox、Edge、Safari）仍不支持在 Worker 内部 new WebSocket()，尝试调用会抛出 DOMException 或直接失败。
为什么 Worker 里不能用 WebSocket？
WebSocket API 依赖于主线程的 DOM 环境和事件循环机制，而 WebWorker 运行在隔离的上下文中：它没有 window、document，也不具备 WebSocket 所需的底层连接管理能力。规范上，WebSocket 被定义为“仅限 Window 或 DedicatedWorker 的子集”，但实际实现中，所有主流浏览器都只允许其在主线程中初始化。
可行的替代方案
若需在后台线程中处理实时消息逻辑，可采用以下组合方式：
-
主线程负责 WebSocket 连接与收发：建立 ws 连接、监听
onmessage、调用send()，全部放在主线程完成 -
Worker 负责解析、计算、缓存等耗时操作：主线程收到原始消息后，用
postMessage()将数据（如 JSON 字符串或 ArrayBuffer）传给 Worker；Worker 处理完再发回结果 -
用 SharedArrayBuffer + Atomics（高级场景）：若需高频低延迟同步（如游戏帧同步），可在主线程与 Worker 间共享内存，但需配合
Atomics.wait()等机制，且要求 HTTPS 环境和跨域许可
典型协作流程示例
假设接收服务器推送的实时日志流：
- 主线程：
const ws = new WebSocket("wss://api.example.com/logs") - 主线程
ws.onmessage = e => worker.postMessage(e.data) - Worker（worker.js）：
self.onmessage = e => { const parsed = JSON.parse(e.data); const filtered = parseAndFilterLogs(parsed); self.postMessage({ result: filtered }); } - 主线程监听 Worker 返回并更新 UI，完全不阻塞渲染
注意事项
不要尝试在 Worker 中 importScripts 加载 socket.io-client 等库——它们内部仍依赖 WebSocket 构造函数，同样会失败。也不要依赖“某些旧版 Chrome 曾短暂支持”的传闻，当前稳定版均不兼容。真正需要 Worker 内全双工通信的场景，目前只能转向 fetch + Server-Sent Events (SSE)（Worker 支持 EventSource），但 SSE 是单向（服务端→客户端），无法主动发送。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
