帧同步这个技术，我接触了快八年，从早年做格斗游戏Demo踩坑，到后来在两家公司参与竞技项目的帧同步框架搭建，中间踩过的坑、趟过的雷，加起来能写一本小册子。很多Unity程序员对帧同步的印象就是"每个客户端跑同样的逻辑，结果一致"，但真到了商业项目里，浮点数精度、随机序列、物理引擎确定性、断线重连、帧率波动，随便一个环节出问题，线上就是事故。这篇文章我想从原理到商业实战，把帧同步完整拆开来讲，包括我实测过的方案和踩坑记录，给想入坑或者已经在坑里的Unity程序员一些参考。

先说清楚这篇文章到底解决什么问题：你拿着需求要做一款实时对战游戏，比如格斗、MOBA、RTS、音游，对战人数不太多但操作实时性强，这时候帧同步往往是比状态同步更优的方案。但它对工程化要求极高，如果原理理解不到位，开发到中期会发现怎么调都不同步，甚至崩溃。这篇文章会从底层原理讲到商业项目落地，包括定点数怎么选、逻辑帧怎么定、服务器怎么调度、回放怎么实现、不同步怎么排查，全程配合我实际开发中的例子和参数，可以让想接手这类项目的读者少走很多弯路。

1. 先说清楚：帧同步到底在解决什么问题

1.1 从状态同步和帧同步的核心差异说起

大多数Unity开发者接触网络同步，第一次都是做状态同步：客户端把操作发到服务器，服务器跑逻辑，算好所有人的位置、血量、Buff，再把完整状态广播给所有客户端。这种模式逻辑上很好理解，缺点是服务器压力大、流量高、客户端的操作感会受网络延迟影响。比较典型的例子是传统MMORPG，几十上百人同屏，状态同步是主流方案，但也经常出现你按了技能、半秒后才有反应的情况。

帧同步的思路完全不同。它不传输状态，只传输"操作指令"。每个客户端都运行一份完整的游戏逻辑，服务器只负责把大家的操作按帧号广播出去，所有客户端在同一个帧号执行同一批指令。因为逻辑是确定的，所以只要初始状态一致、指令序列一致，最终每个客户端算出来的世界状态就一致。这个过程有点像：给一百个人发同一份乐谱，让他们在同一拍开始演奏，只要每个人演奏的规则完全一致，最后听起来就是同一首曲子。

这就能解释为什么格斗游戏、MOBA、RTS特别青睐帧同步。这类游戏对操作响应要求极高，玩家按下一个技能，你希望在下一帧甚至本帧就能看到反馈。帧同步下客户端可以本地先行执行自己的操作，不需要等服务器回包，手感天然比状态同步好一个量级。

1.2 帧同步的适用边界：不是所有游戏都该用帧同步

我见过不少团队，一听到帧同步"省流量、手感好"，不管什么项目都往上套，结果开发到一半痛不欲生。这里先泼一盆冷水，帧同步有几个硬性前提，满足不了就别硬上。

第一，参战实体数量不能太多。帧同步要求每个客户端完整模拟全场逻辑，实体越多，单帧计算成本越高。上百个单位互相寻路、碰撞、技能判定，帧同步往往顶不住，也就是为什么大规模战争类游戏一般还是用状态同步或者"分层同步"。

第二，逻辑复杂度必须可控。逻辑里但凡混入一点不确定因素——物理引擎Float运算、平台相关数学函数、非确定性随机——早晚会出不同步。你的团队如果没有能力从代码层面强制确定性，这个方案会变成一场噩梦。

第三，规则必须是强一致的。比如格斗游戏的连招判定、击退距离、受击硬直，这些数值必须全球所有客户端完全一致，不允许任何一方客户端有"本地特权"。

如果你的项目满足这三条，帧同步能让你的服务器带宽开销降到极低，操作手感直线提升。如果不满足，建议老老实实用状态同步，不要为了炫技给自己挖坑。

1.3 商业项目里帧同步还有什么隐藏价值

除了省流量和手感好，帧同步在商业项目里还有个巨大的隐形优势：回放系统几乎零成本。因为整局游戏只是"初始种子 + 一串输入指令"的产物，回放就是重新执行一遍同样的输入。我参与过的某格斗项目中，回放系统就是直接复用战斗逻辑模块，服务器只存输入流，一个几百KB的录像文件能完整还原整场战斗，这对电竞判负、观战、内容复盘都很有价值。

另外，帧同步天然适合"观战跟随"。观战客户端不需要频繁同步所有人的位置，只需要跟着某个玩家的视角，接收同一份输入流即可。这个特性在直播场景、游戏内置观战系统里非常实用。

2. 帧同步的核心原理拆解：确定性是命根子

2.1 确定性模型：同样的输入、同样的帧号，必须得到同样的结果

帧同步的前提是"确定性计算"。定义很简单：给定同样的初始状态、同样的输入序列、同样的代码版本，无论在谁的机器上跑，无论跑多少次，得到的结果必须逐位相同。

很多第一次接触这个概念的开发者会问：这难道不是理所当然的吗？同一份代码在同一个游戏里跑，结果不就应该一样吗？答案是，在单机环境下，大部分时候确实一样，但放在跨平台、跨设备的网络环境里，很多你以为是确定性的东西其实都是不确定的。

我举个例子。Unity的Transform.position是Vector3，也就是三个float。float在不同CPU架构下的乘加运算精度并不完全一致，Intel和ARM的浮点行为有差异，GPU和CPU的差异就更大了。你的伤害计算里如果有一个float乘法，在开发机上算出10.000001，在玩家手机上算出10.000000，这个微小差异平时看不出问题，但经过几百帧的累积，两个客户端的血量、位置、判定窗口就会慢慢漂移，最终表现为"两个人明明同时出招，一个人打到了另一个人没打到"。

更麻烦的是，这些微小差异不是你写代码时能一眼看出来的，等到线上对战时才随机爆发，排查难度极高。所以帧同步项目的第一铁律就是：逻辑层坚决杜绝非确定性因素。

2.2 浮点数、随机数、集合遍历、物理引擎：四个隐藏杀手

确定性问题的元凶，我归纳下来主要有四类，建议做帧同步的团队把下面这张表贴在工位上，每天写代码前都看一眼。

先讲浮点数。Unity开发中最直接的问题是，逻辑层用了float计算位移、伤害、击退距离。我在某MOBA项目中做过一次全量审计，逻辑层有上百处float运算，最终统一替换成定点数才解决不同步问题。这个后面详细讲。

再讲随机数。游戏逻辑几乎离不开随机：暴击判定、随机掉落、AI巡逻方向。如果直接用UnityEngine.Random.Range，每个客户端初始化时各自调用，得到的随机序列完全不一样，战斗结果自然五花八门。正确做法是在战斗开始时同步一个随机种子，逻辑层只通过这个种子驱动的确定性随机器来生成随机数，比如用System.Random配合统一种子，或者干脆自己实现一个确定性随机算法（比如xorshift、PCG）。我自己项目中用的是PCG算法，速度比System.Random快，而且跨平台行为完全一致。

第三类是集合遍历顺序。这个坑很隐蔽。Dictionary在绝大多数平台上遍历顺序和你插入顺序无关，而且不同平台甚至不同运行版本下顺序都可能不一样。如果你的逻辑代码里有"遍历所有敌人，先处理离我最近的"这样的需求，万一遍历顺序不一致，两个客户端处理攻击事件的顺序就不同，结果自然不同步。解决方案有几种：不使用Dictionary做逻辑遍历，改用List并按唯一ID排序；或者如果非要Dictionary，每次遍历前先取出Key排序。总之，逻辑层对集合的访问必须是全序的。

第四类是物理引擎。Unity的物理系统基于PhysX，不同平台的行为本来就有差异，加上物理模拟本质上依赖浮点运算，几乎不可能做到跨平台确定性。商业项目的通用做法是：逻辑层完全不用Unity物理引擎，自己写碰撞判定和位移计算。听起来工作量很大，但在竞技游戏里，角色碰撞、受击框、判定框这些逻辑本来就是需要精确到像素级别的，自己写反而更可控。我在格斗项目中就是把碰撞盒和判定盒全部手写，用AABB和OBB就够了，效果很好。

2.3 定点数方案的落地细节

既然浮点数是确定性头号杀手，商业项目中最稳妥的方案就是逻辑层全面改用定点数。定点数的思路很简单：用整数来表示小数，比如把一个float放大10000倍存储，运算时用整数运算，最后显示时再缩小回去。Unity里可以选择自己封装一个FixedPoint结构体，或者直接用成熟的库，比如FixMath.NET、Phoenix系列。

我个人的做法是自研一个简化版定点数，底层用long存储，数值范围控制在几十亿以内，精度取小数点后4位，也就是1/10000。这样乘法、加法、比较都直接映射为long运算，跨平台行为完全一致。下面是我项目里定点数结构体的核心代码结构，思路可以直接参考。

// 简化的定点数核心实现 public struct FixPoint { public long Raw; // 使用long存储，扩大10000倍 public static readonly FixPoint Zero = new FixPoint(0); public static readonly FixPoint One = new FixPoint(10000); public FixPoint(long raw) { Raw = raw; } public static FixPoint FromFloat(float f) { return new FixPoint((long)(f * 10000)); } public static FixPoint operator +(FixPoint a, FixPoint b) { return new FixPoint(a.Raw + b.Raw); } public static FixPoint operator -(FixPoint a, FixPoint b) { return new FixPoint(a.Raw - b.Raw); } public static FixPoint operator *(FixPoint a, FixPoint b) { return new FixPoint((a.Raw * b.Raw) / 10000); } public static bool operator <(FixPoint a, FixPoint b) { return a.Raw < b.Raw; } // 其他运算符和数学函数，比如Sqrt、Sin、Cos等，都需要基于Raw实现 public float ToFloat() { return Raw / 10000f; } }

你可能注意到，定点数实现里最麻烦的不是加减乘除，而是三角函数、开方这些数学函数。如果游戏逻辑里用到Mathf.Sin、Mathf.Atan2，这些函数在不同平台下的实现精度不一致，也会导致不同步。解决方案有两个：一是用查找表，把角度值离散化，预先算好对应的Sin、Cos值存到表里，查表得出结果，这在中低精度需求下完全够用；二是用多项式逼近，比如用泰勒展开实现自己的Sin、Cos，只要展开阶数确定，不同平台跑出来就是完全一致的。我项目中的做法是手写了Sqrt、Sin、Cos、Atan2四个常用函数，其余能不用就不用。

提示：定点数计算有溢出风险，尤其是乘法。我习惯在开发阶段开启long溢出的checked模式，把潜在溢出在测试期就暴露出来，而不是等上线后在玩家手机上崩溃。这个习惯救了我好几次。

3. 实战前的底层设计：逻辑帧与渲染帧分离

3.1 为什么必须锁帧：帧号一致是同步的基础

帧同步最基本的时间单位是"逻辑帧"，也叫"同步帧"。所有客户端必须对"当前是第几帧"有一致的认知——某个玩家的操作归属到第几帧，服务器广播给所有人，所有人都要在这一帧执行。

但问题来了：玩家手机性能相差很大，有人90帧，有人30帧。如果逻辑帧跟着渲染帧跑，性能高的客户端一秒钟跑了90步逻辑，性能低的只跑30步，很快就乱套了。所以帧同步的铁律是：逻辑帧是固定的，与渲染帧无关。不管屏幕刷新率是30还是144，逻辑帧每秒固定跑若干个，常见的取值是15、20、30。我做过的大多数项目，逻辑帧率取15，也就是每帧66.7毫秒，这样既能保证操作精度，又能给逻辑计算留够时间。有些对操作性要求极高的格斗游戏会取30逻辑帧，但每帧的逻辑计算量必须控制得很小。

Unity中的实现方法是把逻辑更新挂在FixedUpdate或者自己写定步长循环里，但切记不能直接用Time.fixedDeltaTime，因为FixedUpdate的调用时机受物理系统影响，不同平台的精确行为还是有差异。更稳的做法是自己维护一个帧计数器，在Update里检测是否到了逻辑帧的边界，到了就执行一帧逻辑更新。

public class LogicDriver : MonoBehaviour { public float LogicFrameInterval = 1f / 15f; private float _accumulator; public uint CurrentFrame { get; private set; } private void Update() { _accumulator += Time.deltaTime; while (_accumulator >= LogicFrameInterval) { _accumulator -= LogicFrameInterval; TickLogicFrame(CurrentFrame); CurrentFrame++; } } private void TickLogicFrame(uint frame) { // 1. 获取当前帧的输入队列（包含本地预测输入和服务器广播的远端输入） // 2. 按顺序执行所有实体逻辑 // 3. 计算校验Hash（可选） // 4. 更新渲染对象的位置（插值或直接赋值） } }

3.2 输入采集、预测与确认：玩家操作怎么变成指令

帧同步的输入系统，核心是解决"玩家操作从按下到生效"这条路径上的延迟问题。因为网络有延迟，玩家按下一个键以后，如果非要等服务器把这条指令广播回来才执行，操作感和单机游戏就差远了。

所以商业项目普遍采用"本地预测 + 服务器裁决"的模式。具体过程是这样的：玩家的操作在本地立刻记录为一个带时间戳的输入指令，本地逻辑帧马上执行这条指令，这个过程叫"预测"；同时这条指令会上传到服务器，服务器统一收集所有人的指令，封装成一个带帧号的输入包再广播给所有人。其他客户端收到这个包之后，在自己的逻辑里执行；如果本地预测的结果和服务器最终广播的指令有冲突（比如本地预测不知道自己被眩晕了，还按了攻击键），则以服务器广播为准，进行回滚和修正。

这里的核心设计是：输入指令必须携带精确归属的帧号。我常用一个InputFrame结构，里面包含：玩家ID、目标帧号、按键状态Bitmask、额外数据（比如移动摇杆的方向和力度）。所有操作都被编码成纯数据，方便打包、广播、存储。按键状态Bitmask的编码方式如下：每个操作对应一个bit，比如0x01表示轻拳、0x02表示重脚、0x04表示跳跃、0x08表示格挡。这样一条指令只需要几个字节，几百KB能存一整场格斗比赛的输入流。

3.3 服务器调度与帧缓存策略：核心机制怎么设计

帧同步的服务器，我把它分为两种：纯转发服务器和权威裁决服务器。纯转发服务器只负责把每个客户端上传的指令收集起来，按约定的逻辑帧率打包广播，不做逻辑计算，优点是便宜、简单、低延迟；权威裁决服务器会自己跑一遍完整逻辑，定期把校验值广播给所有客户端，一旦客户端算出来的结果不一致，立刻能发现并纠偏。

纯小规模对战（1v1、3v3）用纯转发服务器就足够，因为对战的确定性由客户端保证，服务器只解决"大家拿到的输入序列一致"这个问题。但如果涉及断线重连、观战、防作弊，就需要权威服务器参与校验。我参与的项目最终采用的是混合架构：正常对战走纯转发，同时服务器每30帧做一次轻量校验（对比所有客户端上报的当前关键实体状态Hash），发现不一致就标记该局，并把权威快照下发修正。

帧缓存策略是另一个重点。因为网络抖动，指令包到达顺序可能错乱，客户端必须缓存未来若干帧的输入，确保执行到某一帧时，该帧的输入已经到达。缓存深度通常取3到5个逻辑帧。缓存太浅，碰到轻微网络抖动就卡住；缓存太深，操作延迟会明显变高。我一般设定为3帧，并让客户端在缓存不足时自动进入"等待态"，此时暂停逻辑帧推进，UI上显示网络状态图标，避免玩家在指令缺失的情况下强行推进导致不同步。

4. 商业项目实践：从零搭建一套可用的帧同步框架

4.1 客户端分层架构：逻辑层、表现层、网络层怎么分工

很多Unity开发者犯的一个错误是，把帧同步逻辑直接写在MonoBehaviour里，结果逻辑和表现耦合严重，动不动就碰到Time.deltaTime、Transform、Camera这些渲染相关的东西，确定性全毁了。商业项目必须做严格分层。

我常用的分层方式分三层：表现层、逻辑层、网络层。

表现层负责所有Unity渲染相关的事：模型、动画、特效、摄像机、UI。表现层可以任意使用Vector3、Quaternion、Time.deltaTime这些Unity友好的类型，因为它只是"展示"逻辑层的数据。逻辑层是一个纯C#类库，不引用任何Unity类型，所有数值都用定点数、自定义向量、自定义矩阵，所有单位都用自己的逻辑实体类。网络层负责指令收发、帧缓存、重连等，它把收到的输入包解析成逻辑层能用的数据结构，然后驱动逻辑层跑帧。

有个关键问题：表现层怎么跟随逻辑层？逻辑层每帧算出逻辑位置，表现层需要平滑地把模型移动到新位置。最简单的做法是逻辑层每帧输出每个实体的公钥数据（位置、朝向、状态机ID），表现层在LateUpdate里直接赋值。如果逻辑帧率是15，画面帧率是60，直接赋值的话模型会有跳顿感，所以表现层要做插值。我用的方案是保留逻辑层前两帧的位置快照，表现层根据逻辑帧的进度做线性插值，视觉上非常流畅。插值只发生在表现层，不参与逻辑计算，所以不影响确定性。

4.2 核心模块实现细节：帧缓存、快照与回放

下面展开三个商业项目必需的模块：帧缓存、快照校验、回放系统。

帧缓存模块的逻辑不是复杂，但是细节决定成败。我实现了一个InputBuffer类，用一个Queue<InputFrame>存未来几帧的输入。每收到一个服务器广播包，就解析出其中的指令列表，按帧号插入到队列的合适位置；每推进一个逻辑帧，就从队列头部取出对应帧号的输入。这里要注意插入排序的稳定性，因为网络包可能乱序到达，后到的帧号比先到的还小，必须按帧号重新排列。

快照校验模块是排查不同步的利器。逻辑层每N帧（我通常选30帧，也就是2秒一次）对外输出一个当前关键状态的Hash值。Hash的计算方式是把所有关键实体的位置、血量、状态机ID拼接成字节流，用MD5或者CRC32算一个纯校验值。客户端把这个校验值随输入一起上报，服务器比对所有客户端的校验值，一不一致就报警。有一次线上事故，就是因为某个单位技能里用了Time.time做计时，导致两个客户端技能释放时机偏差了一帧，最后30帧后的校验值对不上，通过快照校验模块瞬间就定位到了问题。

回放系统实现起来非常妙：因为整局游戏只是"初始化种子 + 输入指令流"的产物，所以回放就是重跑逻辑。具体做法是记录三样东西：初始终端种子、初始角色配置、完整输入流（按帧号排列的所有玩家指令）。回放时，新建一个逻辑世界，用记录的种子初始化随机器，然后按相同的帧率重放输入流，到哪一帧就执行哪一帧的指令。整个回放和观战完全复用战斗逻辑，不写一行额外代码。

4.3 不同步检测与自动纠正机制

就算开发期做得再谨慎，发布后还是可能在玩家的某个诡异机型上出现不同步。所以商业项目必须做两件兜底的事：检测和恢复。

检测就是上面说的Hash上报。发现不一致后怎么办？如果不同步只发生在两个客户端之间且影响很小，可以尝试用服务器权威快照对整个战斗世界做一次修正。我做过一个自动纠偏方案：服务器每30帧保存一份权威快照——包括所有单位的位置、血量、Buff列表、状态机的关键变量——发现不一致时，把快照下发给所有客户端重载。听起来简单，实现起来难点在于：逻辑世界里除了单位状态，还有弹道、技能作用域、场地事件这些临时实体，快照必须把所有运行时对象都序列化。我在某格斗项目中只对核心战斗实体做快照，非核心的临时对象（比如一次性特效判定、已发射弹道）直接重建，简化了不少工作。

不过说实话，自动纠偏是最后一道保命手段，正常开发节奏里应该把它做成"开发期报警工具"而不是"线上治疗工具"。线上真正健康的帧同步系统，运行很多局也不该出现一次校验不一致。

4.4 测试与调试工具：帧同步项目的必备基建

没有一套趁手的调试工具，帧同步项目开发到后期会很痛苦。我们项目组打磨了一套"帧级回放调试"工具，可以在本地复现某一局的所有帧，逐步单帧推进。每次线上不同步，客户端上报当前的帧号和Hash，我们直接拿到对应玩家录像，在调试工具里单步跑，很快就能定位是哪一帧哪条指令开始出现偏差。

另外我强烈建议，从开发第一天起就把逻辑层的所有随机行为、时间调用、浮点运算标记化。怎么做呢？在逻辑层封装一个统一的GameRandom类、一个GameTimer类、一个FixedMath静态类，所有逻辑代码只能通过这三个入口访问随机、时间和数学函数。这样在做代码审计时，直接全局搜索"Mathf."和"Random."，如果有遗漏，立刻就能发现。我见过不止一个项目，因为某次需求急着上线，临时在逻辑层塞了一句Time.deltaTime，结果线上出了事故才追悔莫及。

5. 常见问题与排查技巧实录

5.1 典型不同步事故复盘：一帧偏差引起的连锁反应

在我做过的一个动作类项目中，上线测试不到一周就收到玩家反馈：对战过程中偶尔会出现"我这边明明把人打飞了，对方屏幕上人没飞"的灵异事件。启动快照校验后发现，两个客户端从第N帧开始Hash不一致，往后越差越大。

我拿到录像后，在调试工具里逐帧跑，发现第N帧之前完全一致，从第N帧开始玩家B的客户端少执行了一次伤害结算。顺着代码排查，最终定位到问题根源：玩家B的角色在那一帧同时受到A的普通攻击和B自己的反击技能的碰撞判定，而碰撞判定的处理顺序依赖于一个Dictionary遍历。虽然之前明确纪律"逻辑层不许用Dictionary遍历"，但那次是美术资源加载需求，临时用了Dictionary存怪物ID和实体引用，忘了排序，结果遍历顺序在天时地利人和的条件下产生了差异。

这个问题的教训有两条：第一条，排查不同步一定要从第一帧不同步的地方开始，逐帧比对两个客户端的输入和状态，而不是从当前差异往前猜；第二条，纪律要写进CR（Code Review）检查单，哪怕一行临时代码，只要碰了逻辑层，必须过一遍确定性检查。

5.2 网络抖动与操作延迟的平衡

商业项目里，网络抖动是躲不过的。玩家手机可能在Wi-Fi和4G之间切换，可能进电梯，可能被人打电话占带宽。如果帧缓存只有3帧，一次200ms的抖动就会导致逻辑帧暂停，玩家会觉得"卡了一下"。

我的取舍经验是：帧缓存深度不设死值，而是根据当前网络质量动态调整。网络好时缓存2帧，玩家操作延迟低；网络差时逐步升到4到5帧，优先保证逻辑不卡住。代价是操作延迟会上升，但总比不同步强。与此同时，客户端要做"乐观预测"，玩家本地按下操作立刻执行，不等服务器确认，这个机制能大幅掩盖小抖动带来的延迟。

提示：网络抖动时最容易出现帧号空洞，也就是某一帧的指令没人上报。处理空洞的原则是：逻辑帧必须连续推进，如果某帧没有输入，就当作"所有人空操作"处理，绝不能跳过帧号。我见过新人在接收帧处做了"如果某一帧没到就跳过等下一帧"的逻辑，结果不同步问题一夜之间全部复发。

5.3 断线重连状态怎么恢复

断线重连是帧同步项目里最麻烦的工程问题之一。玩家打着打着切到后台，再回来时已经过了好几帧，如果一直用"从断线那一帧开始追"的方式，历史帧的输入可能已经丢失，缓存也无法无缝恢复。

我采用的方案是重连时重新整局同步：重连客户端向服务器请求当前权威快照，服务器把当前帧号、世界状态快照、从当前帧起未来数帧的输入一并下发给重连客户端。客户端用快照重建逻辑世界，直接跳转到最新帧继续跑。这样做的好处是简单可靠，坏处是重连客户端会丢失断线期间的本地表现细节，但对玩家来说，"我还活着、局势没乱"比"操作剧情被回放一遍"重要得多。快照数据的大小可控在几十KB以内，即使每帧都有单位位置、血量、Buff，用紧凑的二进制序列化仍然很快。

5.4 性能优化：逻辑层计算量控制

帧同步把完整逻辑放在每个客户端跑，这意味着某些原本由服务器集中承担的计算压力，现在由每个玩家承担。如果一个复杂技能在服务器状态同步里只算一次，到了帧同步里，每个客户端都要算一遍。所以逻辑层的性能优化是必须的。

我用过最有效的手段是"分帧计算"：把大量计算摊到多帧执行，比如一次寻路分几帧走完，而不是一帧内走完一整条路径。另外，逻辑层对象池非常重要，频繁创建销毁对象是GC压力的主要来源，GC的STW停顿在战斗中出现，很可能导致逻辑帧超时。

还有一个容易忽略的点：逻辑层和表现层的Update要分开处理。逻辑层固定频率跑，表现层尽量仰赖插值而不是每帧向逻辑层查数据。如果把逻辑查询放到了表现层每帧执行，Unity的MonoBehaviour.Update顺序在平台上有不确定性，虽然不影响逻辑结果，但可能造成表现帧率浪费。

6. 最后分享一点实际使用中的心得体会

说了这么多原理和框架，最后聊点实在的。我入行时接手过一个帧同步项目，代码里到处都是Mathf和Time.deltaTime，当时导师说这项目迟早出事，果然后来测试阶段就频繁不同步。后来大家痛下决心重写逻辑层，全面换定点数，约法三章：逻辑层不碰Unity API、不用Dictionary遍历、所有随机走统一接口。改完以后，同项目组的QA连续跑了五百局对局，校验Hash一次都没红过。这让我深刻体会到，帧同步的技术难点不在"想出方案"，而在"守住纪律"。方案是公开的、写出来谁都看得懂，但能在三个月、半年的迭代周期里让团队每个人写代码时都记得确定性这回事，才是真正的工程挑战。

如果你准备在项目里用帧同步，我的建议是：先把逻辑层和表现层彻底分离这件事做到位，再把定点数、确定性随机、帧缓存这三个基础模块一次做好，后面全靠这套地基顶住业务迭代的压力。开发过程中遇到不同步，不要慌，用"最早差异帧定位法"顺着Hash不匹配的那一帧往下查，大多数问题半小时内就能找到根源。这套框架和排查方法在我经历的几个项目中反复使用，每一次都能用得上。希望这篇分享能帮你在帧同步的路上少踩几个我踩过的坑。