企业官网建设流程全解析

多人FPS的网络同步，是UE5里最容易让人“一看就会、一做就废”的模块。我见过太多团队，单机Demo跑得飞起，一联机就出现角色瞬移、射击打不中、载具抖动、开镜回弹这些玄学问题。更麻烦的是，这些问题往往不是某一个Bug，而是同步策略、网络频率、权限归属、插值方式几件事叠在一起产生的连锁反应。这篇内容就围绕“UE5多人FPS网络同步”这个主题，把我在实际项目里踩过的坑、验证过的方案、以及能直接抄作业的配置参数，完整拆一遍。不管你是刚接触UE5网络复制的新手，还是已经做过几款联机Demo但总感觉“同步不够跟手”的开发者，下面这些内容都能直接拿去对照排查。

1. 先搞清楚UE5多人FPS同步到底在同步什么

很多人一上来就问“怎么让角色不瞬移”，这个问题本身就不够准确。因为多人FPS的网络同步，从来不是“同步一个位置”这么简单，它至少包含四层内容：输入同步、状态同步、表现同步、时间同步。这四层如果混在一起处理，后面一定会乱。

1.1 输入同步：谁在按键，谁说了算

在UE5的多人架构里，FPS游戏最核心的一条原则是：客户端拥有输入，服务器拥有权威。也就是说，玩家按下WASD、鼠标移动、开火键，这些输入首先发生在本地客户端，但最终角色移动到哪里、子弹打中谁，必须由服务器裁定。

这就带来一个经典问题：如果客户端按下移动后，等服务器确认再移动，那玩家会感觉操作延迟极高；如果客户端自己先移动，服务器又可能判定你“瞬移”或“穿墙”。所以输入同步的本质，是在本地预测和服务器权威之间找平衡。

我通常会把输入同步拆成三个环节：

• 客户端采集输入，并立即在本地执行一次预测移动；
• 输入数据随网络包发送到服务器，服务器按同样逻辑模拟；
• 服务器把权威结果回传给客户端，客户端做校正。

这里的关键是，输入不能只发“当前按了什么”，还要带时间戳和序号。否则服务器无法判断这个输入是新的还是旧的，也无法做回滚重放。

1.2 状态同步：位置、旋转、血量、弹药

状态同步是大多数人最熟悉的部分，也就是把角色位置、旋转、速度、血量、弹药、武器状态等复制到其他客户端。UE5里常用的是Replication和RepNotify，但FPS游戏不能只靠默认复制频率。

默认情况下，Actor的复制频率受NetUpdateFrequency控制，默认值大概是100Hz，但实际网络更新并不是每帧都发。对于FPS角色，我一般会把NetUpdateFrequency设到60到100之间，同时把MinNetUpdateFrequency设到30左右，避免低优先级时完全停更。

但这里有个坑：位置复制频率高，不代表表现就顺滑。因为网络包到达间隔不均匀，如果直接硬设位置，角色会抖动。所以状态同步之后，必须接插值和外推。

1.3 表现同步：插值、外推、平滑校正

表现同步是FPS网络同步里最影响手感的一层。简单说，服务器发来的位置是离散的，客户端不能直接SetActorLocation，否则就是一顿一顿的。正确做法是：

• 对远程角色使用插值，让它在两个网络位置之间平滑过渡；
• 对本地预测角色使用校正，当服务器结果和本地预测差异过大时，平滑拉回，而不是瞬间瞬移；
• 对高速移动物体，比如子弹、投掷物，使用外推，根据速度和方向预测下一帧位置。

UE5里CharacterMovementComponent已经内置了网络预测和校正机制，但很多人不知道怎么调。比如NetworkSmoothingMode，默认是Exponential，我一般会改成Linear，因为线性插值在FPS里更可控，尤其配合NetworkSmoothingTime可以精细调节平滑时长。

1.4 时间同步：服务器时间、客户端时间、回滚

时间同步是高级话题，但FPS绕不开。比如你做击杀回放、延迟补偿、命中判定，都需要一个统一的服务器时间。UE5里可以用GetServerWorldTimeSeconds()获取服务器时间，但客户端本地时间会有偏移。

我通常会在客户端维护一个服务器时间偏移量，每次收到服务器时间包就更新一次，然后用本地时间 + 偏移量来近似服务器时间。这样在做延迟补偿时，可以把射击时刻回滚到服务器时间轴上的对应位置，再去做射线检测。

注意：时间同步不要追求绝对精确，FPS里毫秒级误差可以接受，关键是一致性。所有客户端都用同一套偏移逻辑，才能保证命中判定公平。

2. 角色移动同步：从预测到校正的完整链路

角色移动是FPS网络同步里最核心、也最容易出问题的部分。我见过不少项目，角色移动同步没做好，导致玩家互相看到对方“滑步”、“卡顿”、“回拉”。这一章就把移动同步的完整链路拆开讲。

2.1 本地预测：为什么你的角色要先动

在UE5里，CharacterMovementComponent默认就支持客户端预测。也就是说，本地玩家按下移动键后，角色会立即在本地移动，不需要等服务器确认。这是FPS手感的基础。

但预测带来一个问题：如果服务器判定你不能移动，比如撞墙了、被眩晕了，服务器会把你拉回权威位置。这个拉回过程如果太生硬，玩家就会感觉“被扯了一下”。

所以预测的关键不是“要不要预测”，而是预测之后怎么校正。我一般会关注两个参数：

• MaxSimulationTimeStep：单次模拟最大时间步长，默认0.05秒，一般不用改；
• MaxSimulationIterations：单帧最大模拟迭代次数，默认8，如果角色速度很快可以适当提高。

另外，CharacterMovementComponent里有个bNetworkSmoothing，默认开启。对于本地预测角色，这个平滑主要作用于校正过程；对于远程角色，它负责插值。

2.2 服务器权威：服务器怎么验证移动

服务器收到客户端输入后，会按同样的移动逻辑模拟一遍。如果服务器结果和客户端预测差异超过阈值，就会触发校正。这个阈值由NetworkSmoothing相关参数控制，但更关键的是服务器不能完全信任客户端。

我通常会在服务器端做几件事：

• 检查移动速度是否超过MaxWalkSpeed；
• 检查移动方向是否合理，比如是否在空中突然变向；
• 检查是否穿墙，用ServerMove里的碰撞检测；
• 对异常移动做记录，必要时回滚。

这里有个经验：不要试图在服务器端做太复杂的反作弊，否则会误伤正常玩家。比如网络抖动时，客户端预测位置和服务器位置本来就会有差异，如果阈值设得太小，玩家会频繁被拉回。

2.3 远程角色插值：怎么让别人的角色不抖

远程角色的同步，核心是插值。UE5的CharacterMovementComponent默认会对远程角色做网络平滑，但默认参数不一定适合FPS。

我一般会这样调：

这里重点说NetworkSmoothingTime。这个值越大，远程角色看起来越平滑，但延迟也越大。比如设成0.2秒，那远程角色实际位置会比服务器位置晚0.2秒。对于FPS，我一般控制在0.05到0.1秒之间，既能平滑抖动，又不会明显延迟。

另外，如果远程角色移动速度很快，比如冲刺、滑铲，可以考虑用外推来补足。UE5里没有直接的外推开关，但可以通过自定义Tick逻辑，根据速度预测下一帧位置，再做插值。

2.4 校正时的平滑处理：避免瞬移感

校正最怕的就是瞬移。玩家正跑着，突然被拉回半米外，体验极差。所以校正必须平滑。

UE5里CharacterMovementComponent的校正逻辑是：如果服务器位置和客户端位置差异超过NetworkSmoothing阈值，就触发平滑校正。但默认的平滑可能不够细腻，我一般会做两件事：

• 调整NetworkSmoothingTime，让校正过程更长一点；
• 在OnRep_ReplicatedMovement里自定义校正逻辑，用VInterpTo或FMath::Lerp做位置过渡。

这里有个坑：校正时不要只校正位置，还要校正速度。否则角色位置拉回来了，速度还是旧的，下一帧又会冲出去。正确做法是同时校正位置和速度，让角色平滑回到权威状态。

3. 射击与命中判定：延迟补偿到底怎么做

FPS游戏里，射击命中判定是网络同步的另一个核心。如果做得不好，玩家会感觉“我明明打中了，却没伤害”。这一章就讲清楚延迟补偿的原理和实现。

3.1 为什么需要延迟补偿

假设玩家A ping 80ms，玩家B ping 20ms。A看到B的位置，其实是B在80ms前的位置。如果A瞄准这个位置开枪，服务器收到时，B已经移动了。如果不做补偿，A永远打不中移动中的B。

延迟补偿的思路是：服务器收到射击请求时，把其他玩家回滚到射击者当时看到的时间点，再做射线检测。这样A打中的就是“他屏幕上看到的位置”。

3.2 服务器时间轴与回滚

实现延迟补偿，需要维护一个历史位置缓存。服务器每隔一段时间记录所有角色的位置、旋转、碰撞体状态，保存最近1秒左右的数据。

当服务器收到射击请求时：

1. 取出射击请求里的客户端时间戳；
2. 换算成服务器时间；
3. 从历史缓存里找到对应时间点的角色位置；
4. 把这些位置临时应用到角色上，做射线检测；
5. 检测完恢复当前位置。

UE5里可以用FSavedMove_Character和FNetworkPredictionData_Server_Character来扩展，但更常见的做法是自己维护一个TMap<FName, TArray<FHistoricalState>>。

3.3 射线检测与命中验证

射线检测本身不难，难的是验证。服务器不能完全信任客户端发来的“我打中了”，否则作弊器随便改。所以服务器必须自己做射线检测。

我一般会这样做：

• 客户端发送射击请求，包含：射击起点、方向、时间戳、武器ID；
• 服务器根据时间戳回滚其他角色位置；
• 服务器从射击起点沿方向做射线检测；
• 如果命中，再验证伤害、弹药、射速是否合法；
• 合法则应用伤害，广播命中效果。

这里有个细节：射击起点不要直接用摄像机位置，因为摄像机在角色头部，射线可能被自己的碰撞体挡住。我一般会从摄像机位置往前偏移一点，或者用IgnoreActorWhenMoving忽略自己。

3.4 高ping玩家的体验平衡

延迟补偿不是万能的。如果玩家ping 200ms，回滚窗口就要开很大，服务器负担重，而且容易误判。我一般会设一个最大回滚时间，比如200ms，超过这个时间的射击请求不做回滚，直接按当前位置检测。

另外，对于高ping玩家，可以适当放宽命中判定，比如用球形检测代替射线检测，或者增加命中容差。但要注意，这会影响公平性，需要根据游戏类型权衡。

提示：延迟补偿的参数不要拍脑袋定，最好用实际网络环境测试。我一般会用网络模拟工具，把ping调到50、100、150、200，分别测试命中率，再调整回滚窗口和容差。

4. 武器、载具与交互物的同步策略

FPS游戏不只是角色移动，还有武器、载具、门、开关等交互物。这些物体的同步策略和角色不同，需要单独处理。

4.1 武器状态同步：开火、换弹、开镜

武器状态包括：当前弹药、是否开火、是否换弹、是否开镜、当前武器ID。这些状态必须同步到所有客户端，否则别人看到你拿着枪却没子弹，或者你开镜了别人看你还是腰射。

我一般会把武器状态放在WeaponComponent里，用Replicated变量同步。但要注意：

• 开火这种瞬时事件，用Multicast广播，不要用RepNotify，因为RepNotify可能丢事件；
• 换弹这种持续状态，用Replicated变量，配合RepNotify更新动画；
• 开镜这种本地表现，可以本地先执行，再同步状态给服务器。

这里有个坑：开火广播不要带太多数据。我见过有人在开火Multicast里传整个武器状态，结果网络包巨大。正确做法是只传必要信息，比如射击方向、武器ID，其他状态由客户端自己维护。

4.2 载具同步：位置、旋转、乘客

载具同步比角色复杂，因为载具本身有物理模拟，还有乘客。UE5里可以用VehicleMovementComponent，但网络同步需要额外处理。

我一般会这样做：

• 载具的物理模拟在服务器端进行，客户端做预测；
• 载具位置和旋转用Replicated同步，频率可以比角色低一点，比如30-60Hz；
• 乘客位置用AttachToComponent挂到载具上，但要注意网络更新顺序，避免乘客先于载具更新导致抖动；
• 载具的输入由驾驶员客户端发送，服务器验证后应用。

这里有个经验：载具的校正要比角色更宽松。因为载具物理复杂，网络抖动时如果频繁校正，会看起来像在“抽搐”。我一般会把载具的NetworkSmoothingTime设大一点，比如0.15秒。

4.3 交互物同步：门、开关、拾取物

交互物同步相对简单，但容易忽略权限。比如一扇门，谁都可以开，那就要用Server函数，客户端调用，服务器验证后广播。

我一般会这样设计：

• 交互物有一个bIsOpen之类的Replicated变量；
• 客户端调用ServerInteract，服务器验证距离、权限后，修改bIsOpen；
• bIsOpen变化触发RepNotify，所有客户端更新表现。

拾取物类似，但要注意防止重复拾取。服务器在处理拾取时，要检查物品是否已经被拾取，避免两个玩家同时拾取同一个物品。

5. 网络频率、带宽与性能的平衡

网络同步不是频率越高越好。频率太高，带宽爆炸；频率太低，表现卡顿。这一章讲怎么找平衡。

5.1 NetUpdateFrequency与带宽估算

NetUpdateFrequency决定Actor每秒最多复制多少次。对于FPS角色，我一般设60-100。但实际带宽还要看复制了多少属性。

一个粗略的估算：

• 每个角色位置+旋转+速度，大概20-30字节；
• 加上其他状态，比如血量、武器，大概50-100字节；
• 如果60Hz更新，每个角色每秒3-6KB；
• 10个玩家就是30-60KB/s，也就是240-480Kbps。

这还没算上武器开火、命中效果等广播。所以如果带宽有限，就要降低频率，或者只复制必要属性。

我一般会用NetPriority来区分优先级。比如本地玩家角色优先级最高，远程角色次之，远处角色最低。UE5里NetPriority默认是1.0，可以按距离动态调整。

5.2 相关性（Relevancy）与优先级

UE5的Relevancy机制决定哪些Actor复制给哪些客户端。默认情况下，AActor::IsNetRelevantFor会根据距离判断。对于FPS，我一般会自定义相关性：

• 距离超过一定值（比如100米）的角色不复制；
• 不在视野内的角色降低更新频率；
• 队友始终高优先级，敌人按距离调整。

这样可以大幅降低带宽。我做过一个测试，用自定义相关性后，带宽降低了40%左右，而玩家几乎感觉不到差异。

5.3 属性复制与RPC的选择

UE5里同步数据有两种方式：属性复制和RPC。属性复制适合持续状态，比如位置、血量；RPC适合瞬时事件，比如开火、命中。

我一般会这样选：

这里有个坑：不要用属性复制传瞬时事件。比如开火，如果用Replicated变量，可能因为网络丢包导致事件丢失，玩家看到你枪口冒火但没声音。

5.4 网络模拟与性能测试

调网络同步，不能只靠感觉。我一般会用UE5自带的网络模拟工具，或者自己写一个简单的延迟模拟。

测试时重点关注：

• 不同ping下的移动表现；
• 不同丢包率下的射击命中；
• 不同带宽限制下的更新频率；
• 服务器CPU占用和带宽占用。

我一般会设几个测试场景：50ms、100ms、150ms、200ms，丢包0%、2%、5%，分别跑一遍，记录问题。

6. 常见同步问题与排查思路

这一章列一些我实际遇到过的问题，以及排查思路。这些问题不一定每个项目都会遇到，但遇到了可以对照看看。

6.1 角色瞬移、回拉、抖动

这是最常见的问题。排查顺序：

1. 检查NetUpdateFrequency是否太低；
2. 检查NetworkSmoothingMode和NetworkSmoothingTime；
3. 检查服务器校正阈值是否太小；
4. 检查是否有自定义移动逻辑绕过了CharacterMovementComponent；
5. 检查网络延迟和丢包。

我遇到过一次，角色频繁回拉，最后发现是服务器端MaxWalkSpeed设得比客户端小，客户端预测跑得快，服务器拉回。这种问题只能靠对比客户端和服务器参数来发现。

6.2 射击打不中、命中延迟

排查顺序：

1. 检查延迟补偿是否开启；
2. 检查回滚窗口是否覆盖玩家ping；
3. 检查射线检测起点是否正确；
4. 检查是否忽略了自身碰撞；
5. 检查服务器是否信任了客户端命中结果。

我遇到过一次，射击打不中，最后发现是射线检测从摄像机位置出发，被角色自己的胶囊体挡住了。改成从摄像机往前偏移50单位就好了。

6.3 武器状态不同步、开火没声音

排查顺序：

1. 检查开火是否用了Multicast；
2. 检查Multicast是否可靠；
3. 检查武器状态是否复制；
4. 检查RepNotify是否绑定正确；
5. 检查网络相关性是否导致武器Actor不复制。

我遇到过一次，远程玩家开火没声音，最后发现是武器Actor的NetRelevancy设得太低，距离远了就不复制了。把武器Actor设为始终相关就好了。

6.4 载具抖动、乘客错位

排查顺序：

1. 检查载具物理是否在服务器端模拟；
2. 检查载具位置更新频率；
3. 检查乘客Attach时机；
4. 检查载具校正是否太频繁；
5. 检查网络更新顺序。

我遇到过一次，乘客在载具上抖动，最后发现是乘客的位置更新早于载具，导致乘客先到新位置，载具还没到。把乘客的NetUpdateFrequency设得比载具低一点就好了。

7. 一些实战中的参数配置与经验

最后分享一些我常用的参数配置和经验，可以直接参考。

7.1 CharacterMovementComponent常用配置

7.2 网络相关性配置

我一般会自定义IsNetRelevantFor，大致逻辑：

• 如果Actor是本地玩家，始终相关；
• 如果距离超过100米，不相关；
• 如果距离在50-100米，降低更新频率；
• 如果不在视野内，降低更新频率。

7.3 延迟补偿配置

7.4 一些零散经验

• 不要在所有客户端上跑服务器逻辑，比如伤害计算、物品拾取，这些必须服务器做；
• 不要用Tick做网络同步，用NetUpdateFrequency和Replication；
• 不要忽略网络相关性，否则带宽会爆炸；
• 不要信任客户端发来的任何数据，包括位置、命中、伤害；
• 不要频繁校正，校正要平滑，否则玩家会晕；
• 不要忽略高ping玩家，延迟补偿要覆盖大部分玩家的ping范围。

提示：网络同步没有银弹，所有参数都要根据项目实际情况调。我一般会先跑通基础同步，再逐步优化，不要一开始就追求完美。

7.5 关于UE5新特性的使用

UE5里有一些新特性，比如Network Prediction插件、Iris复制系统，理论上可以简化网络同步。但我实际用下来，Network Prediction更适合复杂物理预测，FPS角色移动用CharacterMovementComponent已经够了；Iris目前还在完善，如果项目不急可以观望。

我一般会先用成熟方案跑通，再考虑新特性。毕竟网络同步的坑已经够多了，没必要再给自己加难度。

7.6 测试与迭代

最后说测试。网络同步的问题，很多在本地跑不出来，必须用真实网络环境测试。我一般会：

• 用网络模拟工具模拟不同ping和丢包；
• 找不同地区的玩家测试；
• 记录每次测试的问题和参数变化；
• 逐步调优，不要一次改太多参数。

我自己的经验是，网络同步调优是一个迭代过程，不可能一次到位。每次改一两个参数，测试，记录，再改。慢慢就能找到适合自己项目的配置。

这个内容后续还可以这样扩展：比如把延迟补偿做成可视化调试工具，或者把网络同步参数做成可配置的DataAsset，方便不同模式切换。这些我在实际项目里都做过，效果不错，后面有机会再单独拆。