1. 为什么我选择死磕 UE5 网络同步与 Coop 实现第一次把 UE5 的 Coop 项目跑起来的时候我盯着屏幕上两个角色互相穿模、位置瞬移、开火特效各放各的画面脑子里只有一个念头这玩意儿比单机难十倍不止。单机游戏里你写个SetActorLocation角色就老老实实过去了一旦进了网络环境同样的代码在客户端和服务器上跑出来的结果可能完全不一样甚至同一个变量在两台机器上的值能差出半个地图。这就是 UE5 网络同步要解决的核心问题。它本质上是一套状态复制Replication机制让服务器作为权威Authority把游戏状态同步给所有客户端同时让客户端的输入能可靠地传回服务器处理。而 Coop合作模式则是这套机制最典型的应用场景——两到四个玩家一起打怪、解谜、推图每个人的操作都要实时反映在别人的屏幕上延迟还得控制在可接受范围内。这篇文章适合谁看如果你已经会用 UE5 做单机项目蓝图和 C 都能写一点但一碰到Replication、RPC、Dedicated Server这些词就头大那这篇就是写给你的。我会从架构设计讲到具体代码从GetLifetimeReplicatedProps讲到Server RPC的坑把我在实际项目里踩过的雷一个个拆开给你看。全程不整虚的能直接抄的代码我都放出来。先说结论UE5 的网络同步不是开个开关就能用的东西它需要你在写每一行逻辑的时候都问自己一句——这段代码是在服务器跑还是客户端跑跑了之后状态怎么同步想清楚这两个问题Coop 就成了一半。2. 网络同步的底层逻辑与架构选型2.1 权威服务器模型为什么服务器说了算UE5 的网络架构采用权威服务器模型Authoritative Server Model这是理解一切同步问题的前提。简单说就是服务器是唯一说了算的人客户端只是提建议的。你按下 W 键想往前走客户端不会直接让你走而是发一个请求给服务器说我想往前走服务器验证没问题后才把你往前走了这个结果同步给所有客户端。这个设计的好处是防作弊。如果客户端能直接决定自己的位置那改个内存就能瞬移。但代价是客户端需要预测Client Prediction否则你按下 W 键要等一个 RTT往返延迟才能看到角色动手感会烂到没法玩。UE5 的CharacterMovementComponent内置了预测和回滚机制这也是为什么角色移动通常不需要你手动写同步逻辑——引擎已经帮你处理了。但其他东西就没这么幸运了。血量、弹药、任务进度、门开没开、Boss 放没放技能这些都需要你手动配置复制。我见过太多新手把血量写成普通变量结果客户端打怪不掉血因为伤害计算在客户端跑了服务器根本不知道。记住一句话任何影响游戏世界状态的逻辑都必须在服务器上执行。客户端只负责输入和表现。2.2 Dedicated Server vs Listen Server选哪个UE5 支持两种服务器模式对比项Dedicated ServerListen Server服务器角色独立进程无本地玩家某个玩家兼任服务器性能高不受玩家设备影响受主机玩家设备性能限制作弊难度高玩家无法接触服务器低主机玩家可作弊开发调试稍麻烦需单独启动方便直接 PIE 多窗口适用场景正式发布、竞技类局域网、合作PVE、原型验证我的建议是开发阶段用 Listen Server 快速迭代发布前切 Dedicated Server 做最终测试。UE5 的 PIEPlay In Editor支持直接模拟多客户端加一个服务器调试效率极高。你可以在编辑器里设置Number of Players为 3Net Mode选Play As Listen Server一键就能跑起三人 Coop。切 Dedicated Server 的时候要注意服务器上没有PlayerController的本地实例所有IsLocallyControlled()的判断都会返回 false。很多在 Listen Server 上跑得好好的代码一到 Dedicated Server 就崩就是因为没处理好这个差异。2.3 复制系统的三种同步方式UE5 的网络同步本质上就三种手段搞清楚它们的分工你就不会乱属性复制Property Replication用于同步持续存在的状态比如血量、位置、弹药数。你只需要在变量上标记Replicated然后在GetLifetimeReplicatedProps里注册引擎就会自动在值变化时同步。注意是值变化时如果值没变引擎不会浪费带宽。RPCRemote Procedure Call用于同步一次性事件比如开火、放技能、捡道具。RPC 分三种Server RPC客户端调服务器执行Client RPC服务器调客户端执行Multicast RPC服务器调所有客户端执行。RPC 不可靠默认走 UDP但可以标记Reliable保证到达。RepNotify复制通知是属性复制的增强版当属性同步到客户端时会自动调用一个回调函数。这个特别适合做血量变化时更新 UI这类需求省得你每帧去检查。三者配合使用才能覆盖所有场景。举个例子玩家开火客户端调Server RPC通知服务器服务器验证弹药足够后扣弹药属性复制同步给所有客户端同时调Multicast RPC播放开火特效和音效。这一套下来所有玩家看到的画面就是一致的。3. 核心同步机制的代码实现细节3.1 属性复制的完整配置流程先看一个最基础的血量同步例子。假设你有一个ACoopCharacter类头文件里这样写// CoopCharacter.h #pragma once #include CoreMinimal.h #include GameFramework/Character.h #include CoopCharacter.generated.h UCLASS() class COOPGAME_API ACoopCharacter : public ACharacter { GENERATED_BODY() public: ACoopCharacter(); protected: // 血量标记为可复制 UPROPERTY(ReplicatedUsing OnRep_Health, BlueprintReadOnly, Category Stats) float Health; // 最大血量初始化后不变不需要 RepNotify UPROPERTY(Replicated, BlueprintReadOnly, Category Stats) float MaxHealth; // 复制回调 UFUNCTION() void OnRep_Health(); public: virtual void GetLifetimeReplicatedProps(TArrayFLifetimeProperty OutLifetimeProps) const override; UFUNCTION(BlueprintCallable, Category Stats) void ApplyDamage(float DamageAmount); };实现文件里// CoopCharacter.cpp #include CoopCharacter.h #include Net/UnrealNetwork.h ACoopCharacter::ACoopCharacter() { Health 100.0f; MaxHealth 100.0f; bReplicates true; // 关键开启 Actor 复制 } void ACoopCharacter::GetLifetimeReplicatedProps(TArrayFLifetimeProperty OutLifetimeProps) const { Super::GetLifetimeReplicatedProps(OutLifetimeProps); // 注册需要复制的属性 DOREPLIFETIME(ACoopCharacter, Health); DOREPLIFETIME(ACoopCharacter, MaxHealth); } void ACoopCharacter::OnRep_Health() { // 血量同步到客户端时触发更新 UI UpdateHealthUI(Health); } void ACoopCharacter::ApplyDamage(float DamageAmount) { // 只有服务器能扣血 if (!HasAuthority()) return; Health FMath::Clamp(Health - DamageAmount, 0.0f, MaxHealth); if (Health 0.0f) { // 处理死亡逻辑 OnDeath(); } }这里有几个关键点新手特别容易漏第一bReplicates true必须设。我见过有人属性配了半天没效果最后发现 Actor 本身没开复制。这个在构造函数里设一次就行。第二GetLifetimeReplicatedProps必须调Super::。不调的话父类的复制属性全丢角色移动都会出问题。第三ApplyDamage里的HasAuthority()检查不能省。客户端调用这个函数时直接 return保证只有服务器能改血量。如果你在客户端也改了会出现客户端显示掉血但服务器不知道的情况下一帧同步回来血量又跳回去画面会闪。3.2 RPC 的正确使用姿势与常见陷阱RPC 是 Coop 里用得最多的同步手段但它的坑也最多。先看一个标准的开火 RPC// 头文件里声明 UFUNCTION(Server, Reliable, WithValidation) void ServerFire(); UFUNCTION(NetMulticast, Unreliable) void MulticastPlayFireEffect();// 实现 void ACoopCharacter::ServerFire_Implementation() { // 服务器验证弹药够不够、是否在冷却 if (CurrentAmmo 0 || !CanFire()) return; CurrentAmmo--; // 属性复制自动同步 // 通知所有客户端播放特效 MulticastPlayFireEffect(); // 服务器做射线检测算伤害 PerformLineTrace(); } bool ACoopCharacter::ServerFire_Validate() { // 返回 false 会断开客户端连接 return true; } void ACoopCharacter::MulticastPlayFireEffect_Implementation() { // 所有客户端都会执行播放特效和音效 PlayFireMontage(); SpawnMuzzleFlash(); }WithValidation是防作弊的关键。服务器收到 RPC 后会先调_Validate函数返回 false 直接踢人。你可以在里面检查参数合法性比如伤害值是不是负数、坐标是不是在合理范围内。虽然默认返回 true 也能跑但正式项目一定要写验证逻辑。Reliable和Unreliable的选择有讲究。开火这种关键事件用Reliable保证一定到达特效播放用Unreliable丢一帧无所谓反而能省带宽。我试过把特效也设成Reliable结果网络一卡特效 RPC 堆积延迟反而更高。Multicast在 Dedicated Server 上有个坑如果服务器上没有对应的 Actor 实例比如服务器不加载特效资源Multicast可能不会执行。这种情况需要用NetMulticast配合bNetLoadOnClient处理或者干脆用Client RPC逐个发。3.3 变量同步的时机控制与带宽优化不是所有变量都需要每帧同步。UE5 默认的复制频率是每秒 30 次左右但你可以通过NetUpdateFrequency调整// 构造函数里设置 NetUpdateFrequency 10.0f; // 每秒同步10次适合不重要的 Actor MinNetUpdateFrequency 2.0f; // 最低频率对于 Coop 游戏我通常这样分配Actor 类型NetUpdateFrequency理由玩家角色30-60位置和动作要流畅敌人15-20稍微卡顿可接受掉落物5基本不动场景道具2几乎不变还有一个高级技巧是条件复制Conditional Replication。比如血量只在变化时同步而不是每帧都发DOREPLIFETIME_CONDITION(ACoopCharacter, Health, COND_None);COND_None表示总是复制但你可以用COND_OwnerOnly只同步给拥有者或者COND_SkipOwner跳过拥有者。对于 Coop 游戏队友的血量通常需要所有人看到所以用默认的COND_None就行。但如果是私密信息比如某个玩家的任务进度用COND_OwnerOnly能省不少带宽。4. Coop 玩法逻辑的完整实现路径4.1 玩家加入与角色生成的同步流程Coop 游戏最基础的需求是玩家 A 创建房间玩家 B 加入两人能看到对方的角色。这个流程涉及GameMode、PlayerController和GameState的配合。GameMode只在服务器上存在负责处理玩家登录和角色生成// CoopGameMode.cpp void ACoopGameMode::PostLogin(APlayerController* NewPlayer) { Super::PostLogin(NewPlayer); // 通知所有客户端有新玩家加入 if (AGameStateBase* GS GetGameStateAGameStateBase()) { // GameState 的属性复制会自动同步给客户端 CoopGameState-PlayerCount; } } void ACoopGameMode::Logout(AController* Exiting) { Super::Logout(Exiting); // 处理玩家离开 }GameState用来同步全局状态比如玩家数量、任务进度、Boss 血量// CoopGameState.h UCLASS() class COOPGAME_API ACoopGameState : public AGameStateBase { GENERATED_BODY() public: UPROPERTY(ReplicatedUsing OnRep_PlayerCount, BlueprintReadOnly) int32 PlayerCount; UPROPERTY(Replicated, BlueprintReadOnly) float BossHealth; UFUNCTION() void OnRep_PlayerCount(); };这里有个经验GameState 的复制是自动的但你需要确保bReplicates true。另外GameState在客户端上也会存在一个实例但只有服务器能修改它的属性。客户端读到的值都是服务器同步过来的。玩家加入的完整时序是这样的客户端连接服务器 → 服务器PostLogin被调用 →GameMode生成PlayerController→PlayerController生成Pawn→Pawn的BeginPlay在服务器和客户端分别执行 → 属性复制开始工作。理解这个时序你就能知道该在哪个环节写什么逻辑。4.2 交互物件的同步门、宝箱、机关Coop 游戏里最常见的交互就是开门、开宝箱、踩机关。这类物件的同步有个特点状态是布尔值但触发是一次性事件。以门为例// CoopDoor.h UCLASS() class COOPGAME_API ACoopDoor : public AActor { GENERATED_BODY() public: UPROPERTY(ReplicatedUsing OnRep_IsOpen, BlueprintReadOnly) bool bIsOpen; UFUNCTION(BlueprintCallable) void Interact(AActor* Interactor); UFUNCTION() void OnRep_IsOpen(); UFUNCTION(NetMulticast, Reliable) void MulticastPlayOpenAnimation(); };// CoopDoor.cpp void ACoopDoor::Interact(AActor* Interactor) { // 只有服务器能改变门的状态 if (!HasAuthority()) return; if (bIsOpen) return; bIsOpen true; // 属性复制自动同步给所有客户端 MulticastPlayOpenAnimation(); // 播放动画 } void ACoopDoor::OnRep_IsOpen() { // 客户端收到状态变化更新碰撞和视觉 if (bIsOpen) { SetActorEnableCollision(false); } }关键点交互逻辑必须在服务器执行。客户端按 E 键时不要直接改bIsOpen而是通过Server RPC请求服务器。我见过有人图省事在客户端直接改结果两个玩家同时开门服务器和客户端状态不一致门卡在半开状态。宝箱的逻辑类似但多了一个每个玩家只能开一次的需求。这时候需要用TArray记录已开启的玩家UPROPERTY(Replicated) TArrayAPlayerState* OpenedByPlayers; bool ACoopChest::CanOpen(APlayerState* PlayerState) { return !OpenedByPlayers.Contains(PlayerState); }TArray的复制需要注意UE5 支持TArray复制但只同步变化的部分。如果数组很大建议用FastArraySerializer优化。4.3 敌人 AI 的服务器权威与客户端表现敌人 AI 是 Coop 同步里最复杂的部分。核心原则AI 逻辑只在服务器跑客户端只负责表现。// CoopEnemy.cpp void ACoopEnemy::Tick(float DeltaTime) { Super::Tick(DeltaTime); // AI 逻辑只在服务器执行 if (!HasAuthority()) return; // 寻找最近玩家、移动、攻击 UpdateAIBehavior(DeltaTime); }客户端的敌人位置是通过CharacterMovementComponent的复制同步过来的。但这里有个问题如果网络延迟高客户端看到的敌人位置会比服务器慢半拍导致你明明打中了却判定没中。解决方案是客户端预测 服务器回滚。UE5 的CharacterMovementComponent内置了这套机制但只对玩家角色生效。敌人需要你手动处理或者用Network Prediction插件UE5.1 之后的新系统。我的做法是敌人位置用插值平滑伤害判定以服务器为准。客户端开枪时服务器根据自己那边的敌人位置算伤害客户端看到的命中特效只是表现。这样虽然偶尔会出现明明打中了却没伤害的情况但至少不会出现打空气却掉血的诡异现象。对于 Boss 战这种需要精确同步的场景我会把 Boss 的技能释放做成Multicast RPC让所有客户端在同一时间播放技能特效然后服务器在技能释放后 0.5 秒再结算伤害。这样即使有延迟玩家看到的画面也是同步的。5. 网络调试与性能优化的实战经验5.1 常用调试命令与工具UE5 提供了一堆网络调试命令我常用的这几个// 显示网络统计信息 stat net // 显示网络相关性 stat netrelevancy // 显示复制属性 net.ShowReplicatedProperties // 模拟网络延迟 Net PktLag100 Net PktLagVariance20 // 模拟丢包 Net PktLoss5Net PktLag是我调试时必开的模拟 100ms 延迟能暴露大部分同步问题。很多在局域网跑得好好的逻辑一加延迟就露馅。还有一个神器是Network Profiler在编辑器里打开Window - Developer Tools - Network Profiler能抓取一段时间内的网络流量看到底是哪个 Actor 在疯狂发包。我有个项目带宽一直降不下来用 Profiler 一抓发现是个特效 Actor 的NetUpdateFrequency设成了 100改成 10 之后带宽直接降了 40%。5.2 带宽优化与相关性管理Coop 游戏的带宽压力主要来自三个方面角色移动、敌人同步、特效 RPC。优化手段按优先级排第一设置合理的NetUpdateFrequency。不是所有东西都需要 60Hz 同步。玩家角色 30Hz 足够敌人 15Hz 就行道具 5Hz 都嫌多。第二用NetPriority控制优先级。当带宽不够时引擎会优先同步NetPriority高的 Actor。玩家角色的NetPriority默认是 1.0你可以把敌人设成 0.5道具设成 0.2。第三开启相关性Relevancy。UE5 默认只同步玩家附近的 Actor远处的不同步。你可以通过NetCullDistanceSquared调整这个距离NetCullDistanceSquared FMath::Square(5000.0f); // 50米内才同步对于 Coop 游戏队友的位置需要始终同步所以要把队友的NetCullDistanceSquared设大一点或者用bAlwaysRelevant true。第四压缩 RPC 参数。能用uint8就别用int32能用FVector_NetQuantize就别用FVector。FVector_NetQuantize会把坐标压缩到厘米精度带宽能省一半。5.3 常见同步问题的排查思路问题一客户端角色不动但服务器上在动。排查检查CharacterMovementComponent的bReplicates是否为 true检查GetLifetimeReplicatedProps是否调了Super::。如果都没问题看看是不是NetUpdateFrequency设得太低。问题二RPC 不执行。排查检查 RPC 是否在HasAuthority()正确的端调用。Server RPC只能在客户端调Client RPC只能在服务器调。调反了不会报错但也不会执行。另外检查Reliable的 RPC 是否因为缓冲区满了被丢弃。问题三属性同步了但 UI 不更新。排查RepNotify函数名是否和ReplicatedUsing里写的一致。UE5 对大小写敏感OnRep_Health和Onrep_Health是两个不同的函数。另外RepNotify只在值变化时触发如果服务器设了同样的值客户端不会收到通知。问题四Dedicated Server 上崩溃。排查检查所有IsLocallyControlled()的调用服务器上没有本地控制的 PlayerController。检查GetPlayerController(0)的调用服务器上可能返回 nullptr。检查 UI 相关的代码服务器上不应该有 UI。6. 从零搭建 Coop 项目的完整流程6.1 项目配置与插件准备新建 UE5 项目时选Third Person模板C 项目。然后在Edit - Plugins里确认这几个插件已启用OnlineSubsystem网络子系统基础OnlineSubsystemUtils提供CreateSession、FindSessions等蓝图节点Networking网络相关的基础模块DefaultEngine.ini里加上[/Script/Engine.GameEngine] NetDriverDefinitions(DefNameGameNetDriver,DriverClassName/Script/OnlineSubsystemUtils.IpNetDriver,DriverClassNameFallback/Script/OnlineSubsystemUtils.IpNetDriver) [OnlineSubsystem] DefaultPlatformServiceNull [/Script/OnlineSubsystemUtils.OnlineSessionSettings] bUsesPresencefalseDefaultGame.ini里设置项目名称和版本[/Script/EngineSettings.GeneralProjectSettings] ProjectNameCoopGame ProjectVersion1.0.06.2 创建会话与加入会话的代码实现创建会话的蓝图节点在OnlineSubsystemUtils里但 C 实现更可控// CoopGameInstance.cpp void UCoopGameInstance::CreateCoopSession(int32 MaxPlayers) { IOnlineSubsystem* OnlineSub IOnlineSubsystem::Get(); if (!OnlineSub) return; IOnlineSessionPtr SessionInterface OnlineSub-GetSessionInterface(); if (!SessionInterface.IsValid()) return; FOnlineSessionSettings SessionSettings; SessionSettings.NumPublicConnections MaxPlayers; SessionSettings.bShouldAdvertise true; SessionSettings.bAllowJoinInProgress true; SessionSettings.bIsLANMatch true; // 局域网测试用 SessionInterface-OnCreateSessionCompleteDelegates.AddUObject( this, UCoopGameInstance::OnCreateSessionComplete); SessionInterface-CreateSession(0, NAME_GameSession, SessionSettings); }加入会话类似用FindSessions搜索局域网内的房间然后JoinSession。这部分代码比较长但逻辑很直接照着官方文档抄就行。6.3 测试与验证的完整清单项目搭好后按这个清单逐项验证PIE 多窗口测试Number of Players 3Net Mode Play As Listen Server确认三个窗口都能看到彼此的角色。延迟测试开Net PktLag100确认角色移动、开火、交互都正常。丢包测试开Net PktLoss5确认关键 RPC 不丢特效偶尔丢失可接受。Dedicated Server 测试打包服务器版本用命令行启动-server -log客户端连接测试。断线重连测试客户端中途断开确认服务器能正确处理Logout其他玩家不受影响。我每次改完网络相关代码都会跑一遍这个清单。有一次偷懒没跑 Dedicated Server 测试结果发布后才发现服务器上有个GetPlayerController(0)返回 nullptr 导致崩溃回滚版本折腾了一整天。7. 我踩过的那些坑与独家经验7.1 新手最容易犯的五个错误错误一在客户端改状态。这是最致命的。任何Health--、bIsOpen true、Score都必须包在if (HasAuthority())里。我建议你养成习惯写任何修改状态的代码前先问自己这是服务器吗。错误二RPC 参数用FString。FString的复制开销极大能不用就不用。用FName或者枚举代替。如果非要传字符串考虑用FText或者压缩后的uint8索引。错误三忘记Super::GetLifetimeReplicatedProps。这个错误特别隐蔽因为不报错只是父类的属性不同步。角色移动出问题的时候第一个要检查的就是这里。错误四RepNotify里做重逻辑。OnRep_Health里不要做复杂的计算或者生成 Actor它可能在网络抖动时被频繁调用。重逻辑放到Tick或者专门的函数里。错误五Dedicated Server 上加载 UI。服务器没有屏幕所有CreateWidget、AddToViewport的调用都要包在if (!IsDedicatedServer())里。我见过有人在BeginPlay里无条件创建 HUD服务器直接崩。7.2 性能优化的三个关键指标带宽Bandwidth每个客户端的下行带宽控制在 50KB/s 以内上行 20KB/s 以内。超过这个数移动网络下就会卡。延迟LatencyCoop 游戏 100ms 以内算优秀200ms 可接受超过 300ms 玩家会明显感觉到打不中。CPU 占用服务器的NetTick时间控制在 2ms 以内。如果超过 5ms说明复制逻辑太重需要优化。监控这些指标用stat net和stat unit打包版本里可以用-log参数输出到日志文件。7.3 从单机到 Coop 的代码重构建议如果你已经有一个单机项目想改成 Coop我建议按这个顺序重构先加bReplicates true把所有需要同步的 Actor 标记上。再配属性复制从血量、位置这些基础属性开始。然后加 RPC把开火、交互这些事件改成 RPC。最后处理 AI把 AI 逻辑移到服务器端。测试每改一步就测一次不要攒着一起测。重构过程中最常见的坑是单例和全局变量。单机项目里用GetGameInstance()存数据没问题但 Coop 里GameInstance在每个客户端上都是独立的服务器改的数据不会自动同步。这种情况要把数据移到GameState或者PlayerState上。8. 进阶方向与扩展思路8.1 网络预测与回滚的深入应用UE5.1 之后引入了Network Prediction插件提供了比CharacterMovementComponent更通用的预测框架。你可以用它来预测技能释放、投射物轨迹、甚至载具物理。这个插件学习曲线陡峭但一旦掌握能做出来的同步效果比传统方案好一个档次。我目前只在载具项目里用过效果确实好但配置复杂需要把预测的逻辑写成纯函数还要处理PredictionKey的传递。如果你的项目对同步精度要求极高值得投入时间研究。8.2 专用服务器的部署与运维Dedicated Server 打包出来后需要部署到服务器上。UE5 支持 Linux 服务器打包命令# Windows 打包 Linux 服务器 RunUAT.bat BuildCookRun -projectCoopGame.uproject -noP4 -platformLinux -server -serverconfigShipping -cook -build -stage -archive -archivedirectoryBuild部署时注意服务器需要开放 UDP 端口默认 7777需要配置防火墙需要写启动脚本自动重启。这些运维细节虽然和游戏逻辑无关但直接决定项目能不能上线。8.3 跨平台 Coop 的注意事项如果要做 PC 和主机跨平台 Coop需要注意输入映射不同主机用手柄PC 用键鼠UI 提示要动态切换。帧率不同主机 30fpsPC 可能 144fps网络同步频率要取中间值。平台限制某些平台不允许跨平台联机需要提前确认。我做过一个 PC 和主机跨平台的项目最大的坑是手柄的摇杆输入精度和键鼠不一样导致角色移动速度在两端表现不一致。解决方案是在服务器端做输入归一化把摇杆输入映射到和键鼠相同的范围。这个内容后续还可以这样扩展如果你对网络同步的底层原理感兴趣可以去读 UE5 源码里的NetDriver.cpp和ReplicationGraph.cpp这两个文件是理解整个复制系统的钥匙。我花了大概两周时间啃完虽然不能全懂但对排查问题帮助极大。另外ReplicationGraph是 UE5 针对大世界 Coop 的优化方案如果你的项目地图很大、玩家很多一定要研究这个。
