Worker实现代理行为上下文持续性的关键是主线程与Worker间有意识地传递、重建和同步JSON可序列化的上下文数据，而非依赖多进程状态维持。
小游戏里用 Worker 实现“代理行为上下文”的持续性，关键不是靠多进程维持状态，而是靠主线程与 Worker 之间有意识地传递、重建和同步上下文数据。Worker 本身无状态、不共享内存、不能存全局变量，所谓“动态保持”，本质是设计一套轻量、可序列化、按需同步的上下文管理机制。
明确 Worker 的上下文边界
Worker 是隔离线程，没有 window、document、wx API，也不能直接访问 game.js 中的对象。它只认 JSON 可序列化的数据——这意味着所有需要“保持”的上下文（比如用户操作序列、AI 决策缓存、路径计算中间值）必须显式传入、显式返回，不能依赖隐式引用或闭包变量。
- 避免在 Worker 内部维护长期状态（如全局数组或计时器），容易因重复创建/销毁丢失
- 把“上下文”定义为结构化数据对象：例如
{ playerId: 'u123', stepHistory: [...], lastActionTime: 1718534200 } - 每次调用前，主线程将当前上下文作为参数传入；Worker 处理后，连同新状态一起返回
用 postMessage 实现上下文接力
主线程每次向 Worker 发送任务时，都附带当前最新上下文；Worker 完成计算后，把更新后的上下文 + 结果一并回传。这样形成一条清晰的数据链路，不依赖 Worker 生命周期。
- 主线程发送示例：
worker.postMessage({ type: 'pathfind', data: { from: [0,0], to: [5,3] }, context: currentCtx }) - Worker 接收后解析 context，执行逻辑，再返回：
worker.postMessage({ result: path, context: updatedCtx, timestamp: Date.now() }) - 主线程收到后立即更新本地
currentCtx，供下一次调用使用
结合分包与预加载提升上下文连续性
如果 Worker 代码被打包为分包（"isSubpackage": true），首次初始化前需调用 wx.preDownloadSubpackage。这个过程虽不直接影响上下文，但能避免因下载延迟导致主线程等待、上下文过期或任务堆积。
- 在游戏启动阶段或角色加载时提前下载 Worker 分包，确保后续调用零延迟
- 下载成功后再创建 Worker，并同步传入初始上下文（如玩家配置、关卡ID等）
- 若 Worker 需要终止重开（如切换场景），先保存当前 context 到主线程变量，再重建 Worker 并传入
规避常见断点：超时、销毁与并发冲突
Worker 最大并发数为 1，且 terminate() 后状态清空。动态保持上下文的前提，是避免无谓的销毁与重建。
- 不要频繁
worker.terminate()+wx.createWorker()，除非业务逻辑明确需要重置环境 - 对长时任务（如寻路+动画预演），用单次 postMessage 触发完整流程，而非拆成多次通信
- 主线程中用防抖或队列控制发送频率，防止 Worker 消息积压导致 context 错位（比如第3次请求覆盖了第2次的上下文）
