第四部 · 数据通道与序列化
这是第四部。原规划这一部排在第三部位置，2026-06 调整为先做完游戏循环再深挖通道。读者在做完闭环 2、看过游戏循环全貌后，回头来选数据通道时心里更有数。
权威拓扑确定后，下一步是把状态装进通道。VRChat 提供的同步原语并不少，挑哪一个、怎么打包，决定了带宽、延迟、调试成本和迟入恢复的难度。
这一部回答的核心问题
Section titled “这一部回答的核心问题”- 状态同步还是命令同步：回合制、解谜、轻实时各自适合哪种
- 版本号、序号与幂等：网络重复、乱序、迟到都可能出现
- 参数化 Network Event 与决策表
- 命令模式与事件日志（进阶）
- 字节打包与增量同步（进阶）
- JSON、
DataDictionary与DataList（进阶）
- 第二部第 12 章：请求式架构的
requestId/commandType/payload模板。 - 第三部第 16 章：开局是可重复执行的事务，需要版本号支撑。
- 第三部第 17 章：分数由谁有权加，决定了同步通道的选择。
- 闭环 2 留下的三个缺陷：重复点击重复加分；网络抖动后状态版本会乱；迟入玩家看到串味状态。这一部要用版本号和幂等修。
同步不是真相，是协议：写代码不是让所有人「看到真相」，是让所有人共同维护一份自洽的版本。
主线（19–21 章，必读）
Section titled “主线（19–21 章，必读）”- 第 19 章 · 状态同步还是命令同步（占位）
- 第 20 章 · 版本号、序号与幂等（占位）
- 第 21 章 · 参数化 Network Event 与决策表（占位，章末给一张通道决策表）
进阶（22–24 章，可跳过 difficulty: 4）
Section titled “进阶（22–24 章，可跳过 difficulty: 4）”章首会明示：读到这里可以先去第五部，做完闭环 4 之后再回来。
- 第 22 章 · 命令模式与事件日志（占位，含一篇翻译章：传统 netcode 的 Command Pattern → VRChat 落地）
- 第 23 章 · 字节打包与增量同步（占位）
- 第 24 章 · JSON、
DataDictionary与DataList（占位）
- 🧠 理解章 D · 选哪条通道（占位）
- ★ 闭环 3 · 加上命令版本号的工程化一局（占位）
修复闭环 2 的三个缺陷。本闭环之后玩法层面的能力已经够用，第八部再做完整项目。 - 📚 对照小练 C · 同一玩法两种通道（占位，用 JSON 同步整个棋盘 vs 用命令流同步）
章节正在筹备。