创作者视角 4 · 同步不是真相，是协议
这一篇写在第四部之前。
VRChat 的网络层乍看像「让所有人看到同一件事的真相」。技术上确实是：所有客户端最后会拿到同一份同步变量值。
往上抬一层：这份值不是真相，是协议。
考虑「这场比赛分数 7 比 5」。这个数字之所以是 7 比 5，不是因为宇宙记录了 7 比 5，是因为：
- 玩家做了一些动作（按按钮、击中目标、过桥）
- 这些动作被某个 Owner 接收并裁决
- 裁决的结果被同步到所有客户端
- 所有客户端共同接受这个结果
这是一个协议：所有玩家共同同意「我们在玩同一局」。协议的稳健性来自版本号、命令幂等、迟入恢复机制。第四部讲的所有技术（requestId、stateVersion、JSON 序列化、参数化事件）都是为了让这个协议在网络抖动、迟入、Owner 切换的情况下保持自洽。
设计协议时有几个原则：
- 谁有权改：协议要明示。同一个状态不能两个客户端都觉得自己有权写。
- 怎么处理冲突：两个玩家同时按按钮，谁的请求被接受？协议要有裁决规则，不能依赖随机。
- 怎么处理迟到：A 客户端三秒前发的请求刚到，现在比赛已经结束了，怎么办？协议要明示「过期请求」的处理。
第四部教读者写这种协议。协议视角先在这里立起来：写代码不是让所有人「看到真相」，是让所有人共同维护一份自洽的版本。