前两章里，服务器处理的要么是「消息」，要么是「一次性的指令」。第 3 章开始不一样了：服务器第一次持有一个会持续演进、且必须能被独立验证的对象——棋盘。井字棋只有 3×3，四子棋也不过 7×6，规则简单到可以手写判定函数，但正是这种简单，让「状态序列化」「合法性裁定」「回放一致性」这些真正棘手的问题暴露得清清楚楚。本章是后面所有棋类、战棋、乃至地图类原型的共同地基。
本章定位
- 难度梯度：进阶入门。规则依旧简单，但引入了空间状态与回放一致性两个重量级概念。
- 前置章节：第 1 章 聊天室 与 第 2 章 石头剪刀布 共同构成依赖，本章复用了前者的房间骨架与后者的回合锁步机制。
- 能力跃迁：从「裁定一次动作」跃迁到「维护并校验一个状态空间」。这是服务端权威从「裁决者」走向「世界持有者」的转折点。
- 阅读时长：单篇 PRD 约 450 行，建议重点读棋盘序列化格式与回放哈希校验两节。
核心验证目标
- 棋盘状态管理：可变网格的存储、序列化与传输，两种棋型共用一套 BoardEngine。
- 回合锁步：玩家轮流操作的顺序保证，非法轮次提交必须被服务端拒绝。
- 服务器权威判定：胜负判断与合法性校验全部在服务端完成，客户端只做展示与乐观预览。
- 快照与断线恢复：Snapshot 机制让重连玩家在不重放全部历史的前提下回到正确棋局。
- 只读观战通道：SpectatorService 提供延迟广播，防止观战者提前获知对局结果。
- 确定性回放：基于哈希一致性的 Deterministic Replay，验证「同一初始状态加同一操作序列必得同一终局」。
- 对局存档：ReplayLogger 落盘完整操作序列，为审计与复盘提供数据基础。
技术栈建议
- 语言：Go、Rust 或 TypeScript（Node）。Rust 在状态机与哈希校验上表达力更强，Go 则更适合与第 1、2 章的底座保持一致。
- 传输：WebSocket 加 JSON 消息流，本章不需要二进制帧。
- 存储：棋盘快照与操作日志分开存放，快照用于恢复、日志用于回放。
- 关键设计：BoardEngine 与 Validator 分离，把「规则」和「状态」拆开，这样第 17 章的战棋可以直接替换 Validator 而不动引擎。
本章文章
| 文章标题 | 核心内容 |
|---|---|
| 在线联机原型全集：第 3 章 井字棋 / 四子棋（Tic-Tac-Toe / Connect Four） | 完整 PRD：BoardEngine、Validator、ReplayLogger、SpectatorService 四模块设计，含两种棋型的规则定义与哈希一致性回放验证 |
本章只有一篇 PRD，未拆出独立的设计稿；状态空间的深入讨论（如 AOI 与分区）留到第 7 章的贪吃蛇大作战。
与相邻章节的关系
- 上一章：第 2 章 石头剪刀布 提供回合锁步与权威判定的模板，本章在其上加入空间状态。
- 下一章：第 4 章 快速问答抢答 从「状态空间」转向「时间仲裁」，开始处理毫秒级公平性问题。