1. 同步技术概述：什么是状态同步，什么是帧同步

大家好，我是你们这门课的主讲。今天咱们来聊聊游戏同步里最基础、也最绕不开的两个概念——状态同步和帧同步。

说实话，我刚开始做游戏服务器那会儿，也分不太清这两者的边界。直到有一次在项目里选错了同步方案，导致后期改得头皮发麻……嗯，从那以后，我对这两个词的理解就深刻多了。

咱们不整那些虚的，直接上干货。

什么是状态同步？

状态同步，说白了就是——服务器说了算。

每个客户端把自己的操作发给服务器，服务器收到后做逻辑运算，算出最终结果（也就是“状态”），再把这个结果广播给所有客户端。客户端只管把收到的状态“展示”出来就行。

举个例子：你玩王者荣耀，点了一下攻击按钮。客户端把这个“攻击指令”发给服务器，服务器判断你的攻击是否命中、扣多少血，然后把“扣血后的血量”这个状态同步给所有人。你的手机只是把结果画出来。

我个人习惯把状态同步叫做“结果同步”——因为同步的是结果，不是过程。

什么是帧同步？

帧同步，思路正好反过来。

每个客户端把自己的操作（比如“按了W键”、“鼠标左键点击”）广播给所有其他客户端。每个客户端收到所有人的操作后，各自在本地跑一遍相同的逻辑，得出完全一样的结果。

你想想看，这就像几个人一起看同一部电影。只要大家同时按下“播放”键，并且播放的是同一个片源，那每个人看到的画面就是一样的。帧同步里的“帧”，指的就是逻辑帧——一个固定的时间片，比如每66ms处理一次输入。

我在做RTS游戏（比如类《星际争霸》）时，用的就是帧同步。每个客户端每帧收集所有玩家的指令，然后统一推进游戏逻辑。效果很爽，但调试起来……嗯，后面章节我会细讲坑在哪。

两者的核心区别

咱们用一张表来对比，这样更直观：

对比维度	状态同步	帧同步
同步内容	同步游戏状态（位置、血量等）	同步玩家输入（按键、点击等）
逻辑执行方	服务器执行逻辑，客户端只展示	所有客户端各自执行逻辑
网络带宽	状态数据量大，但频率可调低	输入数据量小，但频率高（每帧都发）
防作弊能力	强（服务器权威）	弱（客户端可篡改逻辑）
断线重连	容易（只需同步最新状态）	困难（需要回放所有历史输入）
开发复杂度	中等	高（需要保证逻辑确定性）

这里我多说一句：帧同步对逻辑的“确定性”要求极高。什么叫确定性？就是同样的输入，在任何机器上、任何时间跑，结果必须完全一样。浮点数精度、随机数种子、甚至多线程执行顺序，都可能破坏确定性。我曾经因为一个Math.random()没处理好，导致两个客户端在第3000帧时结果不一样……排查了整整两天。

适用场景

选哪个方案，其实看游戏类型就大概知道了。

状态同步适合的场景

• MMORPG（魔兽世界、最终幻想14）：玩家多、世界大、状态复杂，服务器必须做权威判断
• FPS/TPS（绝地求生、守望先锋）：虽然也有用帧同步的，但主流大厂还是状态同步+客户端预测
• 卡牌/策略游戏（炉石传说）：状态变化不频繁，同步成本低
• 任何需要强防作弊的游戏：只要服务器说了算，外挂就难下手

帧同步适合的场景

• 格斗游戏（街霸、拳皇）：操作精度要求极高，帧同步能保证所有玩家看到完全一致的画面
• RTS游戏（星际争霸、帝国时代）：大量单位同时行动，状态同步带宽扛不住
• MOBA游戏早期版本（Dota1、LOL早期）：其实LOL早期是帧同步，后来才改的状态同步
• 本地多人/联机数少的游戏：2-8人对战，帧同步的确定性优势很明显

一个小例子帮你理解

假设两个玩家控制角色移动，从A点走到B点：

状态同步的做法：

客户端1: "我要往右走"
  → 服务器收到，计算新位置 (x=10, y=0)
  → 服务器广播: "玩家1的位置是 (10, 0)"
  → 所有客户端把玩家1显示在 (10, 0)

帧同步的做法：

客户端1: "我按了→键"
  → 服务器收集所有输入，打包成"第10帧输入包"
  → 广播给所有客户端
  → 每个客户端自己计算: "玩家1按了→，所以位置从(0,0)变成(10,0)"
  → 所有客户端结果一致

看出来了吗？状态同步里，服务器是“大脑”；帧同步里，每个客户端都是“大脑”，但大家用的是同一套“食谱”。

好了，这一章咱们把状态同步和帧同步的概念、区别、适用场景都捋了一遍。下一章我会深入讲状态同步的架构设计，包括客户端预测、插值、延迟补偿这些实战技术。到时候我会拿一个我实际做过的MMO项目来拆解，保证干货满满。

记住一句话：没有最好的同步方案，只有最合适的。选型之前，先想清楚你的游戏到底需要什么。