UE客户端预测必须走CharacterMovementComponent的ServerMove流程，绕过会导致预测失效；需确保复制启用、调用ClientMove、服务端校验、平滑纠错而非瞬移，并用net命令调试。
客户端预测必须走 CharacterMovementComponent 的 ServerMove 流程
UE 的移动预测不是靠你自己在 Tick() 里算位置实现的，而是深度绑定在 CharacterMovementComponent 的网络移动管线中。如果你绕过它、自己用 SetActorLocation() 或 AddMovementInput() 在客户端强行更新位置，预测就会失效——服务器根本不知道你“以为”自己在哪，后续校正无从谈起。
关键点在于：客户端调用 ServerMove() 发送输入帧（含时间戳、位移、旋转、是否跳跃等），服务端收到后执行完整移动模拟（碰撞检测、斜坡判定、地面约束等），再把结果通过 ReplicatedMovement 打包回传。整个链路是引擎内置的，不能跳过。
- 确保
bReplicates = true且CharacterMovementComponent::bReplicates = true - 客户端必须调用
ClientMove()（通常由输入系统触发），它会自动打包并调用ServerMove() - 服务端重载
ServerMove_Implementation()做规则校验（比如禁止穿墙、速度封顶），不通过就直接丢弃该帧 - 不要在客户端
Tick()中修改GetActorLocation()或GetVelocity()—— 这些值应始终来自ReplicatedMovement或预测插值结果
位置纠错不能用瞬移，得靠 SmoothCorrection + 阻尼控制
当客户端收到服务器回传的 OnRep_ReplicatedMovement()，发现本地预测位置和服务器权威位置偏差超过阈值（比如 >10cm），直接 SetActorLocation() 会导致角色“抽搐”或“瞬移”。UE 提供了内置的平滑机制，但默认参数往往不合适，必须手动干预。
真正起作用的是 CharacterMovementComponent::SmoothCorrection()，它内部使用阻尼插值（damped spring）逼近目标位置。但它的衰减系数硬编码在组件属性里，容易导致纠错太慢（漂移残留）或太快（抖动明显）。
立即学习“C++免费学习笔记（深入）”；
- 在 C++ 构造函数中调整：
GetCharacterMovement()->NetworkSmoothingMode = ENetworkSmoothingMode::Disabled;（先关掉默认逻辑） - 重载
OnRep_ReplicatedMovement()，手动调用FVector::VInterpTo()或带阻尼的FMath::VInterpTo_Constant() - 推荐用
FMath::VInterpTo_Constant(Current, Target, DeltaTime, Speed)，Speed设为 2000–5000（单位 cm/s），具体看角色移动速度和网络 RTT - 避免在纠错过程中触发物理模拟（如
SetActorLocation(..., true)带 sweep），否则可能卡进几何体
预测失败时的回滚必须限定范围，且不可累积浮点误差
有些项目尝试在预测失败时“回滚到上一帧 + 重放输入”，这在 UE 中极难安全实现。因为 CharacterMovementComponent 的模拟不是完全确定性的（受浮点精度、Tick 时间微差、物理子步长影响），多次回滚会导致位置漂移越来越严重。
UE 官方推荐路径是“预测 → 服务器校验 → 不一致则平滑修正”，而非“预测 → 回滚 → 重模拟”。只有在极少数场景（如射击命中判定）才需要服务端缓存输入帧做回滚，且必须严格限定只对位置/旋转做，不涉及动画、音效、UI 等非确定性模块。
- 服务端若需回滚（例如验证子弹命中），只保留最近 16–32 帧的
FInputSnapshot，超出即丢弃 - 回滚模拟必须用固定时间步长（
FixedDeltaSeconds = 1/60.f），禁用DeltaTime动态变化 - 所有参与回滚的向量运算必须用
FVector::Equals()而非==判断相等，避免浮点误差误判 - 客户端绝不自行保存历史位置用于“比对回滚”，只依赖服务器下发的
ReplicatedMovement和时间戳
调试预测与纠错最有效的三个命令
光看代码逻辑很难定位预测是否生效、纠错是否过猛。UE 内置的 net 统计命令能直接暴露问题根因，比打断点更高效。
-
stat net：查看每帧同步数据量、RPC 调用次数、ReplicatedMovement更新频率。如果RepMovement更新间隔 >100ms，说明同步条件太严或网络卡顿 -
netdump <actorname></actorname>：输出指定 Actor 的完整复制状态，确认ReplicatedMovement是否被标记为 Replicated，以及NetUpdateFrequency是否合理（默认 100Hz，FPS 类项目建议设为 60–120） -
show collision+show net：开启后，客户端能看到自己预测位置（白线）、服务器位置（红线）、插值轨迹（虚线），直观判断漂移方向和纠错强度
真正难的不是写对这几行代码，而是理解 ServerMove() 和 OnRep_ReplicatedMovement() 之间那几十毫秒里，引擎到底做了什么——它在等网络包、在做碰撞、在裁剪数据、在插值，而你写的每一行 SetActorLocation() 都可能悄悄覆盖掉这个链条里的某个环节。
