企业官网建设流程全解析

上周有个做独立游戏的朋友半夜发消息给我，说他用 Unity 折腾了两周，单机射击手感已经调得挺舒服，结果一加联机就崩——两边玩家各打各的，子弹穿人而过，血量同步像抽奖，房主一掉线整局作废。他的问题不是代码写得差，而是从一开始就没搞清楚 PUN2 这套东西的职责边界：谁该同步位置，谁该判定命中，谁说了算。这篇就把 Unity 用 PUN2 插件实现多人联机射击游戏的完整链路拆开讲，从房间连接到位置同步，从开火射线到伤害结算，再到那些文档里不写、只有真机联调才会跳出来的坑。如果你正在做 Unity 多人在线射击 Demo、课程设计，或者想把单机射击玩法快速搬成联机版，这篇应该能帮你省下不少试错时间。

1. 为什么射击游戏原型阶段我还是推荐 PUN2

先把选型这件事说透，因为选错方案比写错代码更致命。Unity 做联机目前主流有几条路：Mirror、Netcode for GameObjects（NGO）、Photon Fusion、PUN2，以及自己拿 Socket 撸一套。它们不是谁替代谁的关系，而是适配完全不同的阶段和规模。

PUN2 最大的价值在于它把服务器这一层完全托管了。你不需要部署、不需要管端口、不需要处理 NAT 穿透，注册一个应用拿到 AppId 就能跑起来。对于射击游戏原型来说，这意味着你能在两三天内看到一个两边玩家能跑能打的版本，把精力全部砸在手感和玩法上，而不是耗在运维上。

我把几个方案的差异整理成表，方便你对照自己的项目阶段做判断：

关键差异在第二列和第三列。PUN2 是中继（Relay）模式加客户端权威，也就是说房间里某个玩家的客户端说了算，数据经过官方服务器转发。这个模型的好处是简单直接，坏处也明显：作弊成本低，玩家改个内存就能瞬移。所以 PUN2 适合 PvE 合作、朋友之间开黑、原型验证，不适合做排位天梯这种强对抗竞技。

射击游戏对网络的硬需求就三条：延迟要低、命中判定要即时反馈、状态不能漂移。PUN2 在前两条上表现够用——官方在全球有多个区域节点，选对区域后延迟通常在几十毫秒量级；命中判定我们可以做"本地即时反馈 + 房主校验"的两段式处理，这个后面细讲。

注意：PUN2 单个房间的人数上限受套餐影响，免费档通常远小于大规模战场需求。如果你的设计是 32 人以上混战，或者需要载具、大面积地图，建议直接评估 Photon Fusion 或自建方案，别硬扛。

还有一点很多人忽略：PUN2 的房间是临时的。当房间里最后一个玩家离开，房间就销毁，没有任何持久化。所以排行榜、战绩、玩家等级这些数据必须走外部存储（数据库或官方其他服务），不能指望房间帮你记住。

2. Room、Player、PhotonView：三个对象各自的职责边界

搞不清这三个东西的关系，后面写多少代码都是乱的。我用一个类比：Room 是一场球赛，Player 是场上的球员，PhotonView 是那个贴在某个人或某个物体身上的号码牌——裁判（其他玩家）靠号码牌认出"这是谁"。

PhotonNetwork是静态入口，所有操作都从它发起：连接、加入大厅、创建或加入房间、实例化对象。它不持有状态，只是一个门面。

Room 层面有几个关键属性值得记住：PhotonNetwork.CurrentRoom.Name、PlayerCount、MaxPlayers，以及最重要的MasterClient。MasterClient 是房间里被指定为"主控"的那个客户端，房间创建者默认是它，它掉线时会自动迁移到另一个玩家身上。很多人把血量、计分这些权威逻辑全挂在 MasterClient 上，却没写迁移处理，结果房主一掉线整局就废了，这是最常见的架构性错误。

Player 层面，每个玩家有PlayerNumber（房间内唯一，从 1 开始）、UserId（跨房间稳定标识）、NickName，以及CustomProperties（一个自定义属性字典）。这个 CustomProperties 是把状态同步给中途加入玩家的利器，后面讲血量同步时会用到。

PhotonView 才是 PUN2 真正的核心。它挂在预制体上，运行时被分配一个ViewID，这个 ID 在房间内唯一。通过 PhotonView，你能做两件事：

• RPC 调用：photonView.RPC("某个方法", RpcTarget.Others, 参数)，让远端执行一个瞬时动作，比如开火、播放受击特效、扣血。
• 状态序列化：实现IPunObservable接口（或挂内置的PhotonTransformView），让拥有者持续把状态推给其他人，比如位置、旋转。

这两个通道的选择是新手最容易搞混的地方。判断标准很简单：

一句话总结："发生了什么"用 RPC，"现在处于什么状态"用序列化。开火是事件，用 RPC；玩家站在哪是状态，用序列化。把位置用 RPC 高频发送，会造成大量丢包和抖动；把开火用序列化发送，会漏掉连点。这条线划清楚，代码结构立刻就顺了。

另外一个细节：PhotonView 有OwnerId，可以通过photonView.IsMine判断自己是不是拥有者。位置同步的写入逻辑只能由拥有者执行，其他客户端只读，这是避免"两边同时推位置导致抖动"的根本原因。

3. 从连接服务器到所有玩家出现在同一个场景

骨架搭建这块，我按实际顺序一步步来，每一步都有它必须存在的理由。

第一步，在 Photon 官网注册账号、创建应用、拿到 AppId。PUN2 需要一个固定的区域（Region），比如亚洲、欧洲、美国。区域选得对不对，直接决定底噪延迟。国内玩家建议选亚洲节点，实测下来大部分情况是合理的选择。

第二步，导入 PUN2 包（从 Asset Store 或官方提供的包导入），然后在 Unity 菜单里打开 Photon Unity Networking 的配置窗口，把 AppId 填进去，或者更稳妥的做法是在代码里设置：

using Photon.Pun; using Photon.Realtime; public class Launcher : MonoBehaviourPunCallbacks { void Start() { PhotonNetwork.AutomaticallySyncScene = true; // 房主切场景，所有人跟着切 PhotonNetwork.GameVersion = "0.1.0"; // 版本号不同的客户端互相看不到 PhotonNetwork.ConnectUsingSettings(); } public override void OnConnectedToMaster() { // 连上主服务器后再进大厅才能看到房间列表 PhotonNetwork.JoinLobby(); } public override void OnJoinedLobby() { // 这里可以弹 UI，让玩家点击"开始游戏" PhotonNetwork.JoinRandomRoom(); } public override void OnJoinRandomFailed(short returnCode, string message) { // 没有可加入的房间就自己开一个 var options = new RoomOptions { MaxPlayers = 8, IsOpen = true, IsVisible = true }; PhotonNetwork.CreateRoom(null, options); } }

这里有两处值得展开讲。GameVersion是一个很容易被忽略但很实用的字段：只有版本号完全一致的客户端才会被匹配到同一个大厅，这能防止旧版本客户端进了新版本房间后因为协议不一致而崩掉。

AutomaticallySyncScene打开后，MasterClient 调用PhotonNetwork.LoadLevel("Battle")，其他玩家会自动跟着加载同一个场景。但有个前提：所有人必须在同一个房间，且切场景的动作要放在大家都准备好之后，否则会出现有人还在加载、有人已经开打的情况。我的做法是用 Player 的 CustomProperties 打一个Ready标记，等房间内所有人都 Ready 了再由房主切场景。

第三步，玩家角色实例化。PUN2 的实例化不能直接用Instantiate，必须走PhotonNetwork.Instantiate，而且预制体要放在Resources目录下，或者你自己实现IPunPrefabPool接管加载：

public override void OnJoinedRoom() { // 注意路径不带 "Resources/" 前缀，也不带扩展名 PhotonNetwork.Instantiate("Player", GetSpawnPoint(), Quaternion.identity); } Vector3 GetSpawnPoint() { int index = PhotonNetwork.LocalPlayer.ActorNumber - 1; return spawnPoints[index % spawnPoints.Length].position; }

用ActorNumber来分摊出生点，能避免所有人叠在同一个位置互相顶飞。这是个很小但很实用的技巧，尤其是出生点数量少于玩家数量时，取模可以让分配自动循环。

4. 位置、朝向、开火、血量：四类数据要分开设计同步策略

这是整篇文章里我最想说清楚的一节。很多人的联机射击之所以"怪怪的"，根源就是把所有数据都当成一种东西来同步。实际上它们对延迟的容忍度、权威归属、传输通道都不一样。

先说位置。位置的写入方必须是角色的拥有者，其他客户端只读并做插值。为什么不让房主统一管所有人的位置？因为那样每个玩家的输入都要先绕一圈到房主再发回来，延迟直接翻倍，手感会糊成一团。让拥有者自己推位置，是客户端权威模型下最优的选择，代价就是作弊空间大。

再说开火。开火这块必须做本地即时反馈，也就是玩家按下鼠标的那一帧，本地立刻播放枪口火焰、音效、弹道，然后才把"我开火了"这个事件通过 RPC 发出去。如果等服务器确认再播放特效，那手感就是灾难。玩家对射击游戏延迟的容忍度极低，超过 80 毫秒就能明显感觉到"粘手"。

血量这块最讲究。命中判定如果交给开火方自己做，那就是"我说我打中了你"，作弊者可以无限命中。所以流程应该是：开火方本地做一次射线检测拿到即时反馈，同时把射线信息发给 MasterClient，由 MasterClient 再做一次校验并扣血。这个校验不需要 100% 精确，只要能把明显作弊挡掉就够了。

血量的同步有个坑我必须提前说：如果你只用 RPC 广播血量变化，中途加入的玩家永远拿不到当前血量，他进房间看到的可能是所有人满血，然后突然有人倒下。正确做法是把血量写进 Player 的 CustomProperties：

public void ApplyDamage(int actorNumber, int damage) { Player target = PhotonNetwork.CurrentRoom.GetPlayer(actorNumber); if (target == null) return; int currentHp = target.CustomProperties.TryGetValue("HP", out object hp) ? (int)hp : 100; int newHp = Mathf.Max(0, currentHp - damage); var props = new ExitGames.Client.Photon.Hashtable { { "HP", newHp } }; target.SetCustomProperties(props); }

CustomProperties 会被 Photon 自动同步给所有客户端，包括后来者，而且OnPlayerPropertiesUpdate回调能让你在任何时候刷新 UI。这个方案的额外好处是它自带一致性：无论谁在什么时候进房间，读到的血量都是权威值。

5. 开火链路落地：射线、伤害RPC与特效的分工

把上一节的策略翻译成代码，开火链路大概是这么几个环节。我按执行顺序列出来，每一步都有它的作用。

using UnityEngine; using Photon.Pun; public class Weapon : MonoBehaviourPun { [SerializeField] float damage = 25f; [SerializeField] float fireRate = 0.1f; [SerializeField] float range = 100f; [SerializeField] LayerMask hitMask; [SerializeField] GameObject muzzleFlash; [SerializeField] Transform muzzlePoint; float nextFireTime; void Update() { if (!photonView.IsMine) return; // 只看自己的输入 if (Input.GetButton("Fire1") && Time.time >= nextFireTime) { nextFireTime = Time.time + fireRate; Fire(); } } void Fire() { // 1. 本地即时反馈，先爽了再说 PlayMuzzleFlashLocal(); // 2. 本地射线检测 Ray ray = new Ray(Camera.main.transform.position, Camera.main.transform.forward); Vector3 hitPoint; int hitActor = -1; if (Physics.Raycast(ray, out RaycastHit hit, range, hitMask)) { hitPoint = hit.point; var targetView = hit.collider.GetComponentInParent<PhotonView>(); if (targetView != null && !targetView.IsMine) hitActor = targetView.OwnerActorNr; } else { hitPoint = ray.origin + ray.direction * range; } // 3. 通知所有人画弹道（不包含自己，避免重复） photonView.RPC(nameof(RpcDrawTracer), RpcTarget.Others, muzzlePoint.position, hitPoint); // 4. 把命中信息交给房主裁决 if (hitActor != -1) photonView.RPC(nameof(RpcReportHit), RpcTarget.MasterClient, hitActor, ray.origin, ray.direction, hitPoint); } [PunRPC] void RpcDrawTracer(Vector3 from, Vector3 to) { /* 画弹道线 */ } [PunRPC] void RpcReportHit(int targetActor, Vector3 origin, Vector3 dir, Vector3 hitPoint) { // 只有房主执行这里 if (!PhotonNetwork.IsMasterClient) return; // 简单反作弊：检查距离和方向合理性 Player shooter = photonView.Owner; Player target = PhotonNetwork.CurrentRoom.GetPlayer(targetActor); if (shooter == null || target == null) return; ApplyDamage(targetActor, (int)damage); // 广播命中特效 photonView.RPC(nameof(RpcPlayHitEffect), RpcTarget.All, hitPoint, targetActor); } [PunRPC] void RpcPlayHitEffect(Vector3 point, int targetActor) { /* 播特效、飘伤害数字 */ } }

这段代码里有几个关键决策点，我逐个解释。

为什么枪口火焰在本地播放，弹道却要广播给别人？因为枪口火焰是"我自己的枪"的一部分，只有我能看到，广播出去纯属浪费带宽。而弹道是别人判断"子弹从哪来"的依据，必须让所有人看到。

为什么弹道用RpcTarget.Others而不是All？这是新手最容易踩的坑之一。PUN2 的RpcTarget.All会包含发送者自己，如果你已经在本地播放了特效，再用All广播一遍，自己的屏幕上就会出现两发子弹、两个音效。要么本地不放、全靠All，要么本地放、广播用Others。我倾向后者，因为本地播放没有网络延迟，手感最好。

为什么调ApplyDamage之前要检查IsMasterClient？因为RpcTarget.MasterClient只保证发给房主，但如果代码写错用了All，这个方法会在所有客户端执行，血量就会被扣多次。加一道防御性检查是必须的。

反作弊校验怎么做才合理？别想着做到完美，那是服务器权威方案该干的事。PUN2 场景下你只需要挡住"明显不可能"的情况：开火点离目标太远、方向偏差太大、开火频率超过武器射速。这三条能挡掉 90% 的低级作弊，成本却很低。

6. 手感和流量的拉锯战：插值、量化与序列化频率

联机射击的体验好坏，一半取决于你怎么处理"别人的位置"。因为这个位置天然是滞后的——你看到的是对方几十毫秒前的状态。

最粗糙的做法是直接把收到的位置transform.position = 收到值，结果就是远端玩家一卡一卡地瞬移。正确做法是插值：把收到的位置作为目标点，本地用Lerp慢慢逼近。

using UnityEngine; using Photon.Pun; public class NetworkPlayer : MonoBehaviourPun, IPunObservable { [SerializeField] float interpolationSpeed = 12f; Vector3 networkPosition; Quaternion networkRotation; void Awake() { networkPosition = transform.position; networkRotation = transform.rotation; } void Update() { if (photonView.IsMine) return; // 自己的角色不做插值 transform.position = Vector3.Lerp(transform.position, networkPosition, Time.deltaTime * interpolationSpeed); transform.rotation = Quaternion.Slerp(transform.rotation, networkRotation, Time.deltaTime * interpolationSpeed); } public void OnPhotonSerializeView(PhotonStream stream, PhotonMessageInfo info) { if (stream.IsWriting) { // 我是拥有者，往外推数据 stream.SendNext(transform.position); stream.SendNext(transform.rotation); } else { // 我是观察者，收数据 networkPosition = (Vector3)stream.ReceiveNext(); networkRotation = (Quaternion)stream.ReceiveNext(); } } }

interpolationSpeed这个值调起来有讲究。太大了，远端角色会追得太紧，网络一抖动就跟着抖；太小了，角色看起来像在冰面上滑行，跟不上实际位置。我一般从 10 开始试，然后根据游戏节奏微调，快节奏的竞技射击可以调到 15 到 20。

接下来是带宽。位置的默认序列化是三个 float（12 字节）加四个 float 的旋转（16 字节），每次 28 字节，乘以频率和人数，很快就上去了。假设 8 人房间、每秒 15 次序列化：28 × 15 × 7 ≈ 2940 字节/秒，看起来不多，但加上其他对象（子弹、可拾取物、载具）会迅速膨胀。

优化的核心手段是量化。位置用short压缩（范围限定在地图尺寸内），旋转只发 yaw（水平朝向）用一个byte，因为射击游戏里角色基本不会翻滚：

public void OnPhotonSerializeView(PhotonStream stream, PhotonMessageInfo info) { if (stream.IsWriting) { // 把位置映射到 short 范围，精度约 1/100 米 short x = (short)(transform.position.x * 100f); short y = (short)(transform.position.y * 100f); short z = (short)(transform.position.z * 100f); stream.SendNext(x); stream.SendNext(y); stream.SendNext(z); // 只发水平朝向，把 0-360 映射到 0-255 byte yaw = (byte)(transform.eulerAngles.y / 360f * 255f); stream.SendNext(yaw); } else { short x = (short)stream.ReceiveNext(); short y = (short)stream.ReceiveNext(); short z = (short)stream.ReceiveNext(); byte yaw = (byte)stream.ReceiveNext(); networkPosition = new Vector3(x / 100f, y / 100f, z / 100f); networkRotation = Quaternion.Euler(0f, yaw / 255f * 360f, 0f); } }

改造后每次只有 7 字节，带宽直接降到四分之一。但要注意地图尺寸：short的范围是 ±32767，除以 100 就是 ±327 米。如果你的地图超过这个尺寸，得按比例缩小系数。

序列化频率通过这两个静态属性控制：

PhotonNetwork.SendRate = 30; // 网络包发送频率 PhotonNetwork.SerializationRate = 15; // OnPhotonSerializeView 的调用频率

这两个值的默认组合不一定适合射击游戏。SerializationRate决定位置刷新多快，15 到 20 是常见区间；SendRate是底层通道的发送节奏，一般设成SerializationRate的两倍比较稳。改这两个值必须在连接服务器之前，连上之后再改是无效的。

7. 只有真机联调才会跳出来的六个坑

前面都在讲"应该怎么做"，这一节讲"实际会怎么翻车"。这些坑的共同特点是：本地编辑器里跑得好好的，一联机就出问题。

坑一：子弹打两发。前面提过，RpcTarget.All包含发送者。排查方法是看你的特效播放代码是不是同时在本地和 RPC 里各写了一次。这个坑很隐蔽，因为单机测试时根本看不出来。

坑二：RPC 静默失败，一点报错都没有。PUN2 的 RPC 依赖 PhotonView，如果目标对象上没挂 PhotonView，或者ViewID不匹配，RPC 会直接消失，既不会报错也不会执行。排查时先确认photonView不为 null，再确认对象是通过PhotonNetwork.Instantiate创建的而不是普通Instantiate。用普通Instantiate创建的对象，在网络上根本不存在，这是新手最常见的失联原因。

坑三：预制体找不到，实例化报 null。PhotonNetwork.Instantiate的路径必须指向Resources目录内的预制体，路径写法不带"Resources/"前缀、不带扩展名。比如预制体在Assets/Resources/Player.prefab，路径就是"Player"。放在子目录里也行，路径写成"Prefabs/Player"。如果你不想用 Resources（它会影响打包体积），就得自己实现IPunPrefabPool接管对象的加载和回收。

坑四：房主掉线，整局垮掉。因为伤害结算、敌人生成这些逻辑挂在 MasterClient 上。解决办法是实现OnMasterClientSwitched回调，在房主切换时把必要的状态重新初始化：

public override void OnMasterClientSwitched(Player newMasterClient) { Debug.Log($"房主切换为: {newMasterClient.NickName}"); // 重新接管敌人 AI、检查所有玩家血量状态等 if (PhotonNetwork.IsMasterClient) { RespawnMissingEnemies(); ValidateAllPlayerHealth(); } }

更进一步的做法是：把房主负责的状态尽量写进 CustomProperties 或 Room 的 CustomProperties，这样房主换人了，新来的房主也能从属性里恢复出正确的状态，而不是从零开始。

坑五：玩家中途加入，看到血量全满。前面讲过，RPC 不补发。所有需要"当前值"的数据都应该走属性同步，而不是 RPC。

坑六：场景切换不同步导致的顺序错乱。房主切场景时，可能有人还在加载、有人已经开始跑了。典型表现是"我刚进战场就被打死"。解决办法是加一个准备机制，用 Player 的 CustomProperties 记录 Ready 状态，等所有人都 Ready 再切。

排查这类问题的通用思路是：先确认网络事件有没有到达，再确认业务逻辑有没有执行。在关键 RPC 的第一行加Debug.Log，配合PhotonNetwork.LogLevel = PhotonLogLevel.Full（只在调试时开，正式包一定要关掉，否则日志会拖慢帧率），基本能定位到是哪个环节断的。

8. 双开联调、延迟模拟与上线前的收尾检查

最后一个实操环节，怎么自己测。

最省事的方案是在编辑器里跑一个、打包出来跑一个。打包版本连的是同一个 AppId，进去后能互相看到。这种方式最接近真实环境，缺点是每次改代码都要重新打包，迭代慢。

想快一点，可以用 ParrelSync 这类工具，它通过符号链接复制项目目录，让你能在编辑器里同时打开多个实例，各自独立运行。改一次代码所有实例都能用，效率高很多。但要注意 ParrelSync 出来的实例共享同一个 Library 目录，某些静态状态可能会串，遇到诡异问题时先怀疑这个。

测试过程中，一定要主动模拟恶劣网络。Photon 提供了一些工具，但你也可以自己在序列化环节人为加延迟：

// 临时测试用：人为制造 150ms 延迟 System.Threading.Thread.Sleep(150);

这只是个粗暴的验证手段，用来确认你的插值逻辑在延迟下是否还稳，测试完必须删掉。

联调时我会固定检查这几项：

子弹对象回收这点特别容易忽略。如果你用PhotonNetwork.Instantiate不断生成子弹又不销毁，带宽和内存都会持续上涨。解决办法是实现IPunPrefabPool做对象池，或者至少给每个网络对象加一个生命周期销毁逻辑：

public class NetworkBullet : MonoBehaviourPun { [SerializeField] float lifeTime = 5f; void Start() { if (photonView.IsMine) Invoke(nameof(DestroySelf), lifeTime); } void DestroySelf() { // 只有拥有者有权销毁网络对象 if (photonView.IsMine) PhotonNetwork.Destroy(gameObject); } }

销毁网络对象的权限只在拥有者手上，其他人调PhotonNetwork.Destroy是无效的，这也是一个会让人困惑很久的点。

上线前记得关掉所有调试日志、确认GameVersion已经规划好升级策略、检查每个PhotonNetwork.Instantiate的预制体路径是否正确、确认SendRate和SerializationRate是在连接前设置的。这几项任何一项出错，都会在玩家那边变成难以复现的怪现象。

我个人实际做过几个 PUN2 的射击原型，最大的体会是——先把同步骨架搭稳，再往上面堆玩法。很多团队急着做武器、做技能、做地图，结果底下同步逻辑是歪的，每加一个功能就多一层抖动和不同步。反过来，如果位置、开火、血量这三条链路一开始就设计清楚了，后面加什么内容都是往上叠，不会返工。如果预算和团队允许，等玩法验证通过、确定要做长期运营时，再考虑迁移到服务器权威方案，那时候你的网络层抽象如果做得足够干净，迁移成本会低很多。