企业官网建设流程全解析

1. 从一次角色血量不同步的事故说起

如果你在做多人联机项目，尤其是用虚幻引擎搭底层框架，那“RPC”和“属性同步”这两个词你肯定绕不开。我见过太多团队在这上面翻车：有人把开火逻辑写在客户端，结果子弹从两个方向飞出去；有人改了血量，服务器扣了，客户端还显示满血；还有人把RPC当普通函数随便调，最后带宽爆了、延迟飙了，玩家体验一塌糊涂。

这篇内容就是围绕**UE里的RPC（远程过程调用）和属性同步（Property Replication）**展开的。它解决的核心问题是：在一个客户端-服务器架构下，怎么让不同机器上的游戏状态保持一致，同时让该发生的动作在正确的机器上执行。适合已经能跑起一个简单联机Demo、但对底层同步机制还模模糊糊的开发者，也适合想系统梳理网络同步知识的老手。

我不会只给你列API，而是把“为什么这么设计”“什么时候用哪个”“踩过哪些坑”讲清楚。你读完至少能判断：这个逻辑该不该走RPC？这个变量该不该同步？为什么我的RPC没触发？为什么属性同步延迟这么高？

2. 先搞明白UE的网络角色：谁说了算

2.1 Authority与Remote的区别不是玄学

UE的网络模型是典型的服务器权威（Server Authority）。服务器上那个Actor拥有最高话语权，客户端上的Actor只是“代理”。这就引出一个关键概念：Role。

• ROLE_Authority：这个Actor在服务器上，或者在被服务器授权的机器上。
• ROLE_AutonomousProxy：这个Actor在客户端上，但由玩家自己控制（比如你的角色）。
• ROLE_SimulatedProxy：这个Actor在客户端上，但由别人控制（比如队友的角色）。

为什么这个区分重要？因为只有Authority才能决定游戏状态。你在客户端改一个变量，如果不通过RPC告诉服务器，服务器根本不知道，其他客户端更不知道。很多新手会问：“我明明在客户端设置了血量，为什么服务器不认？”答案就在这。

我习惯在写任何网络逻辑前，先问自己三个问题：

1. 这段代码在哪个机器上执行？
2. 这个Actor在这台机器上的Role是什么？
3. 这个操作需要服务器批准吗？

2.2 一个生活化类比：公司审批流程

把服务器想成公司总部，客户端想成各地分公司。分公司想改预算（属性），不能自己直接改，得走审批流程（RPC）报给总部，总部批准后更新总账，再把新预算同步给所有分公司。如果分公司自己偷偷改了，总账对不上，其他分公司也不知道，整个公司就乱套了。

这个类比里，RPC就是审批单，属性同步就是总部下发的通知。审批单有不同类型：有的需要总部回执（可靠RPC），有的发出去就不管了（不可靠RPC）。通知也有不同频率：重要的财务数据每次变动都通知（高频同步），茶水间零食库存可能一天同步一次（低频同步）。

2.3 常见误区：客户端也能有Authority吗

能，但极其危险。UE允许你把某个Actor的Authority给客户端，但这意味着服务器信任这个客户端。在竞技类游戏里，这等于把反作弊的钥匙交给玩家。我见过有人为了省事，把伤害计算放在客户端，结果被玩家改内存秒杀全场。所以除非是单机合作或者完全信任的环境，否则永远不要让客户端拥有核心逻辑的Authority。

3. RPC不是普通函数：调用时机决定一切

3.1 三种RPC的适用场景拆解

UE里RPC分三种，按“谁调用、谁执行”来区分：

这里有个容易混淆的点：Multicast RPC在服务器上调用时，服务器自己也会执行一次。如果你在Multicast里写了一个生成Actor的逻辑，服务器会生成一个，每个客户端也会生成一个，但只有服务器的那个是Authority。如果你没做判断，就会出现“服务器生成一个，客户端又生成一个”的重复问题。

我通常这样记：Server RPC是“上报”，Client RPC是“下发”，Multicast是“广播”。上报要可靠，下发可以按需，广播要小心带宽。

3.2 Reliable与Unreliable：不是“重要”与“不重要”那么简单

很多人以为Reliable就是“重要的”，Unreliable就是“不重要的”。不完全对。Reliable保证到达，但会占用带宽和重传队列；Unreliable不保证到达，但速度快、开销小。

关键判断标准是：这个RPC如果丢了，会不会导致状态不一致？

• 开火、换弹、使用技能：必须Reliable，丢了玩家会觉得“我明明按了没反应”。
• 语音聊天数据、每帧的位置更新：Unreliable，丢一帧无所谓，下一帧就补上了。
• 播放一个 cosmetic 特效：Unreliable，丢了就丢了，不影响游戏逻辑。

我踩过的一个坑：把每帧的鼠标朝向用Reliable RPC发送，结果网络稍微抖动一下，重传队列堆积，延迟直接爆炸。后来改成Unreliable，瞬间流畅。Reliable不是越多越好，它是有限资源。

3.3 RPC的声明与实现：语法细节决定成败

在UE里声明RPC，函数必须加UFUNCTION宏，并且带上Server、Client或NetMulticast标记。比如：

UFUNCTION(Server, Reliable, WithValidation) void ServerFire();

这里WithValidation是个关键。它要求你实现一个_Validate函数，用来检查参数是否合法。比如玩家传了一个超出射程的坐标，你可以在Validate里拒绝。如果不加WithValidation，服务器会无条件信任客户端传来的参数，这在竞技游戏里是致命的。

另一个细节：RPC函数名通常以Server/Client/Multicast开头，这不是强制，但团队协作时能一眼看出这是网络调用。我见过有人把Server RPC命名成DoSomething，结果新人以为是普通函数，在客户端直接调，调试了半天。

还有，RPC只能在拥有Authority的Actor上调用。如果你在一个SimulatedProxy上调用Server RPC，它会静默失败。我建议在调用前加一个if (GetLocalRole() == ROLE_Authority)的判断，或者用ensure来捕获错误。

4. 属性同步：让状态自动流动的机制

4.1 Replicated变量的注册与条件

属性同步的核心是Replicated标记。在GetLifetimeReplicatedProps里注册：

void AMyActor::GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const { Super::GetLifetimeReplicatedProps(OutLifetimeProps); DOREPLIFETIME(AMyActor, Health); DOREPLIFETIME_CONDITION(AMyActor, Ammo, COND_OwnerOnly); }

DOREPLIFETIME是默认同步给所有客户端，DOREPLIFETIME_CONDITION可以加条件。常用的条件有：

• COND_OwnerOnly：只同步给拥有者。比如弹药数量，队友不需要知道。
• COND_SkipOwner：不同步给拥有者。比如某些特效，自己不需要看到。
• COND_InitialOnly：只在初始时同步一次。比如玩家名字。

为什么要有条件？因为带宽是稀缺资源。一个64人的服务器，如果每个玩家的每个属性都广播给所有人，带宽瞬间跑满。我做过一个测试：把10个无关紧要的变量从COND_OwnerOnly改成默认同步，带宽直接涨了30%。

4.2 RepNotify：属性变化时的回调

有时候属性变了，你需要做点什么——比如血量变了要更新UI，或者播放受伤动画。这时候用RepNotify：

UPROPERTY(ReplicatedUsing = OnRep_Health) float Health; UFUNCTION() void OnRep_Health();

OnRep_Health会在客户端收到新值时自动调用。注意：在服务器上，属性变化不会触发RepNotify，因为服务器是源头，它知道自己改了。所以如果你有一段逻辑既要在服务器执行，又要在客户端执行，不能只写在RepNotify里。

我常用的模式是：服务器改属性，然后手动调用一个OnHealthChanged函数处理服务器端逻辑；客户端则通过RepNotify触发同一个函数。这样逻辑统一，不会漏。

4.3 属性同步的时机与顺序问题

属性同步不是实时的，它跟着网络更新周期走。默认情况下，UE会以一定的频率（通常是网络Tick）发送属性更新。这意味着：

• 你在服务器上连续改两次属性，客户端可能只收到最后一次。
• 属性同步的顺序不保证，但同一个Actor的属性通常按注册顺序发送。

这就引出一个经典问题：如果两个属性有依赖关系，怎么办？比如IsDead和Health，如果Health先到，IsDead后到，客户端可能短暂出现“血量0但还没死”的状态。解决方案是用一个结构体或者让IsDead由Health计算得出，而不是单独同步。

我个人的经验是：能计算的属性就不要同步。比如HealthPercent可以由Health和MaxHealth算出来，同步它纯属浪费带宽。

5. 实战中的坑：那些文档不会告诉你的细节

5.1 RPC没触发？先查这五个地方

RPC不执行是新手最常见的求助。我总结了一个排查清单：

1. Actor的Role对不对？Server RPC只能在客户端拥有的Actor上调用。如果你在一个SimulatedProxy上调用，它不会报错，但也不会执行。
2. 函数有没有加UFUNCTION宏？没有宏，UE的网络系统根本不认识它。
3. Reliable还是Unreliable？Unreliable在丢包时可能永远不到，调试时先用Reliable确认逻辑。
4. WithValidation的Validate函数返回true了吗？如果Validate返回false，RPC会被丢弃，而且不会有明显提示。
5. 网络模式对不对？在Standalone模式下，RPC可能被优化掉。用Play As Client或者Dedicated Server测试。

我遇到过最隐蔽的一次：RPC函数在头文件里声明了，但实现时忘了加_Implementation后缀。编译通过，运行不报错，但就是不执行。后来查了半天才发现。

5.2 属性同步延迟高？可能是这几个原因

属性同步延迟高，通常不是网络本身的问题，而是用法不对：

• 同步频率过高：每帧改一个变量，网络层会合并，但如果你在Tick里改，它可能每帧都发。改成只在变化时改。
• 同步数据量太大：一个结构体里塞了几十个字段，每次同步整个结构体。拆成多个小属性，按需同步。
• 条件设置不当：该用COND_OwnerOnly的用了默认，导致无关客户端也收到数据。
• NetUpdateFrequency太低：默认是100Hz，但有些Actor可以调低。如果延迟高，检查这个值。

我做过一个优化：把一个每帧同步的浮点数改成每0.1秒同步一次，带宽降了80%，玩家完全感知不到差别。

5.3 属性同步与RPC的配合：谁先谁后

有时候你需要先同步一个属性，再触发一个RPC。比如先同步“当前武器”，再RPC“开火”。如果顺序反了，客户端可能用旧武器播放开火动画。

UE不保证属性同步和RPC的到达顺序。解决方案是：把依赖的数据打包进RPC参数里。比如ServerFire(FVector Location, int32 WeaponId)，这样即使属性还没同步，RPC也能用正确的武器ID执行。

另一个方案是用NetSerialize自定义序列化，但这属于进阶内容，新手先掌握打包参数就够了。

6. 一个完整的同步案例：从开火到血量更新

6.1 需求拆解与角色分配

假设我们要做一个简单的射击逻辑：

• 玩家按鼠标左键，客户端播放开火特效。
• 服务器计算是否命中，扣血。
• 所有客户端看到血条变化。

角色分配：

• 客户端：检测输入，调用Server RPC。
• 服务器：执行命中检测，修改Health属性。
• 所有客户端：通过RepNotify更新血条。

6.2 代码实现与关键注释

// 客户端调用 void AMyCharacter::Fire() { if (GetLocalRole() == ROLE_Authority) return; // 防止服务器重复调用 ServerFire(); PlayFireEffect(); // 本地立即播放，提升手感 } // Server RPC UFUNCTION(Server, Reliable, WithValidation) void ServerFire(); bool AMyCharacter::ServerFire_Validate() { return true; } void AMyCharacter::ServerFire_Implementation() { // 服务器执行命中检测 FHitResult Hit; if (TraceHit(Hit)) { AMyCharacter* Target = Cast<AMyCharacter>(Hit.GetActor()); if (Target) { Target->Health -= 10.0f; // 触发RepNotify } } MulticastPlayFireEffect(); // 广播特效 } // 属性同步 UPROPERTY(ReplicatedUsing = OnRep_Health) float Health = 100.0f; UFUNCTION() void OnRep_Health() { UpdateHealthBar(); // 客户端更新UI }

这里有个细节：客户端在调用Server RPC后立即播放了本地特效，这叫客户端预测。如果不做预测，玩家会感觉按了键半天才响。但预测要小心，如果服务器拒绝了这个动作，你得回滚。对于开火特效这种cosmetic的东西，不回滚也无所谓；对于弹药数量这种逻辑数据，就必须回滚。

6.3 测试与验证：怎么确认同步正确

测试网络同步，不能只在一个窗口里跑。我通常用这三种方式：

1. Play As Client：开两个窗口，一个服务器一个客户端，看行为是否一致。
2. Network Emulation：在编辑器里模拟延迟和丢包，看极端情况下是否崩溃。
3. 日志输出：在关键路径加UE_LOG，打印Role、NetMode、属性值，对比服务器和客户端。

我习惯在RepNotify里加一行日志，确认它真的被调用了。有时候属性同步没生效，就是因为忘了在GetLifetimeReplicatedProps里注册。

7. 进阶思路：什么时候该用RPC，什么时候该用属性同步

7.1 判断标准：状态 vs 事件

这是我最想强调的一点：属性同步用于状态，RPC用于事件。

• 状态：血量、弹药、位置、是否开镜。这些是持续存在的，适合属性同步。
• 事件：开火、换弹、使用技能。这些是瞬时的，适合RPC。

如果你把事件当状态同步，比如“是否正在开火”用bool同步，会出现“开火状态同步到了，但开火动作已经结束了”的尴尬。如果你把状态当事件RPC，比如每次血量变化都发RPC，那带宽会爆炸，而且新加入的玩家不知道当前血量。

我见过一个项目，把玩家位置用RPC每帧发送，结果延迟高得没法玩。改成属性同步后，UE自动做了插值和优化，瞬间流畅。

7.2 混合使用：一个技能释放的完整流程

以释放技能为例：

1. 客户端检测输入，调用ServerCastSkill(SkillId)。
2. 服务器验证魔法值是否足够，如果足够，扣魔法值（属性同步），并广播MulticastPlaySkillEffect。
3. 所有客户端收到RPC，播放特效。
4. 如果技能有持续状态（比如加速），服务器修改SpeedMultiplier属性，自动同步。

这里RPC负责“释放”这个事件，属性同步负责“魔法值”和“速度”这些状态。两者配合，逻辑清晰，带宽也省。

7.3 性能与带宽的平衡技巧

最后分享几个我常用的优化手段：

• 合并RPC：如果一秒内要发多个小RPC，考虑合并成一个结构体。
• 降低NetUpdateFrequency：对于不重要的Actor，从默认的100降到10甚至更低。
• 使用COND_SimulatedOnly：只同步给模拟代理，跳过自主代理。
• 避免在Tick里改Replicated变量：改成定时器或者事件驱动。

我做过一个极限测试：把100个Actor的NetUpdateFrequency从100降到20，带宽降了60%，玩家几乎察觉不到。当然，前提是这些Actor不是玩家角色。

网络同步是个细活，没有银弹。每次遇到问题，回到“谁说了算”“这是状态还是事件”“丢了会怎样”这三个问题，基本都能找到方向。