企业官网建设流程全解析

要说清楚CMC（CharacterMovementComponent）这套网络移动流程，绕不开“服务器回包 → 客户端回滚 → 重放追平”这三个节点。很多项目跑在单机上一切正常，一上联调就出状况：角色明明在客户端往前跑，突然被“拽”回十几帧前的位置，或者朝一个方向按方向键，但人像踩了冰一样滑来滑去。这些现象背后不是简单的网络抖动，而是预测与实际服务器判定产生了偏差，客户端收到回包后必须以某个规则把本地状态拉回去，再用历史输入重新把位置追回来。

我在之前那篇里把客户端预测和移动输入的上半段链路讲完了，这篇正好接上后半程：服务器回包到达客户端之后，客户端怎么理解这个包，什么时候该回滚，回滚之后怎么重放才能让玩家几乎无感。如果你正在做UE5的多人联机，或者被角色的“瞬移式拉扯”折磨过，这篇应该能帮你把整条链路彻底捋顺。

1. 为什么移动预测需要“回包—回滚—重放”这套组合拳

1.1 客户端先跑，服务器仲裁：预测同步的基本模型

UE的角色移动在单机环境下没有任何分歧：玩家按方向键，CharacterMovementComponent直接驱动角色往前，碰撞、斜坡、浮空、落地都是同一个进程里一套物理模拟算出来的。但一旦进入多人联机，服务器成了绝对的裁决者，所有玩家看到的角色最终位置必须由服务器说了算。

问题是，如果每个操作都必须等服务器算完再回传，高延迟下玩家会明显感觉到“按了方向键但角色不走”。为了消除这种操作延迟，UE默认启用客户端预测：客户端在本地立刻模拟一遍移动，让角色回馈玩家的操作；同时把这一帧的移动输入、时间戳、状态打包发给服务器，服务器也拿着同一份输入在自己的世界里模拟一遍。

这种“客户端先跑，服务器仲裁”的模型，本质上就是让操作反馈和逻辑权威分离。玩家是即时被满足的，服务器则负责确认你是否真的能走到那个位置。

1.2 偏差不是Bug，是时延的必然产物

大多数刚入门的开发者会问：既然客户端和服务器用的是同一套移动逻辑，输入也完全一致，那结果为什么还会不一样？

原因很现实：两端的模拟环境不是一致的。首先是网络延迟，客户端发出移动请求到服务器收到，中间有几十到几百毫秒的间隔，这期间客户端自己又跑了若干帧，输入队列和时间戳已经先走了一步；其次是碰撞数据差异，客户端加载的地形、静态网格、其他玩家的占位，和服务器上实际结算的几何数据可能不同；再就是物理性的外部扰动，比如角色站在移动平台上，平台位移在两端同步有时间差，或者下一秒服务器上某个玩家把门关上了，客户端还在按“门开着”的状态预测移动。

这些偏差不是某个环节“写错了”，而是时延和分布式环境的必然产物。只要网络不是零延迟、两端状态不是逐字节相同，客户端预测出来的位置和服务器权威算出来的位置就一定会有差距。

1.3 三个阶段的职责划分

有了偏差，就需要一封“权威信”回到客户端：“你刚才那几步走得不对，我的结果是这个位置。”这封信就是回包；客户端收到后，不能直接以为是网络包抖动然后忽略，它必须把本地角色放回服务器认可的时间点上，这就是回滚；但光回滚是不够的，因为在等待服务器的这段时间里，玩家又持续按了新的方向、按了跳跃，这些输入不能丢掉，要在一个修正过的起点上重新执行一遍，这就是重放追平。

这就是标题里那三个箭头的含义：服务器回包带来了权威快照，客户端回滚建立了新的基准，重放追平则让客户端在“尊重服务器”的前提下不丢失玩家后续操作。三者缺一不可，如果只做回包不做回滚，角色位置永远停留在预测错误状态；如果做回滚却不重放，玩家明显感觉到角色“往后缩了一截”且之后的输入全部断档。

2. 服务器回包链路：从ServerMove到客户端回调

2.1 ServerMove请求里到底装了什么

客户端预测跑完一帧后，会把移动数据通过CharacterMovementComponent::ReplicateMoveToServer打成RPC发给服务器，也就是ServerMove。这个RPC内部不是简单传一个“我当前在X点”，而是传了一组压缩过的运动数据，包含客户端本地的时间戳、移动模式、旋转、跳跃状态、加速度、控制输入等。

这里的关键是时间戳。客户端发给服务器的时间戳，必须在客户端和服务器之间保持相对一致的语义，否则服务器无法判断“这一帧移动发生在哪个时刻”。在实际项目中，我见过有人直接把服务器时间拿来当锚点，结果回包对不齐，修正位置永远差一截。正确做法是客户端用自己这套移动逻辑的时间戳序列，服务器在回包时原样带回来，再用这个时间戳去和本地SavedMove队列匹配。

服务器收到ServerMove后也不是直接信任它：先做基础校验，比如时间戳是否合法、移动请求频率是否过密、速度是否异常。UE源码里这部分包含了针对作弊和异常请求的基础防护，正常情况下这些校验会直接放行。

2.2 服务器是怎么“算”你的移动

服务器把客户端送来的移动输入交给MoveAutonomous执行一次增量模拟。它不会直接把角色SetActorLocation到你上报的位置，而是按输入重新走一遍加速、减速、扫掠、碰撞等逻辑。

这样说可能比较抽象，我举个具体的例子。客户端预测时，它认为门是开的，于是侧着身钻进门口跑到了房间里；服务器在收到这个移动请求时，门已经被另一个玩家关上了，那么在服务器上做同样的移动模拟，就会在门框位置碰壁，速度被阻挡、位置停在门外。这个结果就是服务器判定出来的权威结果。

另外，服务器上的物理环境也不是固定不变的。角色可能撞到其他玩家、被远程攻击击退、脚下的移动平台改变方向，这些都会让服务器端算出和客户端完全不同的轨迹。服务器不会“通知客户端‘你算错了’”，它只是把这次移动模拟后的最终状态整理好，准备回包。

2.3 回包的具体形态：AckGoodMove与ClientUpdatePositionAfterServerUpdate

服务器模拟完一个或连续多个移动请求后，会向客户端发回确认包。这里有两种形态，区分它们特别重要。

第一种是ClientAckGoodMove，服务器认为客户端预测的结果“没问题”，位置、速度、移动模式基本一致，于是承认这一帧移动。客户端收到后要做的事情很简单：把对应时间戳之前的SavedMove清掉，表示这些移动已经得到服务器认可，不需要回滚。

第二种是ClientUpdatePositionAfterServerUpdate（实践中常见路径还包括内部调用ClientAdjustment），服务器发现客户端预测结果与自己的权威结果有明显偏差，于是把一组修正数据带回客户端。这组数据里最关键的有：服务器计算出的位置、旋转、速度、移动模式，以及服务器处理到的那一帧时间戳。这个包对应着标题里的“服务器回包”，也是客户端回滚的直接触发点。

回包频率并不等于移动频率。服务器可以连续处理多个ServerMove之后，把确认结果合并成一次回包发回客户端。这也解释了为什么网络条件差的时候，客户端不会每个移动请求都收到一个修正包，而是一段时间后突然收到一个较大的修正包，然后角色被“拉”一大截。

3. 客户端回滚：以服务器快照为基准恢复权威状态

3.1 回滚的本质不是传送，而是校准

我第一次看回滚代码时，第一反应是“那就把角色SetActorLocation到服务器位置呗”，后来发现这个理解太危险了。如果你只是把一个瞬移指令丢给角色，客户端玩家看到的就是角色突然被拽到另一个位置，然后后续输入全部失效，手感完全断裂。

回滚的本质是“建立一个从服务器确认点重新开始计算的基准”。在这个基准之上，客户端后续还会通过重放把玩家没被服务器看到的输入补回来，所以回滚这一步做得越精确，重放的效果就越自然。

在UE内部，收到修正包后执行的回滚并非由Actor层直接把位置写死，而是在CharacterMovementComponent内部做状态校正：把当前组件的位置、速度、旋转、移动模式更新为服务器回包带回来的值，同时把需要重放的SavedMove队列按时间戳切分好，准备进入重放阶段。

3.2 回滚时到底要恢复哪些状态

不少开发者以为回滚只需要“把位置改对”，实际上远不止这些。一个完整的回滚需要恢复以下内容：

• 位置：服务器权威算出的坐标，这是修正包的绝对重点；
• 旋转：角色朝向如果错位，重放输入时的方向判断会全部出错；
• 速度向量：速度不仅是移动快慢，还影响加速度、跳跃初速度的叠加；
• 移动模式：走、跑、飞行、游泳、落下，回滚时如果模式不对，重放会走到完全错误的分支；
• 脚下基座：如果角色站在某个移动平台上，基座信息也要还原，不然平台带着角色走时，两边对不上；
• 跳跃状态：是否刚起步跳、跳了第几段、蓄力状态等。

在我实际项目中，碰到最多的问题是回滚时只改了位置和速度，忽略了移动模式，重放时角色明明应该还在空中，却走了Ground模式的分支，结果直接“瞬移落地”。所以，第三步一定要检查服务器回包里带回来的MoveMode是否被应用了。

3.3 回滚对相机、动画、物理的连带影响

回滚不只影响CharacterMovementComponent内部状态，对相机和动画也有明显的连带效应。默认情况下，相机是跟着角色走的，回滚意味着角色位置发生了一次“不合常规”的变化，SpringArm和Camera如果不做平滑，画面会瞬间跳一下。

处理思路一般有三种：一是让相机也做一个短时间的插值，从当前跟随位置平滑过渡到角色新位置；二是把相机更新延迟到重放完成之后再执行，减少跳变压入感；三是明确接受“网络修正时出现瞬间跳变”作为代价，这在快速动作类游戏里较少被接受，在慢节奏项目里反而问题不大。

动画方面，角色位置突变会导致动画蓝图的Locomotion状态、脚部IK、着地判断同步错位。我看到不少项目的做法是在回滚发生后短暂锁定“移动匹配”功能，让角色动画在重放完成前不强行贴合地面，避免角色模型与胶囊体明显分离。物理体则要更加谨慎，回滚时不要强制修改正在模拟中的物理刚体的位置，否则容易引发穿透和爆炸式的约束反弹。

4. 重放追平：把等待期间的输入按顺序补回来

4.1 SavedMove与PendingMove：客户端的时间记忆

要理解重放，先看客户端是怎么记忆移动历史的。客户端每次产生一个移动输入周期，就会把它保存成一个FSavedMove结构，放进SavedMove队列；这个队列记录了每一帧玩家按了什么键、给出了什么加速度、处于什么状态。同时还有一个“当前正在累积”的移动，就是PendingMove。

SavedMove队列实际上就是客户端自己的一份“操作账本”。服务器确认了某一帧时间戳，客户端就可以把这一帧之前的SavedMove从队列里清掉；而修正包到达时，客户端需要回头找出：从服务器确认的时间戳到现在，有哪些输入是服务器还没见过的，这些就是需要重放的内容。

这里经常有人混淆：SavedMove里存储的是一系列输入指令，不是移动后的位置坐标。重放不是“把这些位置连起来”，而是“把输入指令在修正后的起点上重新执行”，所以SavedMove的时间戳、输入参数完整性直接影响重放结果。

4.2 从回滚点到当前帧的重放循环

重放的执行入口在CharacterMovementComponent::MoveAutonomous，它会把回滚点之后的SavedMove依次取出，再重新跑一遍移动模拟。每一次MoveAutonomous都相当于把那一帧的输入“补投”到新的起点上，然后由物理、扫掠、阻挡重新结算。

重放循环中有个容易被忽略的细节：每一条SavedMove都带着自己的时间戳，重放时不能把每条Move当成“瞬间完成”，而要按照它们原本的DeltaTime累加消耗时间。这样，重放的物理过程才保持和客户端最初预测时的帧率节奏接近，而不是把一堆增量在零时间内挤完。

UE在这里对单步模拟时长也有限制，比如MaxSimulationTimeStep会把单步模拟的时间步控制在一定范围内，避免因重放步长过大而明显穿透物体或者产生异常的物理反应。简单来说，重放不是“一键把后面几帧全部结算完”，而是一小步一小步地补，和正常预测的步长尽量保持同构。

4.3 重放为什么会有“穿墙”和“卡地面”的坑

重放场景里最常见的坑，一个是穿墙，一个是卡地面。

穿墙的典型过程是：服务器修正回了一个新位置，这个新位置和客户端后续几帧要执行的输入之间存在一个差值，如果重放时的扫掠查询没有正确拿到最新的碰撞数据，角色就会从墙边或门缝中直接穿过去。问题根源多数发生在SafeMove与触发器、异步物理数据的组合上，特别当重放步长偏大时，角色可能一跨跨进了另一侧碰撞体中，抵消了扫掠的保护效果。

卡地面的典型过程是：回滚点落在了其他物体内部，或者重放过程中角色被压在新的遮挡物下方，导致连续多帧无法正常模拟。这种情况下不只是表现异常，角色甚至可能陷入持续SmoothedMove失败的循环。调试时可以先关闭参与碰撞的复杂几何体，用简单碰撞体排查是哪部分几何引入了异常。

另一个让重放频繁出问题的是移动模式切换。如果回滚时MoveMode没恢复好，重放会在错误的分支上执行：明明服务器认为是空中，重放却按走地逻辑处理，结果角色垂直掉落到地板上；反之亦然。这也是为什么我在3.2节里特别强调“移动模式必须随回滚恢复”。

4.4 追平之后的自然收敛与手感恢复

重放完成后，角色所在的最终位置，就是客户端在当前时间点上最合理的显示位置。理想情况下，这个位置距离服务器的权威位置不会太远，玩家只会感到角色有一瞬间的轻微顿挫。

追平后的手感恢复也值得注意。重放结束后，客户端并不是“回到预测状态”，而是从修正好后的位置重新开始后续移动。这时候如果玩家的输入方向持续保持一致，角色继续执行新的预测即可；如果输入方向已经变化，那么重放后的第一帧就会带上新的控制输入，和正常操作没有任何区别。

要验证重放是否正确，看位置收敛趋势就很直观：每次修正包处理后，客户端角色的最终位置应该越来越接近服务器权威位置。如果发现角色“越修正越远”，大概率是时间戳切分出了问题，部分输入被重放了两次或者被错误丢弃了。

5. 实测调优：让回滚和重放腰杆硬起来

5.1 关键参数：容差、步长、移动频率怎么设

联机移动同步绕不开几个核心参数。首先是AGameNetworkManager::ClientErrorCorrection，它控制客户端位置误差的修正容差。简单说，如果客户端预测位置与服务器权威位置的距离小于这个容差，服务器不会触发修正包，客户端也不需要回滚；容差调大，修正包触发变少，手感更顺滑，但偏差会更大；容差调小，修正更频繁，精度更高，但玩家更容易察觉角色被轻微拉回。

其次是MaxSimulationTimeStep，它限制单次模拟的时间步长上限。重放时如果原始帧耗时较大，会被拆成多个小步执行，降低穿墙和卡地面的概率，但代价是会消耗更多CPU。项目中如果你的角色经常在复杂几何地形中重放，值可以适当调小；如果角色场景很简单，保持默认就好。

还有一个容易被忽视的是移动发送频率。ServerMove不会无脑每帧都发一个，而是会和客户端的移动步调对齐。客户端帧率越高，一段时间内产生的移动请求越多，服务器处理压力越大，回包也可能被合并。在做大世界游戏时，可以考虑降低移动请求频率，让每个包携带更多增量信息，但压缩和解码的复杂度会上升。

参数没有“最佳”只说，必须在手感和精度之间反复试。实际操作时，我一般是先把p.NetShowCorrections打开，把修正可视化和频率用眼睛先看一遍，再根据修正频率和表现调整容差。

5.2 可用的调试命令与可视化技巧

做移动同步调试，几个控制台命令几乎每天都要用：

• p.NetShowCorrections 1：在视口显示客户端和服务器位置修正情况，绿色表示预测正确，红色表示产生了修正，线条长度直观反映偏差大小；
• p.NetPktLag=100：模拟100ms延迟，配合p.NetPktLoss测不同延迟下的回滚频率；
• showdebug movement：显示角色当前MovementMode、速度、加速度等关键信息，回滚后看这里能立刻发现模式是否错了；
• stat CharacterMovement：显示移动模拟耗时，重放时如果这个数字明显升高，说明保存的SavedMove队列太长了。

调试时建议先用p.NetPktLag和丢包组合模拟一个“很差”但可复现的网络环境，然后观察修正线的分布。如果修正线集中在某个固定区域，比如某个门、某个斜坡上，说明这块区域的碰撞数据在客户端和服务器间不一致，回滚和重放的问题多半不是逻辑问题，而是场景数据没有同步好。

5.3 网络条件差时的常见异常与对症方案

延迟较高或者丢包明显时，客户端会积累很长的SavedMove队列，重放需要的时间随之变长，CPU消耗也会上升。同时回滚频率变大，角色可能被频繁拉回，看起来就像“人物在抽搐”。

针对这类现象，常见的缓解手段有：

• 收紧单次修正的幅度，让小幅偏差通过客户端本地平滑来吸收，而不是每次偏差都触发一次完整回滚；
• 降低预测移动的最大速度或加速度，让客户端预测时别一次性冲太远，减少和服务器判定的差距；
• 增加服务器对移动请求的处理节流，防止极端网络下客户端一次性塞入大量请求；
• 增加客户端“丢弃超时输入”的手段，把积压过量、已经明显不适用于当前状态的SavedMove部分作废，而不是全部重放。

这里要特别提醒一个细节：不要为了追求“看起来同步得很准”而在低延迟机器上把容差调到极小，因为你最终要跑的玩家网络环境远没有本机好。我自己做过的最傻的一次就是把容差调到了零点几厘米，单机测试特别完美，一上公网玩家侧延迟超过80ms就疯狂回滚，走路像踩弹簧。调参必须瞄准目标网络延迟的中位数来调。

6. 一些个人的经验碎碎念

我带的项目里，大部分移动同步问题追根溯源都不在“回包—回滚—重放”这套主体逻辑上，而是差在数据准备阶段：要么是某个碰撞体在客户端被剔除，要么是移动模式切换没纳入回滚范围，要么是时间戳没有按统一语义对齐。只要这三块不出错，整条链路其实很皮实。

调试的时候别把眼光只钉在“角色位置”上，多看速度和移动模式的变化曲线。很多时候位置看起来没问题，但速度值已经在服务器和客户端之间错开了，下一帧就会突然产生一个修正包。把速度、移动模式、时间戳这三样东西先对齐，再把位置差异交给重放去收敛，问题会好找得多。

如果你读到这里才发现对客户端预测的上半段链路还不太熟，建议先把SavedMove的生成、预测的发起机制补一补。回滚和重放能不能顺利执行，很大程度取决于预测时给SavedMove记的账够不够完整——账记错了，回滚和重放无论如何都追不回来。