企业官网建设流程全解析

1. 先把五个类的分工理清楚：UE 为什么要把玩家相关的逻辑拆成这么多层

刚开始接触 UE 的时候，我也被这几个类绕晕过。一个玩家进了游戏，为什么要分成 GameInstance、GameMode、GameState、PlayerState、PlayerController 五个类来承载？直接一个类全干了不行吗？后来在做一个四人联机合作项目时被网络同步问题按在地上摩擦了两周，我才真正明白这套拆分逻辑的精妙之处。这五个类不是 UE 为了炫技硬造出来的概念，而是被"单机、局域网联机、专用服务器、多关卡切换"这些真实场景逼出来的一整套职责划分方案。

先把它们各自的身份用一句话定位：GameInstance 是整个游戏进程的全局单例，跨关卡存活；GameMode 是一局游戏的规则裁判，只存在于服务器；GameState 是这局游戏的公开状态公告板，所有端都有；PlayerState 是单个玩家的档案卡，跟着玩家走；PlayerController 是玩家的操作手柄，负责把输入翻译成意图。理解这五句话，基本就理解了一半。

这套体系面向的读者，既包括刚学完官方教程、想搞明白"我该把变量放哪个类"的入门者，也包括做过一两个 Demo、但一进多人模式就各种空指针和不同步的进阶开发者。我下面讲的每一条，都是能直接落到项目里用的，而不是照抄文档的概念罗列。尤其是那几个"放错位置就会出问题"的坑，几乎每个 UE 项目都会踩一遍。

1.1 从单机到联网：这套架构到底在解决什么问题

如果只做单机游戏，说实话这五个类里你只需要 GameMode 和 PlayerController 就够了，GameState 和 PlayerState 的存在感极低。但一旦你的项目要支持联机，问题立刻就变了：谁有权决定这局游戏什么时候结束？玩家的血量变化谁来广播？玩家掉线重连之后，他的分数还记得吗？关卡切换的时候，之前设置好的音量、难度选项、存档数据怎么带过去？

UE 的答案是：把这些不同性质的数据，按"生命周期"和"权威归属"两个维度拆开。生命周期决定了它能不能跨越关卡，权威归属决定了它是服务器说了算还是各客户端自己维护。GameMode 在一局结束时就被销毁了，所以它适合放"这局怎么打"的规则；GameInstance 伴随整个进程，所以它适合放"跨局甚至跨存档"的全局数据。这套拆分不是为了好看，是为了让你在写代码的时候，天然就不会把"服务器才该有的逻辑"写到客户端会执行的类里。

我见过太多新手项目，把玩家分数直接存在 PlayerController 里。单机跑起来一点问题没有，一联机就发现每个客户端看到的分数都不一样，因为 PlayerController 是每个客户端各自持有的本地对象，它的变量默认不会自动同步。这就是不按职责放数据的代价。

1.2 生命周期对照：谁活得最久，谁一局就换

把生命周期这张图记在脑子里，很多决策会自动变得清晰。GameInstance 从游戏进程启动到退出，全程只有一个实例，关卡切换不会重建它——这是它最核心的价值。GameMode、GameState 属于"World"级别，每加载一个新关卡（World）就会生成新的，关卡一换就销毁重建。PlayerController 和 PlayerState 属于"玩家"级别，只要这个玩家还连着，就一直存在，但换关卡时 UE 会尽量保活它们（这点很关键，后面讲重连时会展开）。

需要特别注意的是 PlayerState 和 PlayerController 在换关卡时的表现。早期版本里换关卡会重新生成 PlayerController，后来 UE 改成尽量复用，但如果你在 GameMode 里设置了bDelayedStart或者用了无缝切换（Seamless Travel），行为又不一样。我个人的做法是：任何需要跨关卡保留的玩家数据，一律放 PlayerState 或 GameInstance，绝不放 PlayerController。这样不管 UE 内部怎么处理 Controller 的重建，你的数据都是安全的。

这里插一句实战心得：判断一个变量该放哪，就问自己两个问题——"它需要跨关卡吗"和"它是所有人的共识还是我自己的本地状态"。第一个问题回答 GameInstance vs 其他，第二个问题回答 GameState/PlayerState（共识，需同步）vs PlayerController（本地，不自动同步）。

1.3 一张表看清五者的定位与归属

这张表的每一列，都是我在项目里反复验证过的。比如 GameMode 那一行"仅服务器"，踩过坑的人才知道有多重要——你在客户端蓝图上给 GameMode 加逻辑，某些情况下它会返回 null，因为客户端压根没这个对象。

2. GameInstance：跨关卡存活的全局数据容器

GameInstance 是我最喜欢也最容易被滥用的一个类。它的定位非常明确：整个游戏进程里唯一存在、关卡切换不销毁的全局对象。正因为它是全局单例，很多人把它当成了万能垃圾袋，什么数据都往里塞，结果项目一到后期就变成一个几千行的巨型类，谁都不敢改。我在第二个项目里就犯过这个错，最后花了一周重构，把该进 GameInstance 的和不该进的彻底分开。

先说清楚它到底适合放什么。跨关卡的数据是首选：比如玩家在设置菜单里调好的画质、音量、难度，进入游戏后要生效，这些数据必须活过关卡切换；再比如玩家的存档进度、解锁的成就、账号信息，这些是进程级的，放 GameInstance 天经地义。还有一类是"全局服务"性质的东西：比如你的音频管理、存档管理、对象池管理器，可以挂在 GameInstance 上，让它跟着进程走。

那什么不该放？一局游戏内的临时状态，比如当前关卡剩余多少敌人、这一波的刷怪计时，这些放 GameInstance 就错了，因为它们本该随关卡销毁，你一换关卡它们还在，反而会造成脏数据。另外，任何需要网络同步的对局数据也不该放这里，GameInstance 的变量默认不做属性同步，你想同步还得自己写 RPC，那还不如直接放 GameState。

2.1 蓝图与 C++ 两种实现路径，以及各自的坑

多数人第一次接触 GameInstance 是在项目设置里指定一个蓝图类。路径是Project Settings → Maps & Modes → Game Instance → Game Instance Class，选一个继承自 GameInstance 的蓝图，UE 会在游戏启动时自动实例化它。这个方式上手快，适合快速验证，但它有两个隐藏问题：一是蓝图里的变量在编辑器里改不生效，因为实例是运行时创建的；二是蓝图读写复杂数据结构时性能一般，如果你要在里面存几百条存档数据，还是老实用 C++。

C++ 的路径是继承 UGameInstance，然后在项目设置里指定你的 C++ 类（或者蓝图继承自它）。C++ 版的好处是可以在构造函数里初始化，可以用FTableRowBase之类的高效结构，还能暴露UFUNCTION给蓝图用。下面是我常用的一个基础骨架：

// MyGameInstance.h UCLASS() class MYGAME_API UMyGameInstance : public UGameInstance { GENERATED_BODY() public: virtual void Init() override; virtual void Shutdown() override; UPROPERTY(BlueprintReadWrite, Category = "Save") int32 PlayerLevel = 1; UFUNCTION(BlueprintCallable, Category = "Save") void SaveAllData(); };

// MyGameInstance.cpp void UMyGameInstance::Init() { Super::Init(); // 注册委托、加载配置等全局初始化逻辑写这里 UE_LOG(LogTemp, Log, TEXT("GameInstance Init")); }

Init()是整个游戏最早被调用的一批函数之一，适合在这里做全局注册；Shutdown()在进程退出时调用，是保存数据的最后机会。很多人在Init()里塞了大量耗时逻辑导致启动卡顿，我的建议是重逻辑延后，Init()只做轻量注册。

2.2 从任意位置拿到 GameInstance 的正确姿势

拿到 GameInstance 的引用是所有人都会遇到的问题。在 Actor 里可以用GetGameInstance()，在 UObject 里可以用GetWorld()->GetGameInstance()，在蓝图里直接用Get Game Instance节点，再Cast成你的自定义类型。看起来简单，但坑在于调用时机。如果在构造函数里调用，GetWorld()可能为 null；在BeginPlay之前的某些回调里调用，World 可能还没完全初始化。

我个人的封装习惯是写一个静态辅助函数，把 cast 和判空都包进去，用的时候一行搞定：

UMyGameInstance* UMyBlueprintFunctionLibrary::GetMyGI(const UObject* WorldContext) { if (!WorldContext) return nullptr; UWorld* World = WorldContext->GetWorld(); if (!World) return nullptr; return Cast<UMyGameInstance>(World->GetGameInstance()); }

注意：不要为了图省事把 GameInstance 的指针存成全局变量长期持有。GameInstance 虽然是单例，但跨关卡时不保证所有内部引用都有效，直接存指针容易在编辑器里 PIE（Play In Editor）反复启动时拿到已被回收的对象。

2.3 跨关卡传数据的实际做法

做关卡切换时怎么把数据带走，是我被问得最多的一个问题。答案其实很直接：数据存 GameInstance，切换关卡后重新从 GameInstance 读。具体做法是在关卡开始（比如 GameMode 的BeginPlay或者玩家 Pawn 的BeginPlay）时，去 GameInstance 里取需要的值，而不是试图把数据"传"过去。

如果数据量不大，直接读 GameInstance 的成员变量就够。如果数据结构复杂，我会把数据序列化成USaveGame子类，通过SaveGameToSlot/LoadGameFromSlot存读，这样既能跨关卡也能跨进程。内嵌代码里我一般这么写：

// 保存 UMySaveGame* Save = Cast<UMySaveGame>(UGameplayStatics::CreateSaveGameObject(UMySaveGame::StaticClass())); Save->PlayerLevel = GI->PlayerLevel; UGameplayStatics::SaveGameToSlot(Save, TEXT("Slot0"), 0); // 读取 UMySaveGame* Loaded = Cast<UMySaveGame>(UGameplayStatics::LoadGameFromSlot(TEXT("Slot0"), 0)); if (Loaded) { GI->PlayerLevel = Loaded->PlayerLevel; }

提示：SaveGameToSlot是同步的，大存档会卡帧。真要发布，建议放到异步任务里，或者用AsyncSaveGameToSlot。

3. GameMode 与 GameState：规则制定者与状态广播员

GameMode 和 GameState 是一对必须一起理解的搭档。很多人第一次做联机，把"玩家进入游戏要加分"这个逻辑写在了 GameMode 里，然后发现客户端压根拿不到 GameMode，一调用就崩。这时候才意识到：GameMode 只存在于服务器端。这是 UE 网络架构里最硬的一条规则，没有例外。理解这一点，你就理解了 GameState 存在的必要性——因为客户端需要知道"这局游戏现在是什么状态"，而状态又只有服务器能决定，所以服务器把状态写进 GameState，GameState 通过网络复制同步给所有客户端。

打个比方：GameMode 是裁判，裁判只在场地中央（服务器）走动；GameState 是大屏幕计分板，所有人都能看到；裁判做出的判罚，会立刻显示在计分板上。你作为球员（客户端），看不到裁判本人，但能通过计分板知道当前比分和时间。

这个比喻帮我理清了很多问题。比如我想在客户端显示"距离回合结束还有 30 秒"，我不会去问 GameMode，而是读 GameState 里被同步过来的剩余时间变量。再比如我想在客户端判断"游戏是否已经结束"，也是读 GameState 里的阶段枚举，而不是去调 GameMode 的函数。

3.1 自定义 GameMode 与 GameState 的实操步骤

在实际项目里，我一般会先建两个 C++ 基类：AMyGameMode和AMyGameState，蓝图再继承它们，这样逻辑放 C++，数值和表现放蓝图。步骤大致是这样：

1. 新建AMyGameMode : public AGameModeBase，在里面重写BeginPlay、PostLogin、Logout等关键回调。
2. 新建AMyGameState : public AGameStateBase，把需要广播的变量用UPROPERTY(ReplicatedUsing=OnRep_XXX)标记。
3. 在 GameMode 的构造函数里设置GameStateClass = AMyGameState::StaticClass();，把两者绑定。
4. 在项目设置或者关卡 World Settings 里指定 GameMode，让这一局用你的规则。

第 3 步是最容易漏的。很多人建了自定义 GameState，却发现游戏里生成的还是默认的，就是因为没在 GameMode 里指定GameStateClass。这个绑定关系必须显式建立，UE 不会自动帮你猜。

至于 GameState 的变量同步，关键是重写GetLifetimeReplicatedProps：

void AMyGameState::GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const { Super::GetLifetimeReplicatedProps(OutLifetimeProps); DOREPLIFETIME(AMyGameState, RemainingTime); DOREPLIFETIME(AMyGameState, TeamAScore); DOREPLIFETIME(AMyGameState, TeamBScore); }

DOREPLIFETIME是告诉引擎"这些变量需要同步到客户端"。不加它，你在服务器改多少遍，客户端也不会变。

3.2 GameState 在客户端读，GameMode 在服务器写

我想强调的是这套读写分离的习惯。凡是需要所有玩家看到的数据，一律写在 GameState 里，服务器负责改，客户端只负责读。GameMode 里则放那些只有服务器需要知道的决策逻辑：什么时候开始回合、什么时候判定胜负、什么时候生成道具。客户端完全不需要知道这些决策过程，它只关心结果状态。

举一个具体的例子。假设我要做一个"限时击杀对手"的模式。服务器端的 GameMode 会维护一个计时器，时间到了就调用EndMatch()，把 GameState 的阶段设为"已结束"，然后把最终比分写进 GameState。客户端收到阶段变化后，播放结算 UI。整个流程里，客户端从来不调用 GameMode 的任何函数，它只是被动接收 GameState 的变化然后做出反应。这就是正确的心智模型。

如果你发现自己的代码在客户端需要访问 GameMode，那一定是架构出了问题，八成是某段逻辑本该放 GameState 却塞进了 GameMode。

4. PlayerController 与 PlayerState：玩家的"手"和"档案"

把这组搭档和上一组对照着看，会非常清晰。GameMode 对 GameState，是"规则对状态"；PlayerController 对 PlayerState，则是"操作对档案"。PlayerController 是玩家的手，负责抓取输入、控制视角、Possess 一个 Pawn；PlayerState 是这个玩家在这局里的档案，记录他的昵称、得分、队伍归属。

它们最本质的区别在于权威归属。PlayerController 在每个端都有一份实例，客户端的那份负责处理本地输入，服务器的那份负责验证和执行；而 PlayerState 虽然也是每个端都有一份，但它的数据以服务器为准，通过复制同步给客户端。换句话说，PlayerController 的变量默认是"各管各的"，PlayerState 的变量默认是"服务器说了算"。这条区别是判断数据该放哪的金标准。

举一个我踩过的具体坑。做排行榜的时候，我一开始把击杀数存在 PlayerController 里，服务器加一分，客户端看自己的还是零。后来移到 PlayerState，加DOREPLIFETIME，所有端立刻同步了。原因就是 PlayerController 不会自动跨端同步玩家档案这种"共识数据"。

4.1 PlayerController 的核心职责：输入、相机、Possess

PlayerController 干的三件事，我在项目里几乎天天碰。第一是输入处理，输入映射（Input Mapping）的解绑最终会走到 Controller 上，通过SetupInputComponent()把按键绑定到回调函数。第二是相机控制，PlayerCameraManager由 Controller 持有，第一人称、第三人称的视角逻辑通常挂在 Controller 或者它 Possess 的 Pawn 上。第三是 Possess 关系，Controller 通过Possess(Pawn)接管一个 Pawn 的控制，UnPossess()则放开控制。

关于 Possess，有几个非常关键的行为需要记住。玩家死亡时，通常的做法是UnPossess掉旧 Pawn 并销毁它，然后进入观察者模式，等复活后再 Possess 新 Pawn。这个过程里，PlayerController 本身是保活的，所以任何需要跨死亡保留的数据（比如连杀数），放在 Controller 里是安全的，但放 Pawn 里就会随着 Pawn 销毁而丢失。这又是一个"生命周期决定数据归属"的实例。

输入绑定的代码我一般这样写：

void AMyPlayerController::SetupInputComponent() { Super::SetupInputComponent(); InputComponent->BindAction("Jump", IE_Pressed, this, &AMyPlayerController::OnJumpPressed); InputComponent->BindAxis("MoveForward", this, &AMyPlayerController::MoveForward); } void AMyPlayerController::OnJumpPressed() { if (AMyCharacter* Char = Cast<AMyCharacter>(GetPawn())) { Char->Jump(); } }

注意我用了GetPawn()再 cast，而不是直接持有 Pawn 指针。因为 Pawn 可能在任意时刻被销毁或替换，直接存指针很容易变成悬空指针。

4.2 PlayerState 独立存在的原因：复活、重连、数据归属

很多人会问，既然 PlayerController 已经跟着玩家走了，为什么还要 PlayerState？答案在几个特殊场景里会暴露得非常明显。

第一个场景是死亡与复活。玩家死了，Pawn 销毁，Controller 还在，但如果你把得分放 Controller 里，逻辑上没错，可一旦涉及"跨队伍汇总"就麻烦了——因为 Controller 是本地对象，服务器汇总时得遍历所有 Controller，而 Controller 的复制能力和 PlayerState 不一样，PlayerState 天生就是为"所有玩家都能看到每个玩家的信息"设计的。

第二个场景是掉线重连。玩家断线后，Controller 会被销毁，但 UE 的设计里 PlayerState 是可以跨无缝切换关卡保留的。如果你的数据放 PlayerState，重连后还能恢复；放 Controller，重连后就没了。

第三个场景是观战和旁观。观战者的 Controller 可能没有 Pawn，但所有玩家的 PlayerState 依然存在，所以观战 UI 能显示所有玩家的昵称和分数。

基于这三点，我把 PlayerState 当作"玩家在这局里的公开名片"来用：昵称、头像 ID、队伍、击杀、死亡、助攻、延迟，全放这里。这些数据的共同点是——它们需要被所有端看到，且以服务器为准。

4.3 Controller 与 Pawn 的 Possess 关系详解

Possess 关系是理解这组类的一条隐藏线索。一个 PlayerController 同一时刻只能 Possess 一个 Pawn，但一个 Pawn 可以被不同的 Controller 先后 Possess。这个一对多的关系，决定了你不能把"玩家身份"绑定在 Pawn 上。

我在做载具系统的时候深刻体会过这一点。玩家开车时 Controller Possess 载具，下车时 UnPossess 载具、Possess 角色。整个过程里玩家还是那个玩家，但 Pawn 换了两三次。如果我把玩家的等级、昵称存在 Pawn 里，换一次就丢一次。存在 PlayerState 里，全程稳定。

这里有个细节要提醒：Possess之后记得在 Pawn 里处理NotifyRestarted或者重写PossessedBy，因为有些初始化逻辑（比如相机设置、输入模式切换）需要在 Possess 完成后再做。顺序搞错会导致输入失效或者相机抖动。

5. 五者之间的调用关系与数据流向实战

把五个类单独讲清楚之后，最重要的是理解它们在一次完整游戏流程里是怎么串起来的。我按"客户端加入服务器"的时间线来梳理，这条链路理清了，你对整套架构的理解就成型了。

游戏进程启动，最先创建的是GameInstance，它注册各类子系统、加载全局配置。然后玩家点击进入某个关卡，UE 加载 World，在服务器端创建GameMode和GameState，并把 GameState 关联到 GameMode。玩家连接进来时，服务器为他创建PlayerController和PlayerState，Controller 通过 Possess 接管一个 Pawn。GameMode 监听到玩家加入（PostLogin），更新 GameState 里的玩家列表。客户端这边收到复制过来的 GameState 和各个 PlayerState，渲染出完整的对局画面。

这条链路里，每个类的创建时机和依赖关系都是固定的，理解它就能预判"某个类在某个时刻是否可用"。

5.1 从加入服务器到进入战斗的完整初始化链路

我把它拆成服务器侧和客户端侧两条线来看，会更清楚。

服务器侧：World 加载 → GameMode 构造 → GameState 构造 → 玩家连接 → PlayerController 构造 → PlayerState 构造 → Pawn 生成 → Possess → GameMode.PostLogin → 更新 GameState。

客户端侧：收到连接确认 → 本地 GameState 复制 → 各 PlayerState 复制 → 本地 PlayerController 生成 → 本地 Pawn 生成并可能被服务器授权 Possess → 输入开始生效。

这里最容易出问题的是时序。比如你在 PlayerController 的BeginPlay里访问 PlayerState，可能 PlayerState 还没复制过来，拿到的是 null。稳妥的做法是在OnRep_PlayerState回调里处理依赖 PlayerState 的逻辑，而不是在BeginPlay里抢跑。这个回调就是专门为"PlayerState 准备好了"这个时刻设计的。

5.2 在任意位置拿到其他类引用的代码模板

在项目里到处拿引用是常态，我把常用的一组辅助函数整理下来，几乎每个项目都直接抄。

// PlayerController 里 AMyGameState* GS = GetWorld()->GetGameState<AMyGameState>(); AMyPlayerState* PS = GetPlayerState<AMyPlayerState>(); AMyGameMode* GM = GetWorld()->GetAuthGameMode<AMyGameMode>(); // 仅服务器有效 // PlayerState / 任意 Actor 里 AMyGameState* GS = GetWorld()->GetGameState<AMyGameState>(); UMyGameInstance* GI = GetWorld()->GetGameInstance<UMyGameInstance>();

注意：GetAuthGameMode()在客户端返回 null，这是设计如此，不是 bug。要用 GameMode，先确认当前是不是服务器，可以用HasAuthority()或者GetNetMode() != NM_Client判断。

我特别想强调GetWorld()->GetAuthGameMode()这个函数名里的 "Auth"。它明确告诉你：只有权威端（服务器）才拿得到。很多新手在客户端调用它，得到 null 之后一顿排查，其实完全没必要——换成 GameState 读数据就好了。

5.3 数据放错位置的典型症状对照

判断数据放哪，除了前面说的两个问题，我还总结了一套"症状对照法"。当你遇到下面这些症状时，基本就是数据放错了地方：

这张表是我在真实项目里一条条攒出来的，每次新人问我"为什么我的分数不同步"，我基本都能靠它对上号。

6. 高频踩坑与排查速查表

理论讲完了，这一节说点真正值钱的东西——那些文档里不会写、只有踩过才知道的坑。我做过三个联机项目，光是在这几个类的选择上就浪费了不知道多少时间，下面这些都是血泪换来的。

第一个高频坑是在客户端访问 GameMode。前面提过，但我还是要单独强调，因为它太常见了。症状是客户端调用 GameMode 的某个函数直接崩溃或者拿到 null。排查方法很简单：打印GetNetMode()，如果是NM_Client，就别碰 GameMode。替代方案是把需要的数据通过 GameState 暴露出来。

第二个坑是忘了 DOREPLIFETIME。你明明把变量放对了 GameState，服务器也改了，客户端就是不变。九成是没在GetLifetimeReplicatedProps里注册。这个函数的签名很容易写错，比如参数类型、const 限定，写错了不报错但同步失效，非常隐蔽。我的习惯是用引擎提供的DOREPLIFETIME宏，别手写注册逻辑。

第三个坑是在 GameState 的 getter 里做重量级计算。GameState 会被频繁访问，如果你在它的属性 getter 里做遍历或者字符串拼接，性能会肉眼可见地掉。正确的做法是把计算放在服务器改值的时刻，GameState 只存结果。

6.1 空指针与"服务器端为 Null"的排查思路

空指针是这套架构里最常见的报错，但它的原因往往不是"对象真的不存在"，而是"你访问的时机不对"或"你访问的端不对"。我总结了一个排查顺序：

先确认端：用GetNetMode()打印当前是服务器还是客户端。如果是客户端访问 GameMode，直接放弃这个方向。

再确认时机：在BeginPlay里拿到 null，很可能是对象还没复制完成。改用OnRep_XXX回调，或者用IsValid()加延迟一帧的Timer。

最后确认World：GetWorld()本身在构造阶段可能为 null，这是 UE 对象生命周期决定的，构造函数里不碰需要 World 的调用，是一劳永逸的习惯。

6.2 问题速查表

6.3 我在实际项目里攒下的几条经验

最后分享几条纯个人经验，都是文档里不会写、但真的能省时间的。

第一条：新建一个项目时，先把这五个类的自定义基类都建好，哪怕暂时是空的。这样后面加数据时不会临时纠结放哪，直接往对应的基类里加就行。这个习惯让我后面几个项目少返工很多次。

第二条：给 PlayerState 和 GameState 加复制属性时，先从最简单的 int32 和 bool 开始。复杂结构（比如 TArray ）的复制有很多限制，容易踩到"结构体没标 UPROPERTY"或者"数组复制性能差"的坑。等简单属性验证通了，再往上加复杂度。

第三条：调试网络问题时，永远在服务器和客户端各打一遍日志。我经常只看服务器日志觉得一切正常，结果客户端那边压根没收到。后来养成习惯，关键逻辑两边都打，一眼就能看出是"没发出去"还是"没收到"。

第四条：别迷信"最佳实践"里所有变量都要标 Replicated。每次复制都有开销，PlayerState 里那些纯本地用的临时变量，标了复制反而浪费带宽。只复制真正需要所有端看到的东西，剩下的留本地。

第五条：GameInstance 里尽量避免持有 Actor 引用。因为 Actor 是 World 级的，跨关卡后会被销毁，而 GameInstance 活得更久，很容易造成悬空引用。要在 GameInstance 里存东西，存数据（int、float、FString、结构体），别存对象指针。

这套架构看起来五个类有点多，但一旦你把每个类的职责和生命周期刻进脑子里，写代码的时候会像有肌肉记忆一样，变量该放哪几乎不用思考。我现在的项目里，新人经常问我"这个变量放哪"，我基本会反问一句"它要跨关卡吗，它是所有人的共识吗"，两个问题问完，答案自己就出来了。这套判断逻辑，是我这几年做联机项目最实用的一条经验，希望对正在被这几个类绕晕的你有点帮助。