第 26 章把第 17 章的锁步压缩到同一逻辑帧内。战棋的锁步以「回合」为单位，玩家有充分时间规划；合作解谜的锁步以「帧」为单位，两个玩家必须几乎同时按下按钮才能触发机关。这带来一个全新的问题：网络抖动让「同时」不可能绝对精确，于是必须引入时间窗——在窗口内到达的输入视为同一逻辑帧。窗口宽了作弊空间大，窄了玩家体验差，这个权衡是本章的技术核心。
本章定位
- 全集位置：第 26 章，属「同步协作」层，是锁步一致性在帧粒度上的应用。
- 难度梯度：进阶。玩法设计难度高（谜题类型决定同步要素），工程难度中等。
- 前置章节：第 1 章聊天室（连接与房间基元）、第 15 章微型赛车系统（回滚与插值）、第 17 章战棋对战（锁步与命令冻结）。
- 后续衔接：第 27 章协作建造系统把「同步操作」升级为「并发编辑世界」，引入区域锁与 CRDT。
核心验证目标
- 锁步状态：所有客户端在每一逻辑帧对谜题状态保持完全一致，房间服务器汇总输入后统一广播。
- 时间窗判定：以滑动时间窗吸纳输入到达抖动，窗口内的输入归入同一帧，窗口外的输入按规则丢弃或顺延。
- 冲突协调：当并发输入指向互斥状态时，由冲突解决器按规则裁定，避免不同客户端得出不同结论。
- 状态重播与回滚：客户端断线重连后凭状态存储与回放日志恢复，必要时回滚到最近一致帧再重放。
- 五级谜题模型：同步触发、序列协作、状态解锁、多线推理、联合推演，难度从一星到五星，覆盖不同的同步要素组合。
- 本地预测与矫正：客户端收集本地输入帧并预测下帧状态，权威帧到达后做平滑矫正，避免频繁跳变。
技术栈建议
| 层次 | 推荐选型 | 说明 |
|---|---|---|
| 服务端 | Go | 承载房间服务器与谜题引擎 |
| 客户端 | TypeScript | 负责前端可视化与本地预测 |
| 协议 | WebSocket 加 gRPC | WebSocket 做帧同步，gRPC 推送状态 |
| 状态共享 | Redis 发布订阅 | 房间状态共享与回放日志 |
| 时钟 | 逻辑帧加滑动时间窗 | 同步管理器统一维护帧时钟 |
本章文章
| 文章 | 核心内容 |
|---|---|
| 在线联机原型全集：第 26 章 合作解谜系统（Cooperative Puzzle System） | 锁步同步、时间窗判定、冲突协调、多人协作、并发交互与断线重播回滚 |
与相邻章节的关系
- 上一章：第 25 章 市场系统 处理经济并发，本章处理帧级并发，是并发问题的另一面。
- 下一章：第 27 章 协作建造系统 把同步操作扩展为对世界状态的并发编辑，引入区域锁与 CRDT。
- 模型简化：第 14 章 房间逃脱 是本章玩法的前身，只是同步要求更宽松。