讲讲游戏里面的帧同步 vs 状态同步的区别，和各自的应用场景

这两种方案是游戏网络同步的两条根本不同的路，理解清楚对你 EA 面试非常有价值，因为 FC Mobile 这类实时体育游戏的同步选型是一个很典型的话题。

帧同步（Lockstep）

核心思想：同步输入，各自演算

服务器或 P2P 网络只传输每帧的玩家操作指令，每个客户端在本地运行完全相同的游戏逻辑，只要输入一样，结果就必须一样。

客户端 A: 第5帧 → 操作：向左移动
客户端 B: 第5帧 → 操作：攻击
          ↓ 双方都收到彼此的指令
客户端 A 本地模拟：A向左 + B攻击 → 结果
客户端 B 本地模拟：A向左 + B攻击 → 结果（必须与A完全一致）

帧同步对**确定性（determinism）**的要求极其苛刻：

• 浮点运算必须在所有平台上结果完全一致（通常用定点数替代 float）
• 随机数必须用相同种子的伪随机数生成器
• 物理引擎不能用任何不确定的优化
• 容器遍历顺序必须一致（不能用 unordered_map）

优点：

带宽极低，只传指令。1000 个单位在移动，网络包里只有两行输入，不是 1000 个坐标。天然支持完美回放（保存所有帧的输入就等于保存了整局游戏）。校验也简单，每隔若干帧对比各客户端的游戏状态哈希值，不一致就是 desync。

缺点：

最致命的问题是木桶效应——所有客户端必须等最慢的那个人确认收到输入才能推进下一帧（或者用预测帧 + 回滚来缓解）。一个人网络抖了，所有人都卡。另外 desync 一旦发生就是全局不一致，排查极其困难。

状态同步（State Sync）

核心思想：服务器权威，下发状态

服务器是唯一的”真相”，它维护完整游戏状态，定期把关键状态广播给所有客户端，客户端负责渲染。

客户端 A: 按下移动键 → 发送给服务器
服务器: 处理逻辑 → 计算新位置 → 广播给所有客户端
客户端 A/B/C: 收到新状态 → 渲染

状态同步的核心挑战不是同步本身，而是如何让玩家感觉不到延迟。由此衍生出三个关键技术：

客户端预测（Client-Side Prediction）：客户端不等服务器确认，立刻在本地执行自己的操作并渲染结果。服务器的权威结果回来后再做校正（reconciliation）。自己的角色不会感觉到延迟。

插值（Interpolation）：其他玩家的位置，客户端在收到的两个状态帧之间做插值平滑，避免其他角色”跳帧”。代价是其他玩家看起来总是落后 1-2 个状态帧。

延迟补偿（Lag Compensation）：FPS 里的典型问题——玩家在本地看到敌人在某个位置开枪，但服务器那边敌人已经移走了。服务器在处理开枪请求时，把游戏时钟”回拨”到玩家开枪时刻来判断是否命中。

两者的本质差异对比

各自的典型应用场景

帧同步适合：

• RTS（星际争霸、魔兽争霸、帝国时代）：单位数量可能成百上千，状态同步带宽不可承受，帧同步只传指令完美解决。
• 格斗游戏（街霸、铁拳）：双人对战，帧数据极少，对确定性要求高，帧同步配合 GGPO 回滚网络代码是行业标准。
• 早期 MOBA 手游（王者荣耀早期版本）：手机流量宝贵，帧同步带宽优势明显。

状态同步适合：

• FPS（CS、COD、Valorant）：射击判定必须服务器权威，延迟补偿 + 客户端预测是标配。
• MMO：玩家数量巨大，且不同玩家关注不同区域，按需同步（AOI，Area of Interest）是关键，状态同步更灵活。
• 体育手游（FC Mobile 这类）：移动网络波动大，每个玩家的延迟体验需要独立保障，服务器权威保证公平性，客户端预测保证手感。