UE5多人FPS网络同步实战：客户端预测与服务器回滚机制详解

1. 多人FPS网络同步的整体设计思路

1.1 为什么FPS游戏的网络同步这么难做

UE5的多人FPS网络同步，说白了就是让几个甚至几十个玩家在各自的屏幕上看到大致一样的战场画面，同时保证每个人的操作都能被服务器认可并广播给其他人。这件事听起来简单，做起来极其折磨人。FPS游戏对延迟的容忍度极低，角色移动、开火、命中判定这些操作，玩家对哪怕50毫秒的偏差都能感知到。你如果做过单机FPS，转过来做多人，第一件要接受的事就是：客户端永远在“撒谎”，服务器才是唯一的真相。

UE5提供了一套基于客户端-服务器权威模型的网络架构，核心组件包括GameMode、GameState、PlayerState、PlayerController、GameInstance以及Actor的复制系统。这套架构的设计哲学是：服务器拥有最终决定权，客户端只负责发送输入和接收状态。但FPS游戏的特殊性在于，如果完全按照服务器权威来做，玩家按下W键到角色真正移动，中间要经历“客户端发送输入→服务器处理→服务器广播位置→客户端接收并渲染”这一整圈，延迟高的时候角色会像在冰面上滑行。

所以UE5的FPS网络同步方案必须引入客户端预测和服务器回滚这两个核心机制。客户端预测是指客户端在发送输入后，不等服务器确认就先行模拟角色移动，让操作手感即时响应；服务器回滚是指服务器在收到客户端输入后，将角色状态回滚到该输入对应的时刻，重新模拟并校正。这套机制在UE5的CharacterMovementComponent里已经内置了，但很多开发者不知道它的存在，或者不知道怎么调参，导致同步效果一塌糊涂。

1.2 核心组件选型与职责划分

在动手写代码之前，先把各个类的职责理清楚。我见过太多项目把所有逻辑塞进PlayerController或者Character里，后期维护起来简直是灾难。

这个划分的核心逻辑是：能放PlayerState的不要放Character，能放GameState的不要放GameMode。因为GameMode只在服务器存在，客户端读不到；Character的复制频率高，塞太多数据会撑爆带宽。PlayerState和GameState是专门为网络复制设计的，同步效率更高。

1.3 网络更新频率与带宽预算

UE5默认的网络更新频率是每秒30次（NetUpdateFrequency = 30），对于FPS游戏来说，角色移动的更新频率建议拉到60甚至更高。但这里有个坑：不是所有Actor都需要高频率更新。武器、投射物、可交互物件的更新频率可以降到10-15，因为它们的移动轨迹相对可预测。

带宽预算方面，一个16人的FPS对战，每个玩家的角色移动数据（位置、旋转、速度、姿态）大约占用每秒2-4KB，加上武器开火、命中判定、动画状态同步，总带宽大概在每秒50-80KB。如果你的服务器上行带宽是100Mbps，理论上能支撑1000个以上的玩家，但实际受限于CPU处理RPC和属性复制的开销，单服建议控制在64人以内。

注意：NetUpdateFrequency和MinNetUpdateFrequency要配合使用。前者是理想更新频率，后者是网络拥塞时的最低频率。FPS角色建议设为60和30，武器设为15和5。

2. 角色移动同步的核心细节与实操要点

2.1 CharacterMovementComponent的预测机制解析

UE5的CharacterMovementComponent（简称CMC）是FPS网络同步的基石。它内置了一套完整的客户端预测+服务器校正流程，但很多人只用了它的表面功能，没吃透它的工作原理。

CMC的预测机制是这样的：客户端每帧调用PerformMovement，将移动结果存在SavedMoves数组里，同时把移动输入（加速度、旋转、跳跃等）打包成FSavedMove_Character发送给服务器。服务器收到后，调用MoveAutonomous重新模拟，如果模拟结果和客户端上报的位置偏差超过阈值，就通过ClientAdjustPositionRPC把客户端拉回正确位置。

这里的关键参数是MAXPOSITIONERRORSQUARED，默认值是100（即10厘米的误差）。对于FPS游戏，这个值可以适当放宽到400（20厘米），因为过于严格的校正会导致角色频繁抖动，尤其是在网络波动时。但也不能太大，否则会出现“穿墙”或者“隔空击杀”的视觉欺骗。

// 在Character的构造函数中调整CMC参数 GetCharacterMovement()->MaxSimulationTimeStep = 0.016f; // 60Hz模拟步长 GetCharacterMovement()->MaxSimulationIterations = 4; // 最大迭代次数 GetCharacterMovement()->NetworkMaxSmoothUpdateDistance = 100.f; // 平滑更新距离 GetCharacterMovement()->NetworkNoSmoothUpdateDistance = 200.f; // 不平滑更新距离

NetworkMaxSmoothUpdateDistance和NetworkNoSmoothUpdateDistance这两个参数控制的是服务器校正时的平滑处理。当偏差小于前者时，客户端会平滑过渡到正确位置；当偏差大于后者时，直接瞬移。FPS游戏建议把前者设小一点（50-100），后者设大一点（200-300），这样小偏差不会造成视觉抖动，大偏差能快速纠正。

2.2 移动输入的网络传输与优化

UE5默认的移动输入传输是通过ServerMoveRPC实现的，每帧发送一次。但FPS游戏有个特殊需求：移动输入必须和开火、瞄准等操作保持时序一致。如果移动输入延迟了，但开火指令先到了服务器，就会出现“人在墙后却被打中”的争议。

解决方案是把移动输入和战斗输入打包在同一个RPC里发送，或者使用FCharacterNetworkMoveData结构体扩展自定义数据。UE5的CharacterMovementComponent支持通过FCharacterNetworkMoveDataContainer来扩展网络移动数据，你可以把瞄准方向、开火状态、武器切换请求都塞进去。

// 自定义网络移动数据 USTRUCT() struct FMyCharacterNetworkMoveData : public FCharacterNetworkMoveData { GENERATED_BODY() UPROPERTY() FVector_NetQuantizeNormal AimDirection; UPROPERTY() bool bIsFiring; virtual void ClientFillNetworkMoveData(const FSavedMove_Character& ClientMove, ENetworkMoveType MoveType) override { Super::ClientFillNetworkMoveData(ClientMove, MoveType); const FMySavedMove* MyMove = static_cast<const FMySavedMove*>(&ClientMove); AimDirection = MyMove->AimDirection; bIsFiring = MyMove->bIsFiring; } virtual bool Serialize(UCharacterMovementComponent& CharacterMovement, FArchive& Ar, UPackageMap* PackageMap, ENetworkMoveType MoveType) override { Super::Serialize(CharacterMovement, Ar, PackageMap, MoveType); Ar << AimDirection; Ar << bIsFiring; return !Ar.IsError(); } };

这样做的好处是移动和战斗输入共享同一个时间戳，服务器可以精确还原玩家在某一时刻的完整状态。代价是每个移动包的大小增加了约12-16字节，但在60Hz的更新频率下，额外带宽消耗在可接受范围内。

2.3 服务器校正的平滑处理与视觉欺骗

服务器校正最怕的就是“拉回”感。玩家明明已经跑到掩体后面了，服务器突然把他拉回开阔地，这种体验极其糟糕。UE5提供了几种平滑校正的方式，但需要手动配置。

第一种是位置平滑，通过NetworkMaxSmoothUpdateDistance控制。当校正距离小于这个值时，客户端不会瞬移，而是以一定速度插值到正确位置。这个速度由NetworkSmoothingMode决定，FPS游戏建议用Exponential模式，插值速度设为10-15。

第二种是旋转平滑，通过NetworkSmoothingMode和NetworkSmoothingTime控制。旋转校正比位置校正更敏感，因为视角的突然转动会让玩家眩晕。建议把旋转平滑时间设为0.1-0.15秒，让视角缓慢转过去。

第三种是动画欺骗，这是FPS游戏的独门技巧。当服务器校正发生时，如果角色正在播放移动动画，可以临时切换到“被击中”或“踉跄”动画，掩盖位置突变。这个技巧在《守望先锋》和《Apex英雄》里都有使用，UE5的动画蓝图可以通过AnimNotify和Montage来实现。

实操心得：服务器校正的频率不要太高。如果每秒校正超过3次，说明客户端的预测逻辑有问题，或者网络延迟太高。优先检查MaxSimulationTimeStep和MaxSimulationIterations是否合理，前者建议0.016，后者建议4。

3. 武器开火与命中判定的网络实现

3.1 开火指令的RPC设计与防作弊

FPS游戏的开火判定是网络同步的重灾区。最简单的做法是客户端开火后发送ServerFireRPC，服务器验证后广播MulticastFire给所有客户端播放特效。但这样做有个致命问题：客户端可以伪造开火指令，比如修改内存让开火频率翻倍，或者在没有弹药的情况下开火。

防作弊的第一道防线是服务器验证。服务器收到ServerFire后，必须检查：弹药是否足够、武器是否在冷却、玩家是否存活、开火方向是否合理。这些检查必须在服务器执行，客户端只负责发送“我想开火”的请求。

// 服务器端开火验证 void AMyWeapon::ServerFire_Implementation() { // 检查弹药 if (CurrentAmmo <= 0) { ClientFireRejected(EFireRejectReason::NoAmmo); return; } // 检查冷却 if (GetWorld()->GetTimeSeconds() - LastFireTime < FireRate) { ClientFireRejected(EFireRejectReason::Cooldown); return; } // 检查玩家状态 AMyCharacter* OwnerCharacter = Cast<AMyCharacter>(GetOwner()); if (!OwnerCharacter || OwnerCharacter->IsDead()) { ClientFireRejected(EFireRejectReason::Dead); return; } // 验证通过，执行开火 CurrentAmmo--; LastFireTime = GetWorld()->GetTimeSeconds(); MulticastFire(OwnerCharacter->GetActorLocation(), OwnerCharacter->GetBaseAimRotation()); }

第二道防线是开火频率限制。服务器要记录每个玩家的开火时间戳，如果两次开火间隔小于武器射速的80%，就判定为异常。这个阈值不能设得太死，因为网络抖动会导致RPC到达时间不均匀，建议留20%的容差。

第三道防线是方向验证。服务器收到开火方向后，要和玩家角色的实际朝向做对比。如果偏差超过30度，说明客户端可能在自瞄。这个检查要结合延迟补偿来做，因为玩家在移动中开火时，客户端朝向和服务器朝向本来就有偏差。

3.2 命中判定的服务器回滚与延迟补偿

FPS游戏的命中判定必须做延迟补偿，否则高延迟玩家永远打不中低延迟玩家。UE5的延迟补偿核心是ServerRewind机制：服务器收到开火指令后，把所有其他玩家的角色位置回滚到开火者当时的视角时刻，然后做射线检测。

具体实现步骤：

1. 客户端开火时，记录当前的世界时间戳ClientFireTime。
2. 服务器收到ServerFireRPC后，计算RewindTime = ClientFireTime - ServerTimeOffset。
3. 服务器遍历所有其他角色，调用RewindToTime(RewindTime)把他们的位置恢复到那个时刻。
4. 执行射线检测，判断是否命中。
5. 恢复所有角色的当前位置。

UE5的CharacterMovementComponent提供了FSavedMove_Character数组，里面存储了角色过去1秒内的移动历史。你可以通过遍历这个数组来找到对应时间点的位置。

// 延迟补偿的射线检测 void AMyWeapon::PerformHitScan(const FVector& Start, const FVector& End, float RewindTime) { TArray<FHitResult> HitResults; FCollisionQueryParams QueryParams; QueryParams.bTraceComplex = true; QueryParams.bReturnPhysicalMaterial = true; // 回滚所有其他角色 TArray<AMyCharacter*> RewoundCharacters; for (TActorIterator<AMyCharacter> It(GetWorld()); It; ++It) { AMyCharacter* OtherChar = *It; if (OtherChar == GetOwner()) continue; if (OtherChar->RewindToTime(RewindTime)) { RewoundCharacters.Add(OtherChar); } } // 执行射线检测 GetWorld()->LineTraceMultiByChannel(HitResults, Start, End, ECC_Pawn, QueryParams); // 恢复角色位置 for (AMyCharacter* Char : RewoundCharacters) { Char->RestoreFromRewind(); } // 处理命中结果 for (const FHitResult& Hit : HitResults) { AMyCharacter* HitChar = Cast<AMyCharacter>(Hit.GetActor()); if (HitChar && HitChar != GetOwner()) { HitChar->ApplyDamage(CalculateDamage(Hit), GetOwner(), Hit); } } }

延迟补偿的最大回滚时间建议设为200-300毫秒。太短了高延迟玩家吃亏，太长了低延迟玩家会觉得“明明躲到墙后了还被杀”。这个值要根据目标玩家的平均延迟来调，国内服务器建议250毫秒，国际服务器建议300-350毫秒。

3.3 投射物武器的网络同步策略

射线武器（Hitscan）的同步相对简单，因为命中判定是瞬时的。但投射物武器（如火箭弹、手雷）的同步就复杂多了，因为投射物有飞行时间，而且飞行轨迹受物理影响。

UE5的投射物同步有两种方案：

方案一：服务器权威投射物。客户端开火后，服务器生成投射物Actor，通过ReplicateMovement同步位置。客户端只负责播放发射特效，不生成实际投射物。这种方案防作弊最强，但高延迟玩家会看到投射物“延迟出现”。

方案二：客户端预测投射物。客户端开火后立即生成一个“视觉投射物”，同时发送ServerFireRPC。服务器生成权威投射物，并通过MulticastFire通知所有客户端。客户端收到广播后，销毁视觉投射物，改用服务器同步的投射物。这种方案手感好，但需要处理视觉投射物和权威投射物的位置偏差。

我个人的建议是：爆炸类武器用方案一，子弹类武器用方案二。因为爆炸武器的命中判定范围大，延迟几百毫秒影响不大；子弹类武器需要精确命中，手感优先。

// 客户端预测投射物 void AMyProjectileWeapon::ClientFire() { // 立即生成视觉投射物 FActorSpawnParameters SpawnParams; SpawnParams.Owner = GetOwner(); SpawnParams.Instigator = GetInstigator(); AMyProjectile* VisualProjectile = GetWorld()->SpawnActor<AMyProjectile>( ProjectileClass, GetMuzzleLocation(), GetMuzzleRotation(), SpawnParams ); VisualProjectile->SetVisualOnly(true); // 发送服务器请求 ServerFire(); } // 服务器广播 void AMyProjectileWeapon::MulticastFire_Implementation() { // 服务器生成权威投射物 if (GetOwner()->HasAuthority()) { FActorSpawnParameters SpawnParams; SpawnParams.Owner = GetOwner(); SpawnParams.Instigator = GetInstigator(); GetWorld()->SpawnActor<AMyProjectile>( ProjectileClass, GetMuzzleLocation(), GetMuzzleRotation(), SpawnParams ); } // 客户端销毁视觉投射物 // 通过ProjectileID匹配，避免误删 DestroyVisualProjectile(); }

注意事项：投射物的NetUpdateFrequency建议设为20-30，不需要太高。但bReplicateMovement必须开启，否则客户端看不到投射物移动。另外，投射物的碰撞检测要在服务器做，客户端只做视觉表现。

4. 动画同步与状态复制的实战技巧

4.1 动画蓝图的网络同步要点

FPS游戏的动画同步有个基本原则：服务器不跑动画逻辑，只复制动画状态。UE5的动画蓝图默认在服务器和客户端都会执行，但服务器的动画计算是浪费性能的，因为服务器不需要渲染。所以要在动画蓝图里加一个IsDedicatedServer判断，服务器直接跳过动画更新。

// 动画蓝图中的优化 void UMyAnimInstance::NativeUpdateAnimation(float DeltaSeconds) { Super::NativeUpdateAnimation(DeltaSeconds); // 专用服务器跳过动画更新 if (IsDedicatedServer()) { return; } // 客户端和监听服务器正常更新 UpdateMovementAnimation(DeltaSeconds); UpdateCombatAnimation(DeltaSeconds); }

动画状态同步的核心是复制必要的变量，而不是复制动画本身。比如角色的移动速度、方向、是否在空中、是否开火、是否换弹，这些变量通过Replicated属性同步到客户端，客户端根据这些变量驱动动画蓝图。

// Character中需要复制的动画相关变量 UPROPERTY(Replicated, BlueprintReadOnly, Category = "Animation") float Speed; UPROPERTY(Replicated, BlueprintReadOnly, Category = "Animation") float Direction; UPROPERTY(Replicated, BlueprintReadOnly, Category = "Animation") bool bIsInAir; UPROPERTY(Replicated, BlueprintReadOnly, Category = "Animation") bool bIsFiring; UPROPERTY(Replicated, BlueprintReadOnly, Category = "Animation") bool bIsReloading; // 在GetLifetimeReplicatedProps中注册 void AMyCharacter::GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const { Super::GetLifetimeReplicatedProps(OutLifetimeProps); DOREPLIFETIME_CONDITION(AMyCharacter, Speed, COND_SkipOwner); DOREPLIFETIME_CONDITION(AMyCharacter, Direction, COND_SkipOwner); DOREPLIFETIME_CONDITION(AMyCharacter, bIsInAir, COND_SkipOwner); DOREPLIFETIME_CONDITION(AMyCharacter, bIsFiring, COND_SkipOwner); DOREPLIFETIME_CONDITION(AMyCharacter, bIsReloading, COND_SkipOwner); }

COND_SkipOwner这个条件很重要，它表示这些变量不复制给角色拥有者自己。因为拥有者的动画是由本地输入驱动的，不需要服务器同步。如果不加这个条件，拥有者会收到自己的动画状态更新，导致动画抖动。

4.2 动画重定向与多角色共享

UE5的动画重定向（Animation Retargeting）在多人FPS里非常实用。如果你有多个角色皮肤，但他们的骨骼结构不同，就需要用重定向来共享动画资源。UE5的重定向流程是：创建一个IK Rig，定义源骨骼和目标骨骼的对应关系，然后创建IK Retargeter，把源动画蓝图的姿势重定向到目标骨骼。

具体操作步骤：

1. 在内容浏览器右键，选择Animation > IK Rig，创建源角色的IK Rig。
2. 打开IK Rig，在Hierarchy面板中定义骨骼链，比如Spine、Arm、Leg。
3. 创建目标角色的IK Rig，重复上述步骤。
4. 右键选择Animation > IK Retargeter，设置源IK Rig和目标IK Rig。
5. 在Retargeter中调整骨骼映射，确保源骨骼和目标骨骼正确对应。
6. 导出重定向后的动画序列，或者直接在动画蓝图中使用Retargeter节点。

重定向的常见问题是手脚位置偏移，尤其是当源角色和目标角色的比例差异较大时。解决方案是在Retargeter中调整Translation Mode，把手脚的Translation Mode设为None，只保留旋转重定向。这样手脚的位置由IK系统决定，不会因为骨骼长度差异而偏移。

实操心得：重定向后的动画一定要在目标角色上预览，重点检查手指、脚掌、武器挂点这些细节部位。我踩过的坑是重定向后武器挂点偏移了5厘米，导致开火特效从枪管旁边冒出来，排查了半天才发现是挂点骨骼的旋转没重定向对。

4.3 动画Montage的网络播放与同步

FPS游戏里的换弹、近战、技能释放这些一次性动画，通常用AnimMontage来播放。Montage的网络同步有个坑：客户端和服务器播放Montage的时机可能不一致。如果客户端先播放了换弹动画，但服务器还没确认，就会出现“动画播完了但子弹没换”的情况。

正确的做法是：服务器驱动Montage播放。客户端发送ServerReloadRPC，服务器验证后调用MulticastPlayMontage，所有客户端（包括开火者）收到广播后才播放动画。但这样开火者会感觉到延迟，所以需要客户端预测播放：客户端发送RPC后立即播放Montage，如果服务器拒绝，再通过ClientStopMontage回滚。

// 客户端预测换弹 void AMyWeapon::StartReload() { if (CurrentAmmo == MaxAmmo || bIsReloading) return; // 客户端立即播放动画 bIsReloading = true; PlayReloadMontage(); // 发送服务器请求 ServerReload(); } // 服务器验证 void AMyWeapon::ServerReload_Implementation() { if (CurrentAmmo == MaxAmmo || bIsReloading) { ClientReloadRejected(); return; } bIsReloading = true; MulticastReload(); // 设置定时器，动画结束后填充弹药 GetWorld()->GetTimerManager().SetTimer( ReloadTimerHandle, this, &AMyWeapon::FinishReload, ReloadTime, false ); } // 服务器拒绝时回滚 void AMyWeapon::ClientReloadRejected_Implementation() { bIsReloading = false; StopReloadMontage(); }

Montage的同步还要注意Montage_IsPlaying的检查。在MulticastReload里，要先判断Montage是否已经在播放，避免重复播放导致动画重置。另外，Montage的PlayRate要和服务器保持一致，否则不同客户端的动画时长会不一样。

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

5.1 角色位置抖动与回弹的排查

角色位置抖动是FPS网络同步最常见的问题，表现为角色在移动中突然回弹一下，或者站在原地抖动。排查思路如下：

我遇到过一个典型案例：角色在跳跃时频繁回弹，排查后发现是JumpZVelocity在客户端和服务器不一致。客户端用的是修改后的值，服务器用的是默认值，导致每次跳跃服务器都认为客户端作弊。解决方案是把所有移动相关参数放在CharacterMovementComponent的Replicated属性里，或者通过GameMode在服务器统一设置。

5.2 武器开火不同步的排查

武器开火不同步的表现是：自己看到开火了，但队友没看到；或者队友看到开火了，但自己没听到声音。排查要点：

1. 检查RPC的可靠性。ServerFire应该用Reliable，MulticastFire可以用Unreliable。如果MulticastFire丢了，队友就看不到开火特效。但Reliable的RPC不能太频繁，否则会阻塞网络通道。

2. 检查开火特效的挂点。如果特效挂点在不同客户端上位置不一致，说明骨骼同步有问题。检查WeaponMesh的AttachSocket是否在所有客户端上都正确。

3. 检查音频同步。UE5的音频默认是本地播放的，MulticastFire里播放的音效会在每个客户端独立触发。如果音频延迟不一致，可以改用PlaySoundAtLocation并设置bIsUISound = false。

// 可靠的多播开火 UFUNCTION(NetMulticast, Reliable) void MulticastFire(FVector_NetQuantize MuzzleLocation, FRotator MuzzleRotation); void AMyWeapon::MulticastFire_Implementation(FVector_NetQuantize MuzzleLocation, FRotator MuzzleRotation) { // 播放开火特效 if (MuzzleFX) { UGameplayStatics::SpawnEmitterAtLocation( GetWorld(), MuzzleFX, MuzzleLocation, MuzzleRotation ); } // 播放开火音效 if (FireSound) { UGameplayStatics::PlaySoundAtLocation( GetWorld(), FireSound, MuzzleLocation ); } // 播放开火动画 if (FireMontage) { PlayAnimMontage(FireMontage); } }

5.3 网络延迟与丢包的模拟测试

开发阶段一定要模拟高延迟和丢包环境，否则上线后问题会集中爆发。UE5提供了Net PktLag、Net PktLoss、Net PktOrder等控制台命令，可以在PIE（Play In Editor）模式下模拟网络状况。

# 模拟200毫秒延迟 Net PktLag=200 # 模拟10%丢包率 Net PktLoss=10 # 模拟乱序 Net PktOrder=1 # 关闭模拟 Net PktLag=0 Net PktLoss=0 Net PktOrder=0

测试时建议组合使用：Net PktLag=150+Net PktLoss=5+Net PktOrder=1，这基本能覆盖国内4G网络的最差情况。如果在这个条件下游戏还能正常玩，那基本就稳了。

注意：Net PktLag等命令只在PIE和开发版本中有效，Shipping版本会自动忽略。另外，这些命令会影响所有网络连接，包括编辑器自身的网络通信，测试完记得关掉。

5.4 常见问题速查表

6. 性能优化与扩展思考

6.1 网络相关性（Relevancy）与优先级管理

UE5的NetRelevancy机制决定了哪些Actor会复制给哪些客户端。默认情况下，所有Actor都会复制给所有客户端，这在64人战场上会直接撑爆带宽。FPS游戏必须做相关性裁剪：只复制玩家视野范围内的Actor。

// 在GameMode中设置相关性 void AMyGameMode::PostLogin(APlayerController* NewPlayer) { Super::PostLogin(NewPlayer); // 设置网络相关性距离 if (AMyCharacter* Character = Cast<AMyCharacter>(NewPlayer->GetPawn())) { Character->NetCullDistanceSquared = FMath::Square(15000.f); // 150米 Character->NetUpdateFrequency = 60.f; Character->MinNetUpdateFrequency = 30.f; } }

NetCullDistanceSquared是距离平方，15000的平方是2.25亿，对应150米。超过这个距离的Actor不会复制给客户端。但要注意，武器、投射物这些需要精确同步的Actor，NetCullDistanceSquared要设大一点，或者用bAlwaysRelevant = true强制复制。

6.2 网络优先级与带宽分配

当带宽不足时，UE5会根据NetPriority来决定哪些Actor优先复制。NetPriority越高的Actor，更新越频繁。FPS游戏的优先级建议：

• 玩家角色：NetPriority = 3.0
• 武器：NetPriority = 2.0
• 投射物：NetPriority = 1.5
• 可交互物件：NetPriority = 1.0
• 装饰物：NetPriority = 0.5

// 在构造函数中设置优先级 AMyCharacter::AMyCharacter() { NetPriority = 3.0f; NetUpdateFrequency = 60.f; MinNetUpdateFrequency = 30.f; } AMyWeapon::AMyWeapon() { NetPriority = 2.0f; NetUpdateFrequency = 30.f; MinNetUpdateFrequency = 10.f; }

6.3 后续扩展方向

这套同步方案还可以往几个方向扩展。一是帧同步与状态同步的混合，对于回放系统或者观战模式，可以用帧同步来保证完全一致；对于实时对战，继续用状态同步保证响应速度。二是服务器集群与分线，当单服人数超过64人时，可以用World Partition和Server Travel把玩家分散到多个服务器实例，通过GameInstance共享全局数据。三是AI角色的网络同步，AI敌人不需要客户端预测，但需要服务器权威的移动和动画同步，可以复用玩家角色的同步框架，只是把PlayerController换成AIController。

我在实际项目里踩过最大的坑是动画Montage的同步时机。当时换弹动画在客户端播放了，但服务器因为延迟没收到RPC，结果客户端动画播完了子弹没换，玩家以为换好了结果开不了枪。后来改成服务器驱动Montage播放，客户端预测播放但用ClientStopMontage回滚，才彻底解决。这个经验告诉我，FPS网络同步里，任何客户端预测都必须有服务器回滚机制，否则预测就是定时炸弹。