第 8 章的玩家各自守着一份秘密，第 9 章反过来：所有玩家共享同一个世界，谁都可能在同一毫秒点击同一个格子。这看起来只是「多人点同一张图」，但它把分布式系统里最经典的难题直接搬进了游戏——并发写入、幂等性、版本冲突、超时裁定。协作扫雷的失败条件也很有意思：任何人踩雷，全体失败。这让冲突解决的正确性直接等价于游戏体验，而不是一个可以事后补偿的后台问题。
本章定位
- 难度梯度：进阶。玩法门槛低，但并发正确性是全书中较易出错的一环。
- 前置章节：第 8 章 战舰 / UNO 简版 提供房间与快照基础，第 5 章 你画我猜 提供 CRDT 合并层的复用经验。
- 能力跃迁：从「视角裁剪」跃迁到「共享写入仲裁」。服务器第一次成为并发冲突的仲裁者而非仅仅是真相持有者。
- 阅读时长：单篇 PRD 约 480 行，建议重点读乐观锁与版本号、幂等操作 ID、限时裁定三节。
核心验证目标
- 并发操作控制：多人同时点击同一格时的乐观锁与版本号机制，保证「先到先得」而非「双写双翻」。
- 幂等性保障：重复提交不重复执行，每个操作携带唯一 ID，重试安全。
- 冲突合并：多人修改同一资源时的 ETag 或 CRDT 式合并策略，翻格与标雷需区别对待。
- 全局状态快照：以 Redis 保存棋盘快照，支持快速恢复与多实例共享。
- 限时机制：三分钟倒计时的定时器与超时仲裁，超时即判负。
- 审计日志：操作按时间序列记录，支持事后回放与责任追溯。
- 协作胜负判定：踩雷全体失败、翻完所有非雷格全体胜利，胜负判定必须在并发环境下保持唯一。
技术栈建议
- 语言：Go、Rust、Elixir 或 TypeScript。Elixir 的进程模型对共享状态串行化有天然优势。
- 传输：WebSocket 加 HTTP（用于 ETag 版本控制）。
- 存储：Redis 承担棋盘快照与版本号，操作日志落持久化存储。
- 关键设计：GridEngine 负责状态、ConflictResolver 负责仲裁，两者分离；仲裁层是本章最值得单独测试的部分。
本章文章
| 文章标题 | 核心内容 |
|---|---|
| 在线联机原型全集：第 9 章 协作扫雷 / 限时合作解谜（Cooperative Minesweeper） | 完整 PRD：GridEngine、ConflictResolver、TimerScheduler、AuditLogger 四模块设计，含乐观锁、幂等 ID 与限时裁定流程 |
本章只有一篇 PRD；共享状态的事务模型在第 10 章的城格建造 mini-SLG 中会被进一步放大到经济结算层面。
与相邻章节的关系
- 上一章：第 8 章 战舰 / UNO 简版 处理信息隔离，本章处理信息共享下的冲突。
- 下一章：第 10 章 城格建造 mini-SLG 把同步协作扩展为异步回合与经济循环，开始引入任务调度与持久化。