第 15 章是本批次的收官，也是实时同步线的一次全面加压。赛车和 Pong 的区别在于：Pong 的球是刚体直线运动，赛车要处理加速、转向、摩擦、碰撞与漂移，物理状态维度高得多；而玩家对操控的敏感度也高得多——一个 100 毫秒的延迟在 Pong 里只是手感稍钝，在赛车过弯时会直接导致撞墙。于是本章把客户端预测与服务端回滚推到主线：本地输入立刻生效，收到权威帧后回滚到确认点、重放未确认输入。这套机制是格斗与竞速类游戏的标准解。
本章定位
- 难度梯度：高阶，本批次技术密度最高的一章。前十四章的同步经验在此汇总成一套完整的预测回滚管线。
- 前置章节：第 7 章 贪吃蛇大作战（实时同步框架）、第 11 章 团队塔防（AOI 与物理同步）、第 2 章 石头剪刀布（回合锁步框架）被标注为依赖。
- 能力跃迁：从「预测加纠正」跃迁到「预测加回滚」。第 6 章的 Pong 只做状态平滑校正，本章要求把模拟状态真正倒回历史 Tick 再重放，对确定性要求高一个量级。
- 阅读时长：单篇 PRD 约 550 行，建议重点读 Tick 时序表、预测与回滚回路、碰撞裁定与轨迹对齐三节。
核心验证目标
- 客户端预测：输入在本地立即生效，不等服务器确认，用预测隐藏往返延迟。
- 服务端回滚：收到权威帧后按确认序列回滚并重放未确认输入，校正过程需对玩家不可见。
- 物理模拟确定性：客户端与服务器共享同一套物理模型，浮点行为与积分步长必须一致，否则回滚后必然发散。
- 碰撞裁定：碰撞统一由服务端权威处理，客户端预测的碰撞结果可能被推翻，需要平滑回退而非瞬移。
- 轨迹对齐与漂移控制：50 至 200 毫秒模拟延迟下的漂移表现评估，对齐策略决定最终手感。
- 高频输入与带宽控制：30 至 60 Hz 的输入帧率下，状态压缩与增量同步要保证带宽可控。
- 状态帧与输入帧协议：逻辑 Tick 统一为 33.33 毫秒（30 fps），每 Tick 生成状态帧，输入帧携带 Tick 序号供服务端排序。
技术栈建议
- 语言：服务端用 Go，客户端用 TypeScript（基于 WebGL 与 Three.js，或 Unity WebGL）。
- 协议栈：UDP 或 WebSocket，采用可靠加低延迟的混合模式，配合 Tick 与 StateFrame 同步模型。
- 存储：状态帧环形缓冲驻留内存供回滚使用，关键帧周期落盘供回放。
- 关键设计：逻辑 Tick 与渲染帧解耦，物理步长固定不可随帧率浮动。这是回滚能否收敛的唯一硬约束，也是最容易在实现中被破坏的一点。
本章文章
| 文章标题 | 核心内容 |
|---|---|
| 在线联机原型全集：第 15 章 微型赛车系统（Mini Racing System） | 完整 PRD：模块分层、Tick 与时序结构、输入帧与状态帧协议、客户端预测与服务端回滚、碰撞裁定与轨迹对齐、延迟与带宽控制策略 |
本章只有一篇 PRD；更底层的物理与渲染细节在游戏客户端专题中有独立文章，本章聚焦网络同步部分。
与相邻章节的关系
- 上一章：第 14 章 房间逃脱 处理离散状态机与并发仲裁，本章转向连续物理模拟与回滚。
- 下一章：第 16 章 简版 MOBA 把战斗、AI 单位、Tick 同步与重连恢复组合成更完整的实时对战系统，是本章能力的下一级台阶。