企业官网建设流程全解析

1. 项目概述：为什么是Mirror？

如果你正在用Unity做网络游戏，或者打算涉足这个领域，那么“Mirror”这个名字你大概率绕不开。它不是Unity官方的网络方案，但在社区里，它的流行度几乎已经成了事实标准。我自己从UNet（Unity旧版网络系统）时代一路踩坑过来，再到Mirror，感触最深的就是：Mirror的出现，让Unity网络开发从“玄学调试”变成了“有迹可循的工程”。

简单来说，Mirror是一个开源的、高性能的Unity网络库，它最初是基于Unity已经废弃的UNet HLAPI（高层API）的一个分支。但别被“分支”这个词骗了，Mirror团队对它进行了大刀阔斧的重构和优化，修复了大量UNet的Bug，增加了许多现代网络游戏需要的特性，比如更好的权威服务器支持、更灵活的序列化、以及一个活跃的社区。它的核心目标是让开发者能更轻松地构建多人游戏，无论是小型合作游戏还是大型多人在线游戏（MMO）的雏形。

为什么选择Mirror而不是直接上Socket或者用更新的Netcode for GameObjects？对于大多数中小型团队和独立开发者而言，Mirror提供了一个绝佳的平衡点。它封装了底层网络通信的复杂性（比如连接管理、消息分发、RPC调用），让你可以用近乎写单机游戏逻辑的思维去写网络同步代码，同时又保留了足够的控制权和性能优化空间。Netcode for GameObjects是Unity官方的新方案，功能强大且与Unity深度集成，但它相对较新，社区生态和成熟案例目前还不如Mirror丰富。而直接使用原始Socket，那意味着你要自己处理几乎所有网络层的问题，对于游戏原型开发和中小项目来说，开发成本太高了。

所以，这个系列的目标很明确：我们不只讲Mirror的API怎么调用，那是手册的工作。我们要做的是，从一个实际网络游戏开发者的视角，带你理解Mirror背后的设计思想，掌握如何用它构建一个健壮、可扩展的网络架构，并避开那些我亲自踩过、教科书上不会写的“坑”。无论你是刚接触网络同步的新手，还是从其他网络库迁移过来的老手，这个系列都会提供实实在在的、能落地的经验。

2. 核心概念与架构拆解

在动手写代码之前，我们必须把Mirror里几个最核心的概念掰扯清楚。很多人在刚接触时觉得同步效果不对，多半是因为对这些基础概念的理解有偏差。

2.1 网络拓扑：客户端与服务器的角色

Mirror主要支持两种网络拓扑，理解它们决定了你整个游戏的架构。

1. 监听服务器模式这是最常见、也是Mirror默认推荐的模式。在这个模式下，有一个独立的、权威的服务器进程（可以是你自己启动的一个Unity构建，也可以是专用的服务器程序）。所有客户端都连接到这个服务器。服务器拥有游戏状态的“唯一真相”，客户端只是状态的观察者和输入指令的发送者。

• 服务器：运行完整的游戏逻辑，验证所有客户端操作，计算游戏状态，并将状态同步给所有客户端。
• 客户端：接收服务器的状态更新，渲染画面，收集本地玩家输入并发送给服务器。
• 适用场景：几乎所有需要公平性和反作弊的竞技游戏、MMO、大型多人在线游戏。这是构建权威服务器的基石。

2. 主机模式这种模式下，其中一个客户端同时兼任服务器。这个特殊的客户端被称为“Host”。它既运行服务器逻辑，也运行客户端逻辑。其他客户端则作为纯客户端连接到它。

• Host（主机客户端）：拥有服务器和客户端的双重身份。本地玩家操作有“零延迟”的优势，因为不需要网络往返。
• 纯客户端：与监听服务器模式下的客户端无异。
• 适用场景：局域网游戏、合作P2E游戏、开发测试阶段快速联机。它的优点是部署简单，但缺点是Host玩家拥有不公平的优势（零延迟），且如果Host掉线，整个游戏就结束了。

注意：很多新手会把“主机模式”和“P2P”混淆。Mirror本身不直接支持纯P2P（每个客户端直接互联）。主机模式本质上还是C/S架构，只是服务器和其中一个客户端重合了。

2.2 身份与权限：NetworkIdentity与NetworkBehaviour

这是Mirror同步机制的基石，必须吃透。

NetworkIdentity你可以把它理解为一个网络对象的“身份证”。任何需要在网络上存在的GameObject，都必须挂载一个NetworkIdentity组件。这个组件会为游戏对象分配一个在网络中唯一的NetId。服务器通过这个NetId来管理对象的生成、销毁和所有权。

NetworkBehaviour这是你编写网络逻辑的地方。任何包含网络同步变量或RPC方法的脚本，都必须继承自NetworkBehaviour，而不是普通的MonoBehaviour。NetworkBehaviour提供了网络相关的生命周期钩子和属性，比如：

• isServer: 当前是否在服务器端运行。
• isClient: 当前是否在客户端运行。
• isLocalPlayer: 当前对象是否代表本地控制的玩家。
• hasAuthority: 当前客户端是否对此对象拥有控制权（所有权）。

理解isServer和hasAuthority的区别至关重要。isServer是一个运行时角色判断，而hasAuthority是关于对象控制权的。例如，在监听服务器模式下，服务器上所有对象的isServer都为true，但只有服务器本身对它们拥有hasAuthority（因为服务器是权威的）。一个客户端拥有的玩家对象，在该客户端上hasAuthority为true，但在服务器和其他客户端上则为false。

2.3 同步的两种核心方式：SyncVar与RPC

Mirror提供了两种主要的数据同步机制，它们的使用场景截然不同。

SyncVar（同步变量）用于自动同步服务器上某个变量的值到所有客户端。你只需要在NetworkBehaviour脚本中，给一个字段加上[SyncVar]特性即可。

public class PlayerHealth : NetworkBehaviour { [SyncVar] public int currentHealth = 100; }

• 工作原理：当服务器上currentHealth的值发生变化时，Mirror会自动将这个变化发送给所有客户端，客户端会自动更新本地的值。
• 特点：声明式，简单。但同步是单向的（服务器->客户端），且默认只在值改变时同步。对于频繁变化的数据（如位置），有性能开销。
• 钩子函数：你可以为SyncVar指定一个钩子（hook），当值在客户端发生变化时，自动执行某个方法，用于更新UI或播放效果。

  [SyncVar(hook = nameof(OnHealthChanged))] public int currentHealth = 100; void OnHealthChanged(int oldValue, int newValue) { // 在客户端更新血条UI healthBar.fillAmount = newValue / 100f; if(newValue < oldValue) PlayHurtEffect(); }

RPC（远程过程调用）用于在网络上执行一个特定的方法。分为两种：

• [Command]: 由客户端调用，在服务器上执行。用于客户端向服务器发送操作请求。

  [Command] void CmdFire() { // 在服务器上执行：生成子弹、计算伤害、验证操作合法性 if (currentAmmo > 0) { // ... 生成逻辑 RpcOnFire(); // 通知所有客户端播放开火效果 } }

  规则：Command方法名必须以Cmd开头。它只能由拥有该对象Authority的客户端调用（通常是本地玩家对象）。

• [ClientRpc]: 由服务器调用，在所有客户端（或指定客户端）上执行。用于服务器向客户端广播事件或效果。

  [ClientRpc] void RpcOnFire() { // 在所有客户端上执行：播放枪口火焰、音效等视觉效果 muzzleFlash.Play(); audioSource.Play(); }

  规则：ClientRpc方法名必须以Rpc开头。它只能在服务器端调用。

SyncVar vs RPC 如何选择？这是一个经验问题。我的原则是：

• 状态同步用SyncVar：比如生命值、分数、装备属性等离散的、变化不极端频繁的状态。
• 事件通知用RPC：比如玩家开火、使用技能、触发爆炸等瞬时事件。用Rpc来触发客户端的视觉效果和音效。
• 输入请求用Command：所有玩家输入（移动、攻击、交互）都应通过Command发送到服务器验证执行，绝不允许客户端直接修改游戏核心状态。

3. 环境搭建与第一个网络对象

理论说再多，不如动手跑一遍。我们来搭建一个最小的Mirror项目，并创建一个会同步移动的玩家立方体。

3.1 安装与基础配置

1. 创建新项目：使用Unity Hub创建一个新的3D核心模板项目。
2. 安装Mirror：最推荐的方式是通过Unity的Package Manager从Git URL安装，这样可以获得最新版本。
   • 打开Window > Package Manager。
   • 点击左上角+号，选择Add package from git URL...。
   • 输入Mirror的Git仓库地址：https://github.com/MirrorNetworking/Mirror.git
   • 点击Add。等待下载和导入完成。你也可以在Asset Store搜索“Mirror Networking”安装，但更新可能不如Git及时。
3. 检查导入：导入成功后，你会在菜单栏看到Window > Mirror选项，并且Project窗口会有Mirror和Plugins文件夹。

3.2 创建网络管理器与场景

Mirror需要一个NetworkManager组件来管理整个网络会话。这是你的网络游戏“大脑”。

1. 创建空对象：在场景中创建一个空的GameObject，命名为“NetworkManager”。
2. 添加组件：选中它，在Inspector中点击Add Component，搜索并添加NetworkManager组件。
3. 配置NetworkManager：
   • Network Manager组件上有很多字段，我们关注几个关键的：
   • Offline Scene/Online Scene: 分别指定断开连接后和成功连接后加载的场景。我们先不填，用同一个场景。
   • Player Prefab: 这是最重要的之一！它定义了当玩家连接时，服务器会在场景中为这个玩家生成哪个预制体作为其代表。我们现在还没有，稍后创建。
   • Spawn Prefabs: 一个列表，用于注册所有可能通过网络动态生成的预制体（比如子弹、怪物、道具）。任何需要通过NetworkServer.Spawn()生成的预制体都必须在这里注册。

3.3 制作第一个可同步的玩家预制体

现在我们来创建那个“Player Prefab”。

1. 创建玩家对象：在场景中创建一个Cube，重命名为“PlayerCube”。
2. 添加网络身份：选中PlayerCube，点击Add Component，搜索添加NetworkIdentity。这是必须的。
3. 编写网络移动脚本：创建一个新的C#脚本，命名为PlayerMovement。

   using Mirror; using UnityEngine; public class PlayerMovement : NetworkBehaviour { public float moveSpeed = 5f; void Update() { // 关键：只有本地玩家控制的角色，才处理输入和移动 if (!isLocalPlayer) return; float h = Input.GetAxis("Horizontal"); float v = Input.GetAxis("Vertical"); Vector3 movement = new Vector3(h, 0, v) * moveSpeed * Time.deltaTime; transform.Translate(movement); } }

   代码解读：
   • using Mirror;：引入Mirror命名空间。
   • 继承自NetworkBehaviour。
   • if (!isLocalPlayer) return;：这是网络游戏脚本的黄金法则。它确保输入处理和客户端预测等逻辑只对本地玩家对象执行。其他玩家同步过来的对象会直接跳过这部分，避免你的输入错误地控制别人的角色。
4. 挂载脚本：将PlayerMovement脚本拖到PlayerCube上。
5. 制作预制体：将Hierarchy中的PlayerCube拖到Project窗口的Assets文件夹中，创建一个预制体。然后删除场景中的PlayerCube实例。
6. 关联预制体：回到NetworkManager的Inspector，将刚刚创建的PlayerCube预制体拖到Player Prefab字段中。同时，点击Spawn Prefabs列表下的+号，也把这个预制体添加进去（虽然玩家连接是自动生成的，但注册在这里是个好习惯）。

3.4 运行测试：监听服务器与客户端

Mirror提供了一个方便的UI来快速测试网络功能。

1. 添加网络管理器HUD：选中场景中的NetworkManager对象，点击Add Component，搜索添加NetworkManagerHUD。这是一个简单的内置UI，用于启动服务器和客户端。
2. 运行游戏：点击Unity编辑器上的播放按钮。
3. 启动服务器：游戏运行后，屏幕左上角会出现几个按钮。点击LAN Host (H)。这会启动一个主机（同时是服务器和客户端）。
4. 启动另一个客户端：不要停止当前运行。在Unity编辑器的顶部菜单栏，选择File > Build and Run（或者先Build，再运行exe）。在构建出来的游戏程序中，同样点击LAN Client (C)。
5. 观察同步：现在你应该有两个窗口在运行。在作为Host的编辑器窗口里，用WASD移动立方体。你会看到，在另一个客户端窗口里，这个立方体也在同步移动！但是，在客户端窗口里移动是无效的，因为它的输入逻辑被isLocalPlayer判断过滤了。

恭喜！你已经完成了第一个Mirror网络对象的创建和基础同步。但这只是开始，我们移动的同步目前是“视觉欺骗”，因为移动逻辑只在本地客户端执行，并没有经过服务器验证，其他客户端看到的位置只是本地客户端NetworkTransform（如果用了的话）同步的结果。在真正的权威服务器架构中，移动逻辑必须放在服务器上。我们将在下一章深入探讨如何实现权威移动同步。

4. 实现权威服务器下的移动同步

刚才的例子中，移动是客户端决定的，这显然不安全（客户端可以开变速齿轮）。现在我们来改造它，实现一个经典的“客户端预测+服务器校正”的权威移动方案。

4.1 重构移动逻辑：从客户端到服务器

我们需要将移动的核心计算逻辑搬到服务器上。

1. 修改PlayerMovement脚本：

   using Mirror; using UnityEngine; public class PlayerMovement : NetworkBehaviour { public float moveSpeed = 5f; private Vector3 _serverPosition; // 存储服务器发来的权威位置 void Update() { if (isLocalPlayer) { // 本地玩家：收集输入，发送给服务器 float h = Input.GetAxis("Horizontal"); float v = Input.GetAxis("Vertical"); Vector3 input = new Vector3(h, 0, v); if (input.magnitude > 0.1f) // 有有效输入才发送，减少网络流量 { CmdMove(input.normalized); // 将标准化后的方向发送给服务器 } // 客户端预测：根据输入和速度，在本地先移动（可选，为了流畅性） // transform.Translate(input * moveSpeed * Time.deltaTime); } // 所有客户端（包括本地）：根据服务器同步的位置进行插值，确保最终一致 // 这里简化处理，实际应该用插值平滑 if (isClient) { transform.position = Vector3.Lerp(transform.position, _serverPosition, Time.deltaTime * 10f); } } [Command] void CmdMove(Vector3 direction) { // 在服务器上执行移动计算 Vector3 movement = direction * moveSpeed * Time.deltaTime; transform.Translate(movement); // 服务器移动权威对象 // 将服务器计算后的新位置同步给所有客户端 RpcUpdatePosition(transform.position); } [ClientRpc] void RpcUpdatePosition(Vector3 newPosition) { // 所有客户端接收服务器发来的权威位置 _serverPosition = newPosition; // 注意：这里直接赋值，客户端预测的位置会被覆盖。更复杂的方案需要做调和。 } }

   核心变化：
   • 移除了本地直接移动的逻辑（注释掉了）。
   • 本地玩家的Update只负责收集输入，并通过CmdMove发送给服务器。
   • CmdMove在服务器上执行真正的移动计算，并调用RpcUpdatePosition将结果广播。
   • 所有客户端在RpcUpdatePosition中接收服务器的权威位置，并更新本地的_serverPosition。
   • 在客户端的Update中，将所有对象（包括本地玩家）的位置向_serverPosition插值，实现平滑同步。

4.2 使用NetworkTransform组件

上面的例子手动同步位置，是为了理解原理。在实际开发中，对于简单的刚体移动，Mirror提供了NetworkTransform组件来处理位置、旋转和缩放同步，它内置了插值和补偿算法，比自己手写要稳定和高效得多。

1. 添加NetworkTransform：给你的PlayerCube预制体添加NetworkTransform组件。
2. 简化脚本：我们可以大幅简化PlayerMovement脚本，只保留发送输入的部分，位置同步交给NetworkTransform。

   using Mirror; using UnityEngine; public class PlayerMovement : NetworkBehaviour { public float moveSpeed = 5f; void Update() { if (!isLocalPlayer) return; float h = Input.GetAxis("Horizontal"); float v = Input.GetAxis("Vertical"); Vector3 input = new Vector3(h, 0, v); if (input.magnitude > 0.1f) { CmdMove(input.normalized); } } [Command] void CmdMove(Vector3 direction) { // 服务器根据输入移动对象。 // NetworkTransform组件会检测到transform.position的变化，并自动同步给所有客户端。 Vector3 movement = direction * moveSpeed * Time.deltaTime; transform.Translate(movement); } }

   工作原理：NetworkTransform组件在服务器上会监控它所挂载的Transform的变化。当变化超过设定的阈值或达到同步间隔时，它会自动将变化压缩成网络消息发送给客户端。客户端收到后，会平滑地插值到目标位置。这比自己用RPC同步要省事和优化。

4.3 同步变量的高级用法：同步复杂状态

移动解决了，我们再来看看如何同步更复杂的游戏状态，比如玩家的装备、技能冷却等。[SyncVar]只能同步基本类型和Unity内置的一些类型（如Vector3, Quaternion）。对于自定义的类或结构体，我们需要用到[SyncVar]配合自定义序列化，或者使用SyncList、SyncDictionary等容器。

示例：同步玩家装备列表（使用SyncList）

using Mirror; using System.Collections.Generic; using UnityEngine; public class PlayerEquipment : NetworkBehaviour { // 定义一个可序列化的装备类 [System.Serializable] public struct Equipment { public string itemId; public int slotIndex; } // SyncList 会自动将列表内容的增删改操作同步到所有客户端 public readonly SyncList<Equipment> equippedItems = new SyncList<Equipment>(); public override void OnStartServer() { base.OnStartServer(); // 服务器初始化一些默认装备 equippedItems.Add(new Equipment { itemId = "sword_001", slotIndex = 0 }); equippedItems.Add(new Equipment { itemId = "shield_001", slotIndex = 1 }); } public override void OnStartClient() { base.OnStartClient(); // 订阅列表变化回调。当列表在客户端被更新（从服务器同步）时，会触发这个回调。 equippedItems.Callback += OnEquipmentChanged; // 初始加载后，手动触发一次更新UI RefreshEquipmentUI(); } void OnEquipmentChanged(SyncList<Equipment>.Operation op, int index, Equipment oldItem, Equipment newItem) { // 当装备列表发生变化时（添加、移除、替换、清空），更新UI Debug.Log($"Equipment changed: {op} at index {index}"); RefreshEquipmentUI(); } void RefreshEquipmentUI() { // 这里更新你的游戏内装备UI foreach (var equip in equippedItems) { Debug.Log($"Item: {equip.itemId} in slot {equip.slotIndex}"); } } [Command] public void CmdEquipItem(string itemId, int slot) { // 服务器验证并执行装备操作 if (IsValidItem(itemId) && IsSlotEmpty(slot)) { equippedItems.Add(new Equipment { itemId = itemId, slotIndex = slot }); } } bool IsValidItem(string itemId) { /* 验证逻辑 */ return true; } bool IsSlotEmpty(int slot) { /* 检查逻辑 */ return true; } }

关键点：

• SyncList<T>是一个线程安全的列表，其所有修改操作（Add, Remove, Insert等）都会自动从服务器同步到所有客户端。
• 通过订阅Callback事件，客户端可以在列表变化时立即做出反应，比如刷新UI。
• 所有修改列表的操作（如CmdEquipItem）都必须在服务器端进行，以确保权威性。

5. 网络对象生成与生命周期管理

在多人游戏中，玩家、怪物、子弹、道具等都需要动态地出现在网络中，并在适当的时候消失。Mirror提供了完整的网络对象生成与销毁机制。

5.1 动态生成网络对象

除了玩家预制体是自动生成的，其他对象都需要你手动调用NetworkServer.Spawn()来生成。

示例：生成一颗子弹

1. 创建子弹预制体：创建一个Sphere，添加NetworkIdentity组件。创建一个Bullet脚本（继承NetworkBehaviour），挂上。将其做成预制体BulletPrefab。
2. 注册预制体：在NetworkManager的Spawn Prefabs列表中添加BulletPrefab。
3. 在服务器上生成：

   public class PlayerShoot : NetworkBehaviour { public GameObject bulletPrefab; public Transform firePoint; void Update() { if (!isLocalPlayer) return; if (Input.GetButtonDown("Fire1")) { CmdFire(); } } [Command] void CmdFire() { // 在服务器上实例化子弹 GameObject bullet = Instantiate(bulletPrefab, firePoint.position, firePoint.rotation); // 为子弹设置初始速度等（在子弹自己的脚本里用[Server]或[ServerCallback]标记） // bullet.GetComponent<Rigidbody>().velocity = firePoint.forward * speed; // 关键：在网络上生成这个对象，所有客户端会自动创建对应的对象 NetworkServer.Spawn(bullet); // 设置子弹的所有者（可选，用于伤害计算等） // bullet.GetComponent<Bullet>().owner = connectionToClient; } }

   重要：NetworkServer.Spawn只能在服务器端调用。它会在所有已连接的客户端上自动实例化该预制体。

5.2 对象生命周期与清理

生成的对象也需要正确销毁，否则会造成内存泄漏和网络ID耗尽。

正确的销毁方式：

• 在服务器上销毁：调用NetworkServer.Destroy(gameObject)。这会通知所有客户端也销毁对应的对象。
• 不要在客户端直接Destroy：客户端没有权限销毁网络对象。如果你在客户端调用Destroy，只会销毁本地实例，服务器和其他客户端上的对象依然存在，会导致状态不一致。

示例：子弹命中后销毁

public class Bullet : NetworkBehaviour { public float lifetime = 5f; public float damage = 10f; void Start() { // 服务器上启动一个协程，5秒后自动销毁子弹（防止永远不消失） if (isServer) { StartCoroutine(DestroyAfterTime()); } } [System.Collections.IEnumerator] IEnumerator DestroyAfterTime() { yield return new WaitForSeconds(lifetime); NetworkServer.Destroy(gameObject); } [ServerCallback] // 这个特性表示此方法只在服务器运行，避免在客户端误调用 void OnTriggerEnter(Collider other) { if (other.CompareTag("Player")) { // 服务器处理伤害逻辑 other.GetComponent<PlayerHealth>().TakeDamage(damage); // 命中后立即销毁 NetworkServer.Destroy(gameObject); } } }

注意：[ServerCallback]特性非常有用，它用于标记那些由Unity事件（如OnTriggerEnter）触发，但逻辑只应在服务器执行的方法。它能防止这些方法在客户端被调用，是一种安全防护。

5.3 场景物体的网络化

除了动态生成的对象，场景中预先放置的静态物体（如门、开关、宝箱）也可能需要网络交互。对于这类物体，你需要：

1. 给场景中的物体添加NetworkIdentity。
2. 确保该物体的预制体已经注册在NetworkManager的Spawn Prefabs列表中（或者将其作为可注册的预制体）。
3. 为它编写NetworkBehaviour脚本，处理交互逻辑（如[Command]开门）。

Mirror在服务器启动时，会自动为场景中所有带有NetworkIdentity且未被动态生成的物体分配NetId，并管理它们的初始状态同步。

6. 实战避坑指南与性能优化

掌握了基础，我们来看看那些容易出问题的地方和提升效率的技巧。这些都是从实际项目里总结出来的血泪经验。

6.1 常见问题与排查

问题1：对象同步位置抖动或回弹

• 可能原因：网络延迟和插值设置不当。NetworkTransform的Interpolate选项如果设置过高，在延迟波动时会导致平滑过度而产生回弹感。
• 排查：检查NetworkTransform组件的Sync Interval（同步间隔）和Interpolate（插值）参数。对于快速移动的物体（如子弹），可以降低同步间隔，但会增加带宽。对于玩家角色，可以尝试调整插值速度或使用更高级的预测算法。
• 解决：对于玩家移动，考虑实现客户端预测和服务器调和。Mirror的NetworkTransform自带简单的预测，但对于复杂运动可能需要自己实现。一个实用的技巧是，在NetworkTransform上启用Client Authority（客户端权威）并配合[Command]进行服务器验证，但这需要仔细设计以防作弊。

问题2：Command或Rpc调用无效

• 可能原因A：方法命名不符合规范。[Command]方法名必须以Cmd开头，[ClientRpc]必须以Rpc开头。这是Mirror的硬性规定。
• 可能原因B：调用权限不足。[Command]只能由拥有该对象Authority的客户端调用。确保你是在本地玩家对象上调用CmdXXX，而不是在其他玩家对象上。
• 可能原因C：参数类型不被序列化支持。Mirror支持大部分基本类型和Unity常见类型，但对于复杂的自定义类或结构体，你需要为其实现自定义序列化（实现NetworkMessage接口或使用[System.Serializable]并确保所有字段都可序列化）。
• 排查：打开Mirror的日志级别（在NetworkManager或代码中设置LogLevel为Debug），观察控制台输出，看是否有相关的错误或警告信息。

问题3：连接失败或断开

• 可能原因A：端口被占用。默认端口是7777。
• 可能原因B：防火墙或路由器阻止了UDP/TCP流量。
• 可能原因C：客户端和服务器使用的Mirror版本不一致。务必确保所有连接端（服务器、所有客户端）的Mirror版本完全相同。
• 排查：服务器启动时查看控制台日志。客户端连接时查看错误信息。在NetworkManager中尝试更换端口。在本地测试时，可以暂时关闭防火墙。

6.2 性能优化要点

网络游戏的性能瓶颈往往在带宽和服务器计算。以下是一些Mirror项目的优化方向：

1. 减少同步频率与数据量

• 善用SyncVar的hook：只在值真正变化时触发同步和回调，避免每帧设置。
• 调整NetworkTransform参数：根据物体重要性调整Sync Interval。背景装饰物可以设置很低的同步频率（如0.5秒一次），而主要玩家角色可能需要0.1秒或更低。
• 压缩同步数据：对于位置、旋转等数据，可以考虑使用精度较低的压缩格式（如将Vector3的float分量乘以一个系数转换为short）。Mirror的NetworkTransform内部已经做了一些压缩。
• 状态同步而非每帧同步：对于动画状态（Idle, Run, Attack），使用[SyncVar]同步一个枚举状态，而不是每帧同步动画参数。

2. 使用Interest Management（兴趣管理）对于大型游戏场景，不需要把所有物体的状态同步给所有玩家。Mirror支持兴趣管理，即只同步玩家“感兴趣”区域内的物体。

• Distance Interest Management：基于距离的简单管理。在NetworkManager上添加DistanceInterestManagement组件，并设置相关距离。
• 自定义Interest Management：继承InterestManagement基类，实现OnCheckObserver等方法，可以定义更复杂的规则（如视野锥、队伍关系等）。这是构建大型地图MMO的必备技术。

3. 对象池化网络对象频繁生成和销毁网络对象（如子弹、特效）会产生GC（垃圾回收）压力和网络消息开销。实现一个网络对象池至关重要。

• 思路：服务器启动时，预先实例化一定数量的对象并禁用它们。需要生成时，从池中取出一个可用的对象，调用NetworkServer.Spawn（对于已生成过的对象，Mirror有内部处理），然后设置其位置状态并激活。需要销毁时，调用NetworkServer.UnSpawn（注意不是Destroy），然后将其放回池中并禁用。
• 注意：NetworkServer.UnSpawn会将对象从网络世界中移除（在所有客户端禁用），但不会销毁GameObject本身，非常适合池化。

4. 序列化优化自定义消息或复杂SyncVar的序列化方式会影响带宽。

• 避免在自定义消息或SyncVar结构体中包含大型数组或字符串。
• 对于频繁同步的数据，考虑使用BitPacking（位打包）来将多个布尔值或小范围整数压缩到一个整数字段中。

6.3 调试与监控

Mirror提供了一些内置的调试工具：

• NetworkManagerHUD：基础的GUI，用于快速启动/停止。
• NetworkStatistics：添加这个组件到NetworkManager对象上，可以在游戏运行时在GUI上显示实时的网络数据统计，如每秒发送/接收的字节数、消息数量等。这是定位网络性能问题的第一手工具。
• 日志：将NetworkManager中的Log Level设置为Debug或Verbose，可以在控制台看到详细的网络事件日志，对于排查连接、RPC调用问题非常有帮助。

最后，也是最重要的一点：始终在真实网络环境下测试。在编辑器内本地主机（Host）模式下运行一切正常，不代表在广域网（WAN）环境下没问题。尽早进行局域网甚至互联网测试，体验延迟、丢包带来的影响，并调整你的同步和预测算法。