去同步
同步失调（Desync）是指玩家本地的游戏画面与服务器的权威状态不再一致的情况。玩家在某一位置看到对手，而服务器上对手却在另一个位置，这导致射击无法命中、角色瞬间移动以及位置被拉回。这属于偏差问题而非速度问题，这也是它与延迟（lag）的区别所在。
又称
去同步化
，
什么是两种不同类型的不同步？
玩家用同一个词来形容两种不同的故障，而这两者的修复方法并无重叠。在 GDC 2001 上发表的两篇论文仍然对这两者进行了描述：Yahn Bernier 在 Valve 关于延迟补偿的工作，以及 Paul Bettner 和 Mark Terrano 在 Ensemble Studios 关于步进同步的 1500 Archers on a 28.8。
复制不同步（Replication desync）发生在具有权威服务器的游戏中。客户端预测将要发生的事情，服务器表示不同意，然后客户端被纠正。玩家会看到角色瞬间回弹或子弹穿过某人。
确定性不同步（Determinism desync）发生在步进同步游戏中，其中每台机器都运行相同的模拟，并且只发送输入。机器会比较其状态的校验和，当数字不再匹配时，没有权威副本可以退回。会话随之停止。
第二种情况有其专门的错误信息。“发生不同步（A desync has occurred）”是玩家搜索的确切词条，通常针对《麦登橄榄球 26（Madden NFL 26）》或《大学橄榄球 26（College Football 26）》等热门游戏。
了解你的游戏属于哪一种情况，就已经完成了大部分工作。
实践中 - 来自 Edgegap 博客的见解
文章的核心洞察
不同步是分歧，而非延迟：滞后（Lag）意味着信息到达较晚。不同步（Desync）意味着两台机器保存着相同世界的不同版本，这是一个具有独立解决方案的独立故障。
存在两种截然不同的类型：复制不同步（Replication desync），即权威服务器纠正预测错误的客户端；以及确定性不同步（Determinism desync），即对等端模拟产生分歧，导致会话直接停止。
“橡皮筋”效应有两个控制杠杆：客户端预测错误的频率（由延迟决定），以及每次纠正的明显程度（由网络代码决定）。调整其中任何一个，玩家看到的“橡皮筋”现象都会减少。
tick 率并不是这两个杠杆之一：提高 tick 率并不会使预测更准确，而且在已经丢包的连接上，它反而会使画面异常情况更加严重。
“发生不同步”是校验和失败：帧同步（Lockstep）游戏在每回合都会比较状态哈希值，因此一个分歧的浮点数或一个未同步的随机调用都会导致会话终止。
为什么会出现网络回弹（网络拉回）？
画面拉回（Rubberbanding）是屏幕上正在修正的一种复制同步异常。它是由两个因素相乘导致的：客户端猜错的频率，以及每次猜错的明显程度。
第一个因素由延迟决定。客户端与服务器之间的每一毫秒，都是客户端根据自己的预测进行模拟的时间。在 60 Hz 的模拟速率下，距离服务器 30 毫秒的客户端会比确认帧提前大约两帧运行。在 180 毫秒时，它会提前大约十一帧运行。同样的代码，相同的引擎，暴露的风险大约是原来的五倍。抖动（Jitter）和 packet loss（丢包）会加剧这种情况，因为丢失输入意味着服务器在完全没有玩家操作的情况下向前推进。
第二个因素由网络代码（netcode）决定。当服务器出现分歧时，回滚（Rollback）会倒退到最后一个确认帧，重新模拟会从该帧开始向前重新播放玩家的输入，而呈现平滑处理则会将剩余的部分混合在几帧中，而不是直接传送。如果处理得当，大多数修正都非常接近玩家已经处于的位置，以至于没有人会注意到。
这两个杠杆互不替代。在 200 毫秒延迟下，优秀的网络代码仍然会产生可见的修正。而在没有预测（prediction）的游戏中，即使路由很短，仍然会让人感觉反应迟钝。
为什么更高的服务器刷新率不能解决不同步问题？
寻找基础设施解决方案的工作室通常会首先考虑Tick率（tick rate）。但这是一个错误的着力点。
Tick率决定了服务器解析和广播游戏世界的频率。提高Tick率可以为命中检测提供更精准的时机。但它对预测准确性毫无帮助，因为准确性取决于模拟代码以及哪些输入到达了服务器，而不是服务器通信的频率。在已经丢包的连接上，更高的Tick率意味着有更多的数据包会被丢弃，而修正信息也会更频繁地到达。
能够解决不同步问题的基础设施杠杆是延迟。将服务器放置在更靠近比赛玩家的位置，无需发布补丁即可缩小网络代码需要解决的问题。Edgegap的不同步原理解析对这两种杠杆进行了全面的分析。
服务器能阻止不同步吗？
出于不同的原因，专用服务器会改变这两种情况。
对于复制不同步，它是恢复路径。当客户端漂移过远时，服务器可以停止发送增量（即仅传输已更改内容的常用方法），转而推送完整状态。客户端的分歧副本会被重写。这会消耗带宽，因此它只是特例，但它能将损坏的会话转化为短暂的卡顿。
对于确定性不同步，它改变了架构。同步锁步会话在不匹配时结束，因为没有哪台机器有权否决其他机器。在中间有一个权威服务器的情况下，根据设计就存在了一个单一的事实来源。
服务器本身并不能缩短与玩家的距离，也不能让预测变得多余。它为您提供了一个您可以拥有、可以检测并可以纠正的状态。
来自我们的赞助商（其实就是我们自己！）的寄语
大多数延迟来自距离，而非代码。Edgegap 的边缘云是一个分布式网络，按需提供高达 615+ 个可用位置，因此每场比赛都能在最适合玩家的可用位置运行。对直播工作室流量的独立重放测试表明，与公共云相比，平均往返时间减少了 58%。
延迟同步（Desync）何时属于作弊行为？
有时报告不同步的玩家正是导致不同步的人，而点对点（P2P）游戏最容易暴露这一问题。正如 Edgegap 关于 P2P 隐藏成本的指南所涵盖的那样，当一名玩家的机器托管比赛时，没有中立第三方来确认任何人的操作。玩家还会搜索如何故意触发不同步，并且在某些平台上，这个词甚至代表了一种漏洞利用（exploit）。
2025 年 10 月，Roblox 开发者 loleris 在 Roblox 开发者论坛上报告了一个在游戏中传播的“不同步”漏洞。利用该漏洞者的位置仍然会传送给服务器，但停止向其他玩家复制，因此“服务器看到你在环内，但所有其他客户端看到你在遥远的某个地方”。Roblox 工作人员复现了该问题并发布了修复程序。
这里的教训在于权威（authority）的存在位置。只有当循环中的服务器是决定结果的服务器时，它才会有所帮助。任何信任客户端报告的内容（从其自身位置到比赛结果），都是客户端可以伪造的。
这并不需要重型服务器。拥有超过 4000 万次下载的手机游戏 Bloody Bastards (Tibith Ltd, 2026) 曾采用点对点模式运行，且比赛结果信任主机。该案例研究描述了作弊行为猖獗，以及追溯到该架构的不同步问题。Tibith 转向了 Edgegap 上的小型、无头（headless）权威服务器，并报告自 5.0.0 版本以来没有作弊成功的案例。对于那些本不需要完整专用服务器的游戏，裁判可以建立在像 Edgegap 的 LightNet（一个底层的 Unity 网络库）这样轻量级的东西上，不过裁判的规则仍需由开发者来编写。
Edgegap 的观点（仅代表个人意见，姑且听之即可！）
Edgegap 的观点
当玩家报告“不同步”时，这个词本身能提供的信息微乎其微。而具体的症状才能告诉你该由谁来修复。
以“发生不同步”而中止的游戏会话属于模拟漏洞。任何服务器、地区或刻率（tick rate）都无法解决它，因为两台机器进行了不同的数学计算。
角色瞬间回弹属于预测差距。较低的延迟可以缩小这一差距，而更好的协调机制可以使其变得不那么明显。
隐形或无法被击中的玩家属于权限差距。某些原本信任客户端的数据应该由服务器来决定。
在分配工作之前，先按症状对报告进行分类，这样每项任务都能准确分派给能够真正解决它的团队。
，
