Worker 是浏览器多线程机制而非多进程模型，运行在独立线程中，不可直接操作 WebSocket 或 DOM；其职责是接收主线程转发的已解析行为数据，执行碰撞检测、路径寻路等 CPU 密集计算，并通过可序列化消息与主线程协同维护游戏状态。
Worker 本身不是“多进程模型”，而是浏览器提供的多线程机制——每个 Worker 运行在独立的 JavaScript 线程中，与主线程隔离。WebSockets 是主线程（或 Service Worker）建立和维护的通信通道，Worker 无法直接创建或持有 WebSocket 实例（因不支持 WebSocket 构造函数，也无法访问 document 或 window）。因此，“利用 Worker 多进程模型动态保持行为上下文”需明确边界：Worker 不接管连接，但可分担与连接强相关、计算密集、状态独立的逻辑。
明确职责边界：谁管连接，谁管状态
WebSocket 连接必须由主线程（或 Service Worker）维持——它负责握手、心跳、收发原始字节/JSON、错误重连。Worker 的角色是：接收主线程转发的、已解析的游戏行为数据，执行耗时计算，再将结果返回。例如：
- 主线程收到
{"type":"move","playerId":"A","x":120,"y":85}→ 校验合法性后，postMessage给 Worker - Worker 内运行碰撞检测、路径寻路、物理积分等 —— 这些不依赖 DOM，但 CPU 密集
- Worker 计算出新位置与影响（如触发区域事件），
postMessage回主线程 → 主线程广播给其他玩家
设计可序列化的行为上下文结构
Worker 与主线程之间只能传递可序列化的数据（JSON 兼容值），不能传函数、DOM 节点或 WebSocket 实例。因此，“行为上下文”必须显式建模为纯数据对象：
Javascript Sdk
下载
用于 inference.sh 的 JavaScript/TypeScript SDK，可运行 AI 应用、构建代理、集成 150+ 模型。包名：@inferencesh/sdk（npm install），完整 TypeScript 支持。
- 定义统一上下文格式，例如：
{ gameId: "room-101", tick: 1245, players: [...], worldState: {...} } - 主线程定期（如每帧或每 50ms）将当前精简快照 + 待处理指令打包发送给 Worker
- Worker 不保存长期状态，每次计算基于输入快照；若需状态延续（如 AI 决策记忆），可将上一轮输出的
context.metadata一并传入下一轮
用消息通道模拟“上下文生命周期”
Worker 没有“连接生命周期”概念，但可通过约定消息协议模拟：
-
初始化：主线程首次
postMessage({ cmd: "init", config: {...} })，Worker 加载规则、预编译函数、缓存静态地图数据 -
运行期：持续接收
{ cmd: "step", context: {...}, actions: [...] }，返回{ nextContext: {...}, events: [...] } - 重同步：主线程检测到网络抖动或状态偏差，主动推送完整快照（而非增量），Worker 丢弃旧中间态，从新快照重启计算
-
销毁：游戏房间关闭时，主线程调用
worker.terminate()，Worker 自身无需清理 DOM，但可释放 TypedArray 缓冲区
规避常见陷阱
实际落地时容易忽略的关键细节：
- 不要在 Worker 中尝试
importScripts("socket.io-client.js")—— 它依赖XMLHttpRequest和document，必然失败 - 避免高频小消息：把 10 次移动指令合并为一批发送，比每帧都
postMessage更高效（减少序列化/反序列化开销） - 时间敏感逻辑（如帧同步）需主线程提供精确时间戳（
performance.now()），Worker 不能依赖自己的Date.now()做同步判断 - 若使用 SharedArrayBuffer 提升性能（需跨域 HTTPS + COOP/COEP 头），仅限 Chrome/Firefox，且需主线程与 Worker 同步构造，不适用于所有小游戏场景
