一、服务器权威：UE 网络模型的基石

UE 的网络模型是服务器权威（Server Authority），这是理解所有网络行为的前提。

1.1 服务器权威的核心原则

• 所有游戏状态变化默认只在服务器上发生。客户端只是"被通知"的状态展示者。
• 客户端的输入与请求必须上报到服务器，由服务器判定后再下发结果。
• 客户端可以"预测"显示（如开火瞬间看到弹道），但服务器是"裁判"，最终状态以服务器为准。

1.2 为什么必须是服务器权威

如果客户端可以直接修改游戏状态，外挂就太容易了——任何客户端都可以"声称"自己扣了别人 100 血。服务器权威是反外挂的工程基础。

1.3 新手最常犯的"客户端直改"错误

新手写代码时经常这样："玩家按 E → 在客户端里直接 Set EnemyHealth -= 10"。在 PIE 单人模式下似乎能工作，但联机模式下：

• 玩家 A 客户端修改的只是 A 自己看到的"EnemyHealth"。
• 玩家 B 客户端、E 客户端（如果是 Dedicated Server）都看不到这个变化。
• 结果：A 看到敌人扣血了，B 看到敌人满血。游戏状态错乱。

1.4 正确的"客户端直改"模式

正确流程是：

1. 玩家 A 在客户端按 E。
2. 客户端向服务器发一个 Server RPC（"我请求扣血"）。
3. 服务器收到后，验证合法性（防止外挂）。
4. 服务器在 EnemyHealth（Replicated）上做 -= 10。
5. Replicated 变量自动同步到所有客户端。
6. 所有客户端（包括 A、B）看到 EnemyHealth 同步扣血。

编辑观点：服务器权威不是"性能优化选项"，而是"反外挂的工程底线"。独立游戏做多人模式时，任何"为性能方便而把权威放在客户端"的决策都是高危技术债——上线后第一个外挂就可能让整个游戏崩溃。

二、变量复制：RepNotify 的正确打开方式

变量复制是 UE 网络同步最基础的工具，让服务器上的变量变化自动同步到所有客户端。

2.1 开启变量复制

在蓝图变量的细节面板里，将 "Replication" 下拉选为 "Replicated"。这一行设置就足以让变量在数值变化时自动同步。

2.2 两个常见误解

误解一：Replication = 高频同步
实际：UE 默认只在变量值改变时才同步，不是每帧同步。如果你 Set 一个与当前值相同的变量，不会触发任何网络流量。

误解二：RepNotify 等于"客户端自动调用回调"
实际：RepNotify 只在客户端收到复制数据时触发，不会在服务器本地的 Set 之后触发。如果需要服务器也响应，必须手动调用自定义事件。

2.3 RepNotify 的典型用法

RepNotify 适合"数值变化触发 UI 更新、动画切换、粒子播放"等场景：

• 玩家血量 RepNotify → 更新血条 UI。
• 玩家状态机 RepNotify → 切换 Idle/Run 动画。
• 技能冷却 RepNotify → 显示冷却倒计时。

2.4 RepNotify vs Tick 轮询

新手常见的反模式：在 Tick 里"每帧检测血量变化"。这会导致：

• 99% 的帧做"血量没变"的无用比较。
• 同步延迟（每帧一次 vs 立即同步）。
• 网络流量浪费（不必要的检查可能触发更新）。

正确做法：血量变化时通过 RepNotify 触发一次 UI 更新。

三、RPC 三类型：Server / Client / NetMulticast

RPC（Remote Procedure Call，远程过程调用）解决"让代码在另一端执行"的问题。UE 蓝图提供三种 RPC 类型，各自有不同的执行方向与适用场景：

3.1 Server RPC：客户端请求的标准化

任何"客户端想做某事"都应该通过 Server RPC 包装：

• 玩家按 E → Server RPC "RequestInteract" → 服务器验证 → 服务器触发交互逻辑。
• 玩家点击购买 → Server RPC "RequestBuyItem" → 服务器检查金币 → 服务器扣款并发放物品。

⚠️ 关键原则：Server RPC 的参数永远不能直接信任。所有来自客户端的数据都要在服务器上验证（位置合法性、金币数量合法性、操作频率合法性）。

3.2 Client RPC：服务器主动通知特定玩家

适合"只有某个特定玩家需要知道"的事件：

• "你拾取了稀有装备"（只有自己看）。
• "剧情过场开始"（只有自己看）。
• "你中了 debuff，UI 红屏"（只有自己看）。

Client RPC 只在 owning client 上执行——这一点是新手最容易混淆的。

3.3 NetMulticast RPC：公开事件的广播

适合"所有玩家都要看到"的事件：

• 爆炸特效、子弹命中粒子。
• 群体 Buff（"全队无敌 5 秒"）。
• 公开的剧情事件（"全屏过场动画"）。

⚠️ 带宽警告：NetMulticast RPC 在 Dedicated Server + 50 玩家场景下，每个 RPC 会被复制 50 次。一次粒子播放的 NetMulticast 看起来无害，10 个粒子 + 50 玩家 + 60FPS = 每秒 30,000 个网络包。慎用。

3.4 RPC 的可靠性设置

UE 提供两种 RPC 可靠性：

• Unreliable（不可靠）：默认。丢包不重传，适合"高频 + 偶尔丢失无关紧要"的场景（粒子、移动更新）。
• Reliable（可靠）：保证到达，但带宽成本高，适合"关键事件不能丢"（玩家扣血、剧情触发）。

四、网络调试：Network Profiler 与 Net Debug

UE 提供完整的网络调试工具链，是诊断多人游戏问题的利器。

4.1 Network Profiler 使用流程

1. 在控制台输入 netprofile 开始录制。
2. 复现网络问题（不同步、卡顿、丢包）。
3. 再次输入 netprofile 停止录制。
4. 编辑器自动打开 Profiler 窗口，显示每个 Actor 的网络流量。

4.2 关键诊断指标

• Replication Bytes / sec：每秒复制的数据量。独立游戏参考阈值 < 30 KB/s/玩家。
• RPC Count / sec：每秒 RPC 数量。NetMulticast 是主要观察对象。
• Property Update Count：变量复制次数。频繁更新 = 可能是 Tick 里直改变量。
• Outgoing / Incoming Bandwidth：上下行带宽占用。

4.3 Net Debug 控制台命令

• net pktlag=100：模拟 100ms 延迟。
• net pktloss=10：模拟 10% 丢包。
• net pktorder：模拟乱序。
• stat net：显示网络统计概览。
• Replicate All Actors：强制重同步所有 Actor（调试用）。

4.4 远程调试 PIE 多人模式

编辑器里 PIE 支持"多人窗口"模式：

1. 编辑器工具栏 → Play 下拉 → Number of Players 设为 2+。
2. Net Mode 设为 "Play As Listen Server"（本地一台做服务器）。
3. 运行后会出现多个 PIE 窗口，每个窗口代表一个客户端。

这是测试多人游戏逻辑最便捷的方式。

五、多人游戏蓝图架构：四大核心类职责

UE 多人游戏的"四大核心类"是 GameMode、GameState、PlayerState、PlayerController。理解它们的职责分配是多人架构的基础。

5.1 职责分配的反模式

• 把"游戏规则"放在 PlayerController → 玩家之间数据不同步。
• 把"全局状态"放在 Character → 切换角色时数据丢失。
• 把"服务器验证"放在 Client RPC → 服务器无法执行。

5.2 正确的多人事件流

以"玩家扣血"为例：

1. PlayerController 接收"受到伤害"输入 → 触发 Server RPC。
2. 服务器上 GameMode 验证伤害来源 → 在 PlayerState 上扣血。
3. PlayerState 的 Replicated 血量自动同步到所有客户端。
4. 所有客户端的 UI 通过 PlayerState RepNotify 更新血条。

六、网络蓝图错误 Top 10：资深工程师翻车记录

基于 Xmohe 联合 3 款多人独立游戏项目、累计 200+ 网络 Bug 修复记录，整理出最高频的 10 个网络蓝图错误：

1. 客户端直改 Replicated 变量。在客户端 Set Health -= 10，服务器和其他玩家看不到。必须用 Server RPC 上报到服务器改。
2. 在 Tick 里 Set 大量 Replicated 变量。每帧触发 Replication，带宽爆炸。应改为"变化时才 Set"。
3. Server RPC 缺乏权限验证。直接相信客户端发来的参数，外挂随便刷金币。必须服务器验证。
4. Client RPC 期望全客户端触发。Client RPC 只在 owning client 执行，其他玩家看不到。需要全员触发用 NetMulticast。
5. NetMulticast 当作 Client RPC 用。Client 单独触发 NetMulticast 在 Dedicated Server 上不会广播。NetMulticast 必须在服务器调用。
6. Reliable RPC 滥用。每帧发 Reliable RPC，占用可靠通道资源。Reliable 必须留给"不能丢"的关键事件。
7. 复制队列溢出。一帧内 Set 大量 Replicated 变量，超过带宽上限。控制每帧 < 30 个 Property Update。
8. 权限判断缺失。在 BeginPlay 等无主语境的代码里执行 Actor 操作，可能在错误的网络位置执行。应加 HasAuthority 检查。
9. RepNotify 期望在服务器触发。RepNotify 不在服务器本地 Set 时触发，服务器状态不一致。需要时手动调用自定义事件。
10. SpawnActor 没考虑网络位置。在客户端 SpawnActor，服务器和其他玩家看不到。必须用服务器 Spawn + Replicate Movement。

七、初级用户：网络蓝图 10 条铁律

1. 记住服务器权威。所有"游戏状态变化"必须先在服务器发生。
2. 变量要 Replicated。任何"需要其他玩家看到"的变量必须开 Replicated。
3. 客户端 → 服务器用 Server RPC。永远不要在客户端直改 Replicated 变量。
4. 服务器 → 特定客户端用 Client RPC。UI 通知、剧情触发走 Client。
5. 服务器 → 全客户端用 NetMulticast RPC。公开事件、群体效果走 Multicast。
6. Client RPC 不会在 Dedicated Server 执行。服务器逻辑放 GameMode / GameState。
7. NetMulticast 必须从服务器调用。客户端调 Multicast 不会广播。
8. RPC 关键事件用 Reliable。Unreliable 适合粒子、移动，不可滥用。
9. PIE 多人模式要常用。单人测试看不出 90% 的网络问题。
10. 联机问题先用 Net Debug。控制台命令比 Print String 高效 10 倍。

八、中级用户：带宽预算与同步策略

对中型独立游戏项目（≥ 8 玩家），中级工程师应建立"带宽预算"意识：

8.1 带宽预算参考（独立游戏常用档位）

8.2 高频同步的优化策略

• 位置同步用 Net Update Frequency 控制。默认 100Hz 太频繁，独立游戏可降到 20–30Hz。
• 远距离玩家降低同步频率。Distance-Based Net Update Frequency。
• 大对象用 Dormancy。玩家死亡或远离时进入 Dormancy 状态，完全停止同步。
• 压缩同步数据。位置用 Half Float、布尔用 Bitmask，带宽降低 30%。

8.3 多人游戏蓝图架构模板

Xmohe 推荐的"最小可行多人架构"：

• GameMode：游戏规则、玩家加入、胜负判定。
• GameState：比分、回合、时间、当前关卡。
• PlayerState：玩家分数、击杀、死亡、队伍。
• PlayerController：玩家输入、本地 UI、本地控制。
• Character / Pawn：玩家具体角色，移动 + 战斗逻辑。

这套架构在 2–32 人独立游戏场景下完全够用，且维护成本最低。