第 4 章把问题从「空间」拽回了「时间」。抢答游戏的规则一句话就能说完——第一个答对的人得分——但「第一个」这三个字在网络上极其昂贵：每个玩家的延迟都不同，客户端时钟不可信，消息到达顺序不等于发生顺序。本章的核心，就是让服务器成为唯一的时钟仲裁者，并在这个过程中学会控制广播量。它是后续所有限时判定、抢单、秒杀式玩法的理论原型。
本章定位
- 难度梯度：进阶。规则简单，但引入了时间公平性与并发裁定两个真正容易出错的问题。
- 前置章节：第 1 章 聊天室、第 2 章 石头剪刀布、第 3 章 井字棋 / 四子棋 均被标注为依赖模块，本章是前三章能力的汇总演练。
- 能力跃迁：从「状态正确」跃迁到「时序公平」。服务器不再只判断对错，还要判断先后。
- 阅读时长：单篇 PRD 约 450 行，建议重点读时间戳排序与延迟校准（client ping offset）两节。
核心验证目标
- 服务器时钟权威：以服务端时间戳为唯一参考，客户端提交必须携带可校正的偏移量，杜绝改本地时钟作弊。
- 毫秒级抢答裁定：多玩家并发提交时按时间戳排序并配合锁判断，保证「第一个正确答案」的唯一性。
- 延迟校准：通过 client ping offset 修正网络抖动带来的时间偏差，让远端玩家不被系统性歧视。
- 广播风暴控制：N 人同时答题会引发消息量成倍爆发，需要批量裁定、节流与延迟抑制。
- 题库系统：题目的随机抽取、缓存与持久化，Redis 承担热点题目的读取压力。
- 实时积分与排名：答对即时加分并刷新排名，积分变化需幂等，避免重复计分。
- 反作弊：答案混淆与签名、数据加密、提交速率限制，防止脚本抢答。
技术栈建议
- 语言：Go、Node.js，或 Elixir（其 Actor 模型与高并发广播场景天然契合）。
- 传输：WebSocket 加 JSON 消息流，题目推送与答案提交共用同一通道。
- 存储：Redis 用于题库缓存与实时积分；持久化题库落关系型数据库。
- 关键设计：把「裁定」与「广播」拆成两个服务，裁定必须串行、广播可以异步批量，这是控制广播风暴的结构性前提。
本章文章
| 文章标题 | 核心内容 |
|---|---|
| 在线联机原型全集：第 4 章 快速问答抢答（Trivia Buzzer） | 完整 PRD：TriviaRoomService、QuestionBank、AnswerJudge、ScoreService、BroadcastDispatcher 五模块设计，含时间同步、延迟校准与防作弊方案 |
本章只有一篇 PRD；延迟补偿的进阶做法（时空回溯）要到第 12 章的团队占点才系统展开。
与相邻章节的关系
- 上一章：第 3 章 井字棋 / 四子棋 处理空间状态，本章转向时间仲裁，两者共同构成「回合制」能力的完整面向。
- 下一章：第 5 章 你画我猜 把消息流升级为二进制绘图流，开始处理带宽与内容审核。