web worker 通信协议设计核心是明确“谁发什么、怎么发、收到后怎么认”，消息类型按动作意图命名（如 startprocessing），统一用 command/type 字段，禁用数字编码；负载结构依 worker 实际访问需求设计，含大量二进制数据时用 transferable；响应必须携带原始请求 id 以匹配任务；可选 meta 字段保留扩展性。
Web Worker 的通信协议设计核心在于明确“谁发什么、怎么发、收到后怎么认”，而不是堆砌功能或追求格式统一。消息类型和负载结构一旦定下来，主线程和 Worker 就能各司其职，不依赖共享状态，也不用猜测数据含义。
消息类型要按动作意图分类，不是按数据形态
类型名应反映操作目的，比如 startProcessing、updateConfig、fetchChunk、abortTask，而不是 object 或 array 这类描述性标签。这样 Worker 收到后可直接 switch 判断行为，避免运行时解析数据结构再决定逻辑。
- 类型字段建议统一用 command 或 type，避免混用 cmd / action / op
- 禁止用数字编码类型（如 1 表示开始，2 表示结束），后期维护成本高且易出错
- 可预留 ping 和 pong 类型用于心跳或连通性检测
负载结构需兼顾可读性与传输效率
payload 不是越扁平越好，也不是越嵌套越规范，关键看 Worker 是否需要立刻访问某字段。常用组合包括：
- 基础任务指令：{ command: 'process', id: 'task-123', data: [1,2,3] }
- 带元信息的批量操作：{ command: 'import', batchId: 'batch-456', total: 1000, offset: 200, chunk: Uint8Array }
- 配置更新：{ command: 'configure', settings: { timeout: 5000, retries: 3 } }
注意：若 payload 含大量二进制数据（如图像帧、音频缓冲区），优先使用 transferable 方式传递，避免序列化拷贝开销。
响应消息必须携带原始请求标识
Worker 返回结果时，不能只回 { status: 'done', result: … }，而应附带发起方能识别的上下文，例如 id 或 requestId。否则主线程无法将响应匹配到对应任务，尤其在并发多任务场景下极易错乱。
- 推荐模式：主线程发 { command: 'analyze', id: 'req-789', data: … } → Worker 回 { type: 'result', id: 'req-789', data: … }
- 错误响应也需一致：{ type: 'error', id: 'req-789', code: 'TIMEOUT', message: '…' }
- 避免用时间戳或随机字符串代替 id，它们不具备业务语义，调试困难
保留扩展字段，但不预设用途
在消息对象中留一个可选字段如 meta 或 ext，类型为 object，供未来添加调试标记、来源标识、版本提示等，但不强制要求每次填充。这样既保持协议向前兼容，又不增加日常使用的负担。
- 例如：{ command: 'render', sceneId: 's-01', meta: { from: 'editor', debug: true } }
- Worker 可忽略 meta，也可根据其中字段开启日志或跳过某些校验
- 主线程不应依赖 meta 中的内容做核心逻辑判断
