Q16: 什么是同步问题？客户端和服务端的状态如何同步？
核心结论
“同步问题”本质上不是“怎么把所有状态一模一样搬到客户端”，而是：
- 服务端和客户端看到的世界天然不同时
- 如何让逻辑保持权威
- 如何让表现足够平滑
- 如何把误差控制在可接受范围内
所以状态同步真正要解决的是三层问题：
- 权威状态在谁手里
- 哪些状态必须同步
- 客户端在等待同步时怎么掩盖延迟
对 MMO 来说，主体通常采用的是：
- 服务端权威
- 状态同步为主
- 客户端预测、插值、校正作为表现补偿
而不是全量纯帧同步。
一、同步问题为什么一定存在
在网络游戏里，客户端和服务端不可能天然保持完全一致。
原因很简单：
- 网络有延迟
- 消息有抖动和丢包
- 客户端渲染和服务端逻辑不是同一个节奏
- 每个客户端只看到自己收到的那部分信息
所以任何多人游戏里都会天然出现：
- 服务端状态
- 本地客户端状态
- 其他客户端状态
它们在同一时刻并不完全一样，这是正常现象。
真正的问题是：
- 哪些不一致可以接受
- 哪些不一致必须纠正
二、先分清“同步的是什么”
很多讨论一上来就说“做状态同步”，但没有说清到底同步哪类东西。
更合理的划分至少有四类。
2.1 位置与运动状态
例如：
- 坐标
- 速度
- 朝向
- 当前移动状态
这类状态变化频繁，且很受网络影响。
2.2 核心逻辑状态
例如：
- HP / MP
- Buff / Debuff
- 技能冷却
- 存活状态
这类状态直接影响逻辑正确性。
2.3 事件
例如：
- 技能释放
- 受击
- 死亡
- 进入战斗
事件和状态不是一回事。
事件是“发生了一次什么”，状态是“现在是什么样”。
2.4 表现层信息
例如：
- 动画播放
- 特效触发
- 飘字
- 音效
这类信息通常更偏表现，可以容忍一定误差。
如果不先把这几类分开，后面就会出现：
- 把事件当状态传
- 把状态当事件补发
- 最后协议和校正逻辑都变乱
三、先决定谁是权威源
同步问题的第一原则是：必须有权威源。
3.1 服务端为什么通常是权威
因为它要负责：
- 防作弊
- 统一裁决
- 保证最终一致
- 处理多人交互冲突
如果权威不在服务端，就很容易出现：
- 客户端各说各话
- 资产状态被篡改
- 战斗结果无法统一
3.2 客户端能不能“先动起来”
可以，但那不等于客户端成为权威。
更准确地说是：
- 客户端先做预测或表现
- 服务端最终确认
- 客户端再对齐服务端状态
也就是说，客户端可以先演，但不能最终拍板。
四、同步不是只有“状态同步 vs 帧同步”两个词
4.1 状态同步
状态同步的核心思路是：
- 服务端维护权威状态
- 客户端周期性接收状态更新
- 客户端做插值、外推和校正
它适合：
- MMORPG
- 大世界游戏
- 大量实体同时存在的场景
因为这类游戏里，玩家看到的世界本来就不是全局完整视角。
4.2 帧同步
帧同步的核心思路是：
- 各端同步输入
- 在同样的帧步长下执行相同逻辑
- 依靠确定性保持状态一致
它适合：
- RTS
- 格斗
- 少量单位、高确定性玩法
它不太适合大多数 MMO 主体场景，原因包括：
- 视野不同
- 实体数量大
- 局部区域热点明显
- 大世界里很难保证全局统一帧逻辑代价可控
4.3 真正常见的现实方案
大多数 MMO 实际上是混合的：
- 主世界主体逻辑：状态同步
- 某些小玩法、对局玩法：可能接近帧同步或半锁步
- 客户端表现层：预测 + 插值 + 校正
所以不要把同步问题理解成“只能二选一”。
五、状态同步真正的核心链路
一个更常见的服务端权威链路通常是：
- 客户端发送输入或操作请求
- 服务端验证并更新权威状态
- 服务端把状态变化广播给相关客户端
- 客户端用表现层手段平滑过渡到新状态
这条链路里最重要的是：
- 客户端发的是“意图”还是“结果”
- 服务端广播的是“事件”还是“最新状态”
- 客户端看到偏差时如何拉回
六、客户端为什么一定要做预测和插值
如果客户端每次都等服务端确认后再动，体验通常会很差。
6.1 本地玩家常见做法：预测
例如本地移动时：
- 客户端先立即移动角色
- 同时把输入发给服务端
- 服务端确认合法后继续同步
- 如果不一致，再做校正
这样做的目的是：
- 保证手感
代价是：
- 必须接受“偶尔拉回”
6.2 远端玩家常见做法：插值
对远端玩家，客户端一般不会做强预测，而更常见的是：
- 接收一系列位置样本
- 在样本之间平滑插值
这样做的目的是：
- 让画面稳定
- 避免跳变
6.3 丢包时常见做法：短时外推
如果新包暂时没到，可以按旧速度做短时间预测。
但外推不能无限做，因为时间越久误差越大。
七、校正是同步系统里最容易被低估的一环
只做预测不做校正，系统一定会漂。
7.1 小误差：软校正
如果偏差不大，通常应该：
- 平滑拉回
- 避免玩家肉眼看到瞬移
7.2 大误差：硬校正
如果偏差已经明显到影响逻辑，就不能再慢慢拉。
这时通常要：
- 直接校正到权威状态
7.3 校正不能只看位置
很多系统只关注位置校正，但实际上还要考虑：
- 朝向
- 速度
- 技能状态
- Buff 状态
- 是否命中、是否死亡
否则表面位置对齐了，逻辑还是错的。
八、MMO 里还要加上 AOI 和可见性裁剪
同步不是把全世界广播给所有客户端。
MMO 最关键的一层是：
- 只同步玩家当前感兴趣区域内的实体
这就是为什么同步系统和 AOI 往往绑定得很紧。
8.1 为什么必须做 AOI 裁剪
因为如果不裁剪：
- 带宽会爆
- 客户端处理不过来
- 同步延迟会越来越高
8.2 所以 MMO 的同步系统天然是局部同步
这也是它和纯帧同步玩法的一个根本差别：
- 并不是所有人都必须拿到同一份全局状态
- 而是每个人拿到“与自己相关的那一部分状态”
九、状态同步最常见的优化方向
9.1 增量同步
不是每次都发完整状态，而是只发变化部分。
适合：
- 中低频状态变化
- 有稳定基线状态的系统
9.2 优先级同步
不同状态优先级不同。
例如：
- 玩家位置、伤害结果优先级高
- 环境对象、低价值表现优先级低
网络紧张时，低优先级消息可以降频甚至暂时跳过。
9.3 频率分层
不同对象的同步频率也不该一样。
例如：
- 本地玩家附近战斗实体：高频
- 远处普通怪物：中频
- 环境对象：低频
9.4 压缩与裁剪
真正有效的优化通常是组合的：
- 字段裁剪
- 增量同步
- AOI 限制
- 消息压缩
而不是只靠其中一种。
十、几个最常见的误区
10.1 误区一：同步就是把所有状态都发出去
不对。
同步的重点从来不是“全发”，而是：
- 发必要的
- 发对的人
- 在合适的频率发
10.2 误区二：客户端预测越多越好
也不对。
预测越多，校正成本和错误表现也越大。
预测应该只用在：
- 体验收益明确
- 可被权威状态拉回
的场景里。
10.3 误区三：状态同步和事件同步可以混着设计
如果不区分事件和状态，最后往往会出现：
- 重复执行事件
- 用旧状态覆盖新事件
- 回滚和补发逻辑混乱
这两个概念一定要分开。
十一、一个更实用的理解框架
如果要把同步问题讲清楚，更好的框架通常是：
- 服务端负责权威逻辑
- 客户端负责体验补偿
- 状态同步负责把世界大体对齐
- 事件同步负责表达“发生了什么”
- 校正负责把偏差拉回
- AOI 负责控制同步范围
把这几层分开，整个系统就清楚很多。
十二、总结
同步问题的本质，不是追求客户端和服务端在每一瞬间都绝对一致，而是：
- 逻辑上以服务端为准
- 表现上尽量平滑自然
- 在弱网和延迟下仍然能收敛到同一个结果
对 MMO 来说，更常见也更稳妥的方案通常是：
- 服务端权威
- 状态同步为主
- 事件同步辅助
- 客户端预测、插值、外推、校正做体验补偿
- 再结合 AOI 和优先级控制同步成本
这才是一个可用的同步系统，而不是单独喊一句“用状态同步”。