企业官网建设流程全解析

做联机项目这几年，我最大的感受是：单机功能写得再漂亮，一旦接上网络同步，很多“理所当然”的假设都会被打破。UE5把网络层封装得很完整，属性复制、RPC、Actor 同步、服务器权威，全都给你铺好了路，但正因为东西多，很多开发者一开始就绕晕了，最常见的问题就是——“明明我加了 Replicated，为什么客户端就是不更新？”这篇内容我不打算只列 API，而是结合实际的联机项目经验，把 UE5 网络同步从底层逻辑到实操落地、从服务器部署到卡顿优化，完整地过一遍。不管你是刚想给项目接入多人功能，还是已经被同步Bug折磨得睡不着，希望这篇能帮你把串联的关键环节一次性理清楚。

1. 网络同步的底层运行逻辑

1.1 谁说了算：Authority 机制

理解 UE5 网络同步，最核心的一个词就是 Authority，翻译过来就是“权威”。在多人游戏里，一个 Actor 的状态到底以谁为准？UE5 的默认答案非常明确：服务器说了算。所有需要同步的状态，真正的“真值”只存在于服务器上，客户端只是服务器的“投影”。这一点怎么强调都不为过，因为你在编码时做的每一个选择，本质上都是在回答“谁有权修改这个数据”。

为什么服务器必须有唯一的权威？你可以用一桌扑克牌来类比。如果每个玩家手里都自己维护一副牌、自己决定自己能不能赢，那整个游戏瞬间就崩了。必须有一个荷官，统一掌握牌堆，统一判定输赢，把结果分发给所有玩家。UE5 里的服务器就是那个荷官。客户端可以发送请求（RPC），但最终是否生效、以什么状态生效，都要过服务器这一关。

在引擎层面，这种权威关系体现在几个地方：

• Actor 的Replicates属性必须设为 true，这个 Actor 才会被纳入同步体系。
• Role和RemoteRole字段标记了当前端是 Authority、Simulated 还是 Autonomous。
• 本地修改一个带复制属性的变量时，如果当前端不是 Authority，修改后的值在下一次同步到来时会被服务器的真值覆盖。

记住这个结论：没有做客户端预测的情况下，客户端直接改一个复制的变量，是“白改”的，UI 上可能闪了一下，服务器数据推过来又会被打回原形。这种问题在很多新手项目里反复出现，排查的时候第一反应就是去看这个变量的写操作发生在哪一端，90% 都是客户端直接写数据造成的。

1.2 状态同步与帧同步：选对路子再动手

聊到 UE5 网络同步，绕不开两种经典架构：状态同步和帧同步。

状态同步是 UE5 原生支持得最好的方式。服务器持有游戏世界的真值，每隔一段时间把变化的状态推送给客户端，客户端负责渲染和表现。我们平时最常接触的 Actor 复制、属性同步，全都是状态同步的范畴。

帧同步则是另一种思路，它同步的不是状态，而是“操作指令”。所有客户端拿到同一组输入后，各自本地跑同一套逻辑，依靠逻辑的确定性来保证结果一致。这种方案在强调公平竞技的游戏类型里非常常见，典型代表就是 RTS 和格斗游戏。UE5 也能做帧同步，但默认框架里没有直接提供开箱即用的完整方案，通常需要自己实现输入收集、固定时间步长、确定性模拟，对工程能力要求高出不少。

我见过不少团队一上来就想搞帧同步，觉得“状态同步跟不上节奏”，结果项目做到半截发现复杂度失控。说实话，如果不是硬核竞技类且对同步精度有极端要求的玩法，UE5 默认的状态同步加客户端预测已经完全够用。比如热词里提到的“ue5 策略游戏开发实例教程”，很多 RTS 类教学也是从状态同步入手的，真正跑到全员帧同步的反而少。

做技术选型的时候一定要想清楚：你的游戏允许多少延迟？是否允许两个客户端出现短暂的不一致然后被纠正？如果你的答案是“允许”，那就老老实实走状态同步，它能让你省下大量工程量。用帧同步前，先把“确定性从哪来”这个问题解决掉，否则后面浮点数精度、物理引擎、随机种子这些坑会连着爆发。

2. 属性同步：最常用的状态分发手段

2.1 从零开始让一个带属性的 Actor 同步起来

属性同步是 UE5 网络同步里最基础、最常用、也最容易出问题的一块。我给你一个非常经典的场景：你要做一个门，玩家按键后门会自动打开，所有客户端都能看到同一个门的状态变化。

在 C++ 里，至少要完成这三步，门才算真正“同步”起来：

第一步，Actor 本身要开启复制。构造函数或者初始化逻辑里调用SetReplicates(true)，或者在蓝图 Actor 的 Class Defaults 面板里把Replicates勾上。

第二步，变量要标记为复制。C++ 里用UPROPERTY(Replicated)修饰变量，蓝图上则是在变量详情面板里把Replication设为Replicated。

第三步，在GetLifetimeReplicatedProps里注册这个变量：

void AMyDoor::GetLifetimeReplicatedProps(TArray<FLifetimeProperty>& OutLifetimeProps) const { Super::GetLifetimeReplicatedProps(OutLifetimeProps); DOREPLIFETIME(AMyDoor, bIsOpen); }

这三步缺一不可。很多人只做了前两步，忘了第三步，结果变量在 C++ 里死活不同步，在那个地方卡了一下午的大有人在。

蓝图里同样要注册吗？蓝图不需要手动写DOREPLIFETIME那一层，只要变量勾了Replicated，引擎会自动处理。但对应的代价是，蓝图变量同步在通信效率上不如 C++ 可控，复杂的网络逻辑我建议还是落到 C++ 层来定制。

再补充一个容易忽略的细节：如果你的门是运行时动态生成（SpawnActor）的，生成的 Actor 必须也开启复制，并且由服务器负责生成。客户端本地 Spawn 一个 Actor，即使这个 Actor 的类设置了Replicates，服务器也不会自动把它广播给别人。一个规范化做法是：客户端发起生成请求，通过 RPC 通知服务器去生成，再由服务器复制度的机制同步给所有客户端。

2.2 同步频率与条件控制：不是所有数据都值得高频同步

属性同步不是“开了就好”，更常见的坑是把所有数据一股脑全设成高频同步，最后游戏还没上线，服务器带宽先把项目搞崩了。

UE5 里有一个概念叫NetUpdateFrequency，默认值是 100，意思是这个 Actor 每秒最多向客户端同步 100 次。对玩家角色的移动来说，100Hz 基本是必需的；但放到门上、灯光上、普通 NPC 上，完全没必要。我通常会把非玩家类 Actor 的NetUpdateFrequency降到 10 甚至 5。

除了频率控制，你还可以在不同的属性上附加同步条件，最常见的是DOREPLIFETIME_CONDITION：

DOREPLIFETIME_CONDITION(AMyCharacter, Health, COND_None); DOREPLIFETIME_CONDITION(AMyCharacter, bIsAiming, COND_SkipOwner);

COND_SkipOwner的意思是：拥有这个 Actor 的客户端（比如角色自己）不会被同步这个属性，因为本地已经知道了；但其他客户端需要被同步。这种条件控制在多人射击游戏里非常常见，能显著减少重复数据的传输量。

还有个经常被忽略的点：结构体复制。结构体可以作为属性同步，但引擎只会判断整个结构体有没有被标记过DOREPLIFETIME，它不会关心结构体内部哪个字段变了。哪怕只是结构体里一个 bool 翻转，整个结构体都会被重新完整发送。所以如果你的结构体体积很大又频繁改动，建议拆成多个原子属性，或者使用专门的快速数组同步方案。

2.3 复杂数据的同步：数组与专用同步通道

数组在 UE5 网络同步里是一个经典痛点。普通TArray<UPROPERTY(Replicated)>复制在大版本改动时可以工作，但它的性能表现很差，也不支持增量更新。UE5 官方推荐的方案是FFastArraySerializer，它把数组容器包装成一个支持增量的序列化器，元素增删时只发送变化的部分，而不是整个数组重新传一遍。像拾取物列表、战斗单位的动态增删、怪物刷新点列表，用FFastArraySerializer都会有非常明显的带宽改善。

FFastArraySerializer的写法和普通数组不太一样，需要自定义一个结构体并实现相关接口。核心思路是：每一个元素都有一个唯一的 ReplicationID，引擎通过这个 ID 识别哪些元素变化了、哪些被删了，按需增量推送。虽然第一次写的时候感觉有点绕，但它应该是多人项目里处理动态列表的默认选择。

还有一个建议：处理同步逻辑时，尽量保持“服务器数据模型”和“客户端表现模型”分离。服务器上的门就只存一个bIsOpen和位置信息，客户端负责播放音效、动画、特效。如果你把一堆表现相关的数据也塞进同步变量里，带宽会被迅速拖垮。

3. RPC 调用：让事件真正跨机器执行

3.1 三类 RPC 的调用关系与真实场景

属性同步负责“状态的持续分发”，而 RPC 负责的是“事件的即时触发”。UE5 的 RPC 分成三类：Server、Client 和 Multicast。搞清楚谁调用、谁执行、应该用在哪，比背定义重要得多。

接着用门的例子说。玩家按下了 F 键，希望门打开。这个交互请求必须先发给服务器，因为只有服务器有权决定门是否真的能打开。这时候客户端调用一个 Server RPC，比如Server_OpenDoor，代码会从客户端跑到服务器上执行。服务器验证没问题后，需要让其他所有客户端也看到门打开的状态。这里有两种方案：一种是直接修改服务器的bIsOpen变量，靠属性同步自然分发；另一种是调用一个 Multicast RPC，让服务器和所有客户端同时执行开门动画或音效。

Multicast RPC 在有些场景下比属性同步更直接，比如爆炸、一次性特效、广播类事件。但它的代价是，每次调用都会向所有连接的客户端发送一份完整数据。如果频率高、参数多，会对带宽产生明显压力，所以不建议把高频状态更新通过 Multicast 传递。能用属性同步解决的，优先属性同步；RPC 只负责“事件性和瞬时性”较强的行为。

Client RPC则是反过来：服务器调动，指定的客户端执行。典型场景是服务器要向某个玩家客户端展示专属的通知、界面交互、或者把某段数据直接推给该玩家。例如，服务器验证玩家可拾取物品后，调用该玩家专属的 Client RPC，把拾取结果和物品数据发给它，客户端再播放拾取表现。

把这三种 RPC 的调用关系和适用场景理顺，踩坑就少了一半。整理出来就是下面这张表：

3.2 服务端校验：永远不要信任客户端传来的数据

RPC 的安全性是我每个联机项目都要反复强调的点。一个 Server RPC 从客户端发出来，它携带的所有参数都是“不可信”的。攻击者完全可以通过修改客户端代码，伪造出他根本没资格发起的请求。

所以，每个 Server RPC 都应该做校验。UE5 提供了WithValidation关键字，允许你写一个_Validate函数，在服务器执行_Implementation之前先做参数检查。比如开门的例子，校验函数里至少要检查两件事：一是角色位置和门的距离是否真的足够近，二是当前门是否真的处于可以打开的状态。

UFUNCTION(Server, Reliable, WithValidation) void Server_OpenDoor(); bool AMyDoor::Server_OpenDoor_Validate() { return bCanOpen && GetDistanceTo(GetWorld()->GetFirstPlayerController()->GetPawn()) < 200.0f; } void AMyDoor::Server_OpenDoor_Implementation() { bIsOpen = true; OnRep_OpenDoor(); }

注意，WithValidation里不能执行真正的状态修改，它只是“安全检查”。真正改状态一定要放到_Implementation里。

如果校验失败，服务器会直接丢弃这次 RPC，客户端这边会表现成“没反应”。从玩家视角看，这是一件好事，因为它保证了游戏规则不被破坏。顺带一提，移动端项目里，很多从触摸蓝图发起的操作也会走 Server RPC，比如热词里提到的“ue5双指触摸蓝图”，双指缩放、双指旋转这类操作如果涉及游戏状态，就必须通过校验后再同步给服务器，否则会出现两个玩家看到完全不一致的结果。

3.3 广播与定向分发：避免 Mulitcast 滥用

很多开发者第一次做网络功能时，容易把 Multicast 当成“万能同步工具”：不知道用属性同步还是 RPC 时就上一个 Multicast，结果项目越来越卡。

这里我想说清楚两个容易被忽略的事实。

第一，客户端调用的 Multicast 只在本地执行。意思是你在一个客户端本地调用 Multicast RPC，不会有任何效果传到服务器或者别的客户端。如果想让所有客户端都执行，Multiicast 必须由服务器调用，或者由客户端先通过 Server RPC 通知服务器，再由服务器去调 Multicast。这个逻辑链条一旦搞反，你常见的现象就是“我这台机器上有反应，其他玩家全看不到”。

第二，Reliable Multicast 有队列压力。Reliable 保证消息不会丢，但它靠的是缓冲区重发机制。如果短时间内调用大量 Reliable Multicast，通道会被撑爆，甚至造成连接断开。所以我建议：凡是高频事件，优先属性同步配 OnRep；凡是低频但需要全量广播的事件（比如爆炸、死亡、比赛开始），才用 Multicast，而且要谨慎压参数体积。如果某些事件只需要发给特定客户端，就老老实实用 Client RPC 定向发送，别一锅端。

4. 服务器编译部署与网络环境搭建

4.1 编译一个独立服务器进程

做了那么多网络逻辑，总得跑起来验证。UE5 里最正规的联机验证方式，是先编译一个 Dedicated Server，也就是专用服务器，然后让客户端连接它。热词里“ue5 服务器如何编译和部署”其实问的是同一个问题，这儿我给出我的常规流程。

如果你想在 Windows 上跑一个专用服务器，最简单的方式是用编辑器自带的“Launch”功能：菜单栏选择 Platforms -> Windows -> Launch Dedicated Server。它会启动一个缩略的服务器进程，不渲染画面，只跑完整逻辑。但要注意，这种方式需要项目已经启用了服务器构建相关配置，在 Project Settings -> Target 里确认 Dedicated Server 相关的 Target 存在（一般默认就有）。

真正要部署到机房或者局域网主机时，需要打包。打包服务器的核心步骤：在 Build Configuration 里通常选 Development，平台选 Linux 或 Windows，勾选打包服务器相关的选项。打包完成后，Linux 服务器通常是一个可执行二进制，启动时附加参数-server，并指定端口：

./YourProjectServer LinuxServer -server -port=7777

核心端口默认是 7777，这个是 UDP 端口，用于游戏数据传输。如果你的服务器有多张网卡，或者想绑定特定 IP，可以通过-multihome=0.0.0.0这样的参数控制。我在实际部署时还遇到过防火墙没放行 UDP 7777 端口、客户端一直卡在连接界面的情况，排查了半天才发现是安全组规则的问题，所以如果你连不上服务器，先检查防火墙，不要急着怀疑项目代码。

4.2 网络驱动与连接配置

UE5 的网络传输默认走的是IpNetDriver，相关的配置在DefaultEngine.ini里可以覆盖。一些关键参数值得你自己调一下：

[/Script/OnlineSubsystemUtils.IpNetDriver] MaxClientRate=100000 NetServerMaxTickRate=30

MaxClientRate可以限制服务器向每个客户端发送数据的最大速率，单位是字节每秒。如果你的游戏是轻量级页游式同步，可以调小一点；如果是重网络游戏，需要适当加大。NetServerMaxTickRate表示服务器每秒最大网络更新次数，默认一般是 30，对大部分游戏够用，但对高精度同步类玩法，可能需要结合NetUpdateFrequency统一调优。

还有一个经常被忽略的点：UE5 的网络驱动默认使用 UDP 协议。UDP 的好处是低延迟，坏处是不可靠，所以引擎才设计了 Reliable RPC 和属性同步的定期重传机制。如果你在局域网内测试，偶尔一次包丢失不会有大问题；但如果是公网环境，延迟和丢包的影响会被成倍放大，所以网络拓扑和机房的规划也要提前想好。

4.3 本地多人联调的完整路径

我的日常联调套路一般是这样的，分享出来供你参考：

第一步，本机开一个编辑器，把当前关卡作为 Listen Server 运行，也就是“服务器+客户端二合一”的运行模式。这样我可以在编辑器里同时看到服务器视角的画面。

第二步，再开 2 到 4 个独立客户端进程，或者用-game命令行参数启动。这一步可以通过命令行快速执行：

YourGame.exe 127.0.0.1:7777 -game

第三步，打开 UE5 自带的网络模拟功能。Console 命令Net PktLag=100可以模拟 100ms 延迟，Net PktLoss=5可以模拟 5% 丢包。这个工具非常关键，很多同步问题在零延迟环境下根本暴露不出来，一加上延迟和丢包就现出原形。

我记得有一次排查一个技能命中判定问题，关掉网络模拟时一切正常，一旦加 50ms 延迟就开始出现偶尔失效的情况。最后定位到问题不在 RPC 本身，而是客户端位置预测和服务端判定时刻存在约 80ms 的偏差。没有网络模拟工具，这种问题根本不可能在开发阶段被发现。

5. 卡顿与帧同步优化实践

5.1 延迟是从哪里来的

“卡顿”这个词在联机游戏里其实很模糊。很多卡顿根本不在网络上，而在渲染和逻辑上。排查的第一步，是先区分“渲染卡顿”和“网络同步卡顿”。

渲染卡顿的典型表现是：FPS 数字波动大，即使一个人在房间里跑也会卡。网络同步卡顿的典型表现是：本地画面流畅，但其他玩家的角色是瞬移的，或者交互后要过一会儿才有反应。

网络同步延迟由三部分组成：客户端上传时间 + 服务器处理时间 + 服务器下发时间。UE5 里的网络同步是周期性进行的，不是事件驱动的，所以即使服务器处理很快，也要等到下一个同步 tick 才会把数据发出去。如果NetUpdateFrequency是 100Hz，那理论最大等待间隔是 10ms；但如果服务器帧率本身很低，实际同步间隔会被进一步拉大。

游戏里常见的“打起来就卡”现象，很多时候不是网速问题，而是服务器在重负载下丢帧、阻塞，导致网络同步 tick 跟着变慢。这时候优化方向应该是服务器逻辑的轻量化、锁和阻塞、GC 压力，而不是一味加大带宽。

5.2 帧同步卡顿的系统性排查思路

热词里的“卡顿帧同步网络优化”，其实是一整套排查流程。我的习惯是这么做的：

先从宏观判断瓶颈在渲染层、逻辑层还是网络层。开控制台命令Stat FPS看帧率，Stat Net看网络同步状态，Stat Game看游戏逻辑耗时。如果Stat Net里显示带宽占用已经接近上限，那多半是属性同步和 RPC 设计得太粗糙；如果Stat Game显示逻辑耗时很高，那就该去优化服务器端的 Gameplay 代码。

再用网络模拟工具复现问题。加延迟、加丢包，观察哪个环节开始出现可感知的不一致。如果只在丢包时出现瞬移，说明你的同步策略缺少插值和预测；如果只在延迟增大时出现交互延迟，说明 RPC 设计或服务器处理延迟有问题。

最后，配合Network Profiler或Insights看每帧的网络包大小和同步 Actor 数量。有时候你会惊讶地发现，一个场景里同时同步了上百个无意义的小物件，每一个都在传位置旋转，带宽就是这样被吃光的。

5.3 可以立刻上手的优化方案

在我的项目里，下面这几招基本是稳定有效的：

1. 降低非关键 Actor 的NetUpdateFrequency。门、灯、装饰物，从默认 100 降到 5 到 10，观感几乎不受影响，但总带宽能降一大截。

2. 设置NetPriority。重要 Actor（如玩家角色、正在交战的单位）的优先级调高，让它更早被发送；低优先级 Actor 在带宽紧张时自动降级。

3. 用NetLoadOnDemand或 World Partition 相关功能做兴趣管理。离客户端很远的 Actor，可以不发送或者只发低频状态。对于大世界项目来说，这几乎是必须的。

4. 客户端做插值平滑。服务器状态到达有时间间隔，如果客户端直接硬切值，表现上就是瞬移。UE5 的CharacterMovementComponent自带插值，但如果是自己写的同步组件，一定要手动做平滑过渡，否则网络只要抖一下，画面就会非常生硬。

5. 避免所有数据都走 Reliable 通道。不可靠数据能用的尽量用Unreliable，引擎会定期重传属性同步数据，但不会重传 Unreliable RPC。位置、旋转这类高频数据完全可以用 Unreliable，丢了就丢了，下一帧还有；但“玩家是否死亡”“门是否打开”这类关键状态，必须 Reliable，绝不能丢。

有时候你会看到一个“奇怪”的现象：网络明明不卡，但某个客户端就是感觉像被拖慢了一样。这时候大概率是服务器端某个耗时操作阻塞了 GameThread，导致网络同步 tick 被拖慢。我们上次排查类似问题，最后定位到是某个寻路接口在极端情况下触发了死循环，服务器帧率从 60 掉到个位数，所有客户端都跟着卡。所以优化网络，很多时候也是在优化服务器的整体性能和稳定性。

6. 常见问题与排查技巧实录

6.1 属性不同步，先按顺序排查五件事

属性不同步是最常见的问题，我在群里答疑时几乎每周都会遇到一次。我的排查顺序已经固化下来了，如果你也遇到“明明开了复制但客户端没变化”，按这个顺序往下查：

1. Actor 本身的Replicates是否打开了？如果 Actor 没有开启复制，里面所有变量的同步都不会生效。
2. 具体属性是否加了Replicated标记？只给 Actor 开启复制，不代表它的每个属性都自动同步。
3. C++ 里是否在GetLifetimeReplicatedProps里注册了？这一步漏掉，属性就不会进入复制生命周期。
4. 数据是不是在服务器端改的？如果你在客户端改了值，会被服务器的真值覆盖掉。
5. 服务器和客户端是不是可能走了不同的逻辑分支？比如服务器if进去了，客户端else，两边状态自然对不上。

这五步走完，90% 的属性不同步问题都能解决。剩下 10% 的情况，往往和组件同步有关：组件的属性也要在组件类里单独处理，不会因为我给 Owner Actor 开了复制就自动复制。这个问题很隐蔽，因为编译不报错、运行不崩溃，就是不同步，只能靠经验定位。

6.2 RPC 不执行，逐个排除这些原因

RPC 不执行是仅次于属性不同步的第二大疑难杂症。我整理过自己遇到过的几类典型原因：

• 调用端不是客户端时调用了 Server RPC。Server 函数名以Server_前缀只是约定，引擎真正判断的是关键字Server。如果你在服务器上调用一个 Server RPC，它不会执行“远程”逻辑，而是直接走本地实现，有时这会导致逻辑执行了两遍。
• Multicast RPC 在客户端被调用，本地能执行，但其他客户端收不到。前面提过，非服务器调用的 Multicast 只有本地生效。
• 参数类型不支持复制。RPC 参数必须是可复制的类型，自定义结构体必须实现复制相关的成员，否则会被直接丢弃。
• Reliable 通道被压满。频繁的 Reliable RPC 会把缓冲区撑爆，后续的 Reliable RPC 会排队甚至被丢弃。这时候服务器日志里通常会有网络阻塞相关的警告。
• Actor 的所有权问题。客户端只能对“自己拥有”的 Actor 调用 Server RPC。如果这个 Actor 的所有者是别人或者没有所有者，调用会被服务器直接忽略。这是一个非常容易踩的坑，尤其是动态生成的非玩家 Actor，生成时必须指定好 Owner。

排查 RPC 问题时，我的建议是先在服务器或客户端的日志里打点，确认函数到底有没有被调用、在哪一端被调用。网络问题最怕猜，你能做的就是把入口和出口都打上日志，用事实说话。

6.3 实战中沉淀下来的几个小技巧

最后分享几个我最近几年做联机项目攒下来的实操技巧，不算什么高深理论，但很能救急。

第一个是联机调试时一定给日志加上来源前缀。我自定义了简单的打印函数，会自动在日志前加上[SERVER]或[CLIENT]前缀，一眼就能看出这段逻辑是在哪一端执行的。很多人调网络问题调了半天，最后发现日志信息混在一起，根本分不清哪条来自哪端，白费很多时间。

第二个是善用控制台模拟极端网络环境。Net PktLag、Net PktLoss、Net PktDup这几个命令可以在开发阶段精确模拟出公网环境下才有的延迟和丢包。千万不要只在零延迟环境下测试，否则你提交给服务器的第一个版本就可能被玩家反馈的卡顿打回来。

第三个是关于蓝图网络同步的建议：尽量减少蓝图中的复制变量数量，网络关键逻辑尽可能落到 C++。蓝图变量同步虽然方便，但调试时很难看到底层传输细节；C++ 层面则可以配合Network Profiler进行更细粒度的带宽分析和优化。这不是说不能用蓝图，而是要把敏感的、高频的数据放在更可控的层级。

第四个，也是我自己最深的体会：网络同步方案的“设计”比“实现”重要太多了。你在开始写第一个复制变量之前，就应该把哪些数据归服务器管、哪些事件走 RPC、哪些表现只在本地做，全部列成一张清单。否则后期来回重构的代价，往往比你想的多得多。

最后再补一句，很多情况下玩家看到的“卡”，根源不是网络，而是服务器逻辑过重、客户端插值策略不当，以及滥用高频率同步导致的带宽打满。从数据流的角度去画一遍你的同步链路，通常会比盲目堆硬件有效得多。希望这篇内容能帮你少踩几个我当年踩过的坑，后续如果大家有感兴趣的方向，比如移动同步、GAS 网络同步、或者世界分区下的同步配置，我可以再单独拆开写写。