Worker是浏览器多线程机制而非多进程模型，仅能通过postMessage进行消息传递，适合纯计算任务如客户端预测校验、粒子更新等，所有I/O、渲染、WebSocket操作必须由主线程完成。
Worker 本身不是“多进程模型”，而是浏览器提供的多线程机制；它不能直接管理 WebSocket 连接，也不能替代服务端的玩家状态同步逻辑。在 WebSocket 多玩家游戏中，Worker 的合理定位是主线程的计算卸载单元，而非行为上下文的管理者。
明确 Worker 的能力边界
Worker 运行在独立线程，无 DOM、无 window、无法创建 WebSocket 实例或监听网络事件。它不能：
- 主动连接或维护 WebSocket 链接
- 读取或修改 canvas 渲染状态
- 访问 localStorage / IndexedDB（除非显式使用专用 API）
- 共享变量或直接调用主线程函数
它的唯一合法交互方式是 消息传递（postMessage / onmessage），数据被结构化克隆，不共享内存。
适合交给 Worker 的游戏上下文任务
真正能提升帧率、缓解主线程压力的，是那些纯计算、无 I/O、无副作用的上下文处理环节：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 客户端预测校验：对本地输入生成的移动轨迹，用物理引擎复现并预判是否与服务端后续广播一致
- 弹幕/特效粒子系统更新：每帧更新数百个弹幕位置、透明度、碰撞检测（不涉及渲染）
- 音频事件调度预计算：根据玩家位置和事件触发条件，提前算出应播放哪段音效及参数
- 局部 AI 行为推演：非关键 NPC 的寻路路径缓存、状态机过渡条件批量判定（不依赖实时画面）
保持行为上下文的关键不在 Worker，而在主线程设计
所谓“行为上下文体系”，本质是游戏状态的一致性表达，需由主线程统一维护。Worker 只能辅助其中一部分计算：
- 主线程负责维护
playerState、worldTime、inputBuffer等核心上下文对象 - Worker 接收序列化的快照（如 {time, players, inputs}），执行只读计算，返回结果（如 {valid: true, predictedX: 124.7}）
- 主线程将 Worker 返回值融合进当前帧逻辑，决定是否回滚、插值或接受预测
- 所有 WebSocket 收发、canvas 渲染、音频播放、用户输入监听，必须在主线程完成
动态通信模式建议
避免高频小消息阻塞通信通道。推荐按需、批量化、带版本号传输：
- 主线程每 3–5 帧向 Worker 发送一次「上下文快照」，附带
frameId - Worker 完成后返回
{frameId, result}，主线程比对 ID 再应用，丢弃过期结果 - 对耗时波动大的任务（如路径重规划），Worker 可分阶段 postMessage 进度，主线程 UI 可显示“计算中…”
- 不使用
onmessage = function(){...}，改用addEventListener('message', handler)，便于解绑
不需要“动态创建多个 Worker”——一个 dedicated Worker 足以覆盖上述场景；频繁启停反而增加开销。
