Unity开发进阶：从可视化编辑到面向对象编程的思维跃迁

1. 项目概述：从“搭积木”到“造世界”的思维跃迁

很多刚接触Unity的朋友，包括几年前的我自己，都容易陷入一个误区：把Unity当成一个高级的“可视化积木搭建工具”。我们兴奋地拖拽预制体，在Inspector面板里调整参数，看着场景视图里的小人儿动起来，就以为掌握了游戏开发。直到某一天，你想让角色在碰到特定颜色的地板时播放一段独特的音效，或者想动态生成一片随机的森林，你发现靠拖拽和勾选复选框已经力不从心了。这时，你才可能真正触及Unity游戏开发的本质——它是一场从“可视化编程”思维到“面向对象”与“数据驱动”思维的深刻顿悟。

这个所谓的“顿悟”，并不是什么玄乎的哲学概念，而是你开始用代码的视角，而不仅仅是编辑器的视角，去审视游戏中的一切。你不再只看到一个叫“Player”的GameObject，你看到的是一个承载了PlayerController脚本、Health组件、Inventory组件的容器。你的思维从“这个物体有什么属性”变成了“这个对象有哪些行为和数据，它们之间如何通信”。本指南的第二部分，就将聚焦于这次关键的思维转换。我们将彻底拆解Unity引擎运作的核心逻辑，让你理解场景中的每一个物体背后，是如何通过C#脚本这个“灵魂”被驱动和组织的。无论你是被“可视化编程”吸引而来的美术或策划同学，还是有一定编程基础但对Unity框架感到陌生的程序员，理解这部分内容，都将是你从“玩具制作”迈向“产品开发”的关键一步。

2. 可视化编程的“甜蜜陷阱”与本质局限

2.1 初识Unity：所见即所得的强大幻觉

Unity编辑器给人的第一印象无疑是强大且友好的。Hierarchy窗口里，你可以像整理文件夹一样组织游戏对象；Scene视图里，你可以直观地移动、旋转、缩放它们；Inspector窗口则展示了对象的所有“属性”，从位置、旋转到刚体质量、渲染材质，一应俱全。你可以通过简单地拖拽一个脚本到对象上，或者勾选一个Box Collider组件，就为对象添加了行为或物理特性。这种“所见即所得”（WYSIWYG）的工作流，极大地降低了入门门槛，也是Unity能吸引如此多非程序背景开发者的重要原因。

这种模式下，开发者的思维链条通常是线性的、基于属性的：“我需要一个会动的敌人” -> “拖入一个胶囊体模型” -> “添加NavMeshAgent组件” -> “在Inspector里设置它的移动速度”。整个过程快速、直观，对于实现原型和简单功能非常高效。很多官方教程和入门案例也强化了这种模式，让你感觉游戏开发就是一系列组件和参数的组合游戏。

2.2 “陷阱”浮现：当简单需求变得复杂

然而，这种模式的局限性会随着项目复杂度的提升迅速暴露。我们来设想几个非常实际的需求：

1. 动态交互：你有一个宝箱，希望玩家靠近时显示“按E打开”的提示，离开时提示消失。仅靠拖拽组件，你无法轻易实现“检测玩家进入某个区域”并“触发UI变化”的逻辑。
2. 数据管理：你有10种敌人，每种都有不同的生命值、攻击力和掉落物品。你当然可以为每种敌人创建一个预制体，然后手动在Inspector里填写这些数值。但当你想调整所有敌人的生命值缩放系数，或者新增一种掉落物时，你需要逐个打开10个预制体进行修改。
3. 状态与流程：你的角色有“空闲”、“行走”、“攻击”、“受伤”等状态。攻击状态不能直接切换到受伤状态，死亡后所有输入应该失效。这种复杂的状态逻辑和规则，很难通过勾选组件和设置参数来清晰定义和管理。

此时，你会发现Inspector面板里那些密密麻麻的输入框和下拉菜单，不再是一种便利，反而成了一种束缚。你无法用它们来表达“如果…那么…”的逻辑，无法方便地遍历和处理一组对象，更无法构建对象之间灵活的通信机制。这就是可视化编程的“天花板”：它擅长配置静态属性和连接预设好的模块，但拙于表达动态逻辑、复杂关系和程序流控制。

注意：这里并非贬低可视化工具的价值。Unity最新的Visual Scripting工具，以及PlayMaker等插件，正是为了提升逻辑表达的可视化能力。但它们本质上仍然是“编程”，只是将代码文本转换成了节点图。其核心思维——变量、函数、事件、流程控制——与面向对象编程是相通的。不理解底层原理，直接使用这些高级可视化工具，同样会举步维艰。

3. 面向对象思想：Unity世界的基石

当你意识到可视化配置的不足时，便是引入面向对象（Object-Oriented Programming, OOP）思想的最佳时机。在Unity的语境下，OOP并非一个遥远的计算机科学概念，而是理解引擎如何工作的自然视角。

3.1 GameObject与Component：组合优于继承的经典实践

Unity核心架构完美体现了OOP中“组合优于继承”的原则。这可能是你需要理解的第一个，也是最重要的顿悟点。

• GameObject（游戏对象）：它是一个空的容器，一个“壳”。在场景中看到的任何东西，一个角色、一盏灯、一个声音源，都是一个GameObject。它本身几乎没有功能，只有最基础的名称、激活状态和变换（位置、旋转、缩放）信息。
• Component（组件）：这才是功能的提供者。Transform组件提供变换信息，MeshRenderer组件负责渲染模型，Rigidbody组件赋予物理特性，而你自己编写的C#脚本，也是一种MonoBehaviour组件。

关键顿悟：一个GameObject拥有什么能力，完全取决于它附加了哪些Component。你想让一个物体可见且可碰撞？那就为它添加MeshRenderer和BoxCollider组件。你想让这个物体受重力影响？再添加一个Rigidbody组件。这种设计带来了无与伦比的灵活性：

• 你不需要一个“物理渲染角色”这样庞大的基类。
• 你可以像搭积木一样，通过组合不同的组件，快速创造出功能各异的对象。
• 功能复用性极高，Rigidbody组件既可以用在玩家角色上，也可以用在箱子、石头甚至子弹上。

你的C#脚本，作为MonoBehaviour的子类，就是一个自定义组件。当你把脚本拖到GameObject上，就等于赋予了这个对象一段由你定义的行为逻辑。

3.2 MonoBehaviour：你的脚本与引擎对话的契约

所有挂载到GameObject上并希望被Unity引擎管理的脚本，都必须继承自MonoBehaviour类。这个类定义了一系列生命周期方法，这是你需要理解的第二个关键点。

引擎会在特定的时间点自动调用这些方法，你不需要手动去调用Start或Update。你的工作就是在这些方法里“填空”，告诉引擎在这个时刻该做什么。

实操心得：理解这些方法的执行顺序至关重要。一个常见的错误是在Awake中试图获取另一个还未Awake的对象的组件，可能导致空引用。安全的做法是：在Awake中初始化自身数据，在Start中处理涉及其他对象的逻辑。对于组件引用，优先在Awake中通过GetComponent获取并缓存，避免在每次Update中都去查找，这是性能优化的基础。

3.3 核心OOP概念在Unity中的映射

面向对象的三大支柱——封装、继承、多态，在Unity开发中无处不在。

1. 封装：你的脚本类将数据（字段）和行为（方法）捆绑在一起。例如，一个Enemy类封装了health（字段）和TakeDamage()（方法）。你通过Inspector面板或代码设置health，通过调用TakeDamage()来影响它。将字段设为public会暴露在Inspector中，但这破坏了封装性。更好的做法是使用[SerializeField] private float health;，这样既能在Inspector中编辑，又在代码层面保持了私有性。

2. 继承：MonoBehaviour是所有脚本的基类。你可以创建更具体的基类，如BaseEnemy，包含所有敌人的通用逻辑（死亡、寻路），然后让GoblinEnemy和DragonEnemy继承它，并实现各自特有的攻击方式。这避免了代码重复。

3. 多态：假设BaseEnemy有一个虚方法virtual void Attack()，GoblinEnemy和DragonEnemy分别重写（override）了它。当你持有一个BaseEnemy类型的引用，调用Attack()时，它会根据实际指向的对象类型执行不同的攻击逻辑。这在管理敌人数组或列表时极其有用。

// 一个简单的封装与继承示例 public class BaseEnemy : MonoBehaviour { [SerializeField] protected float health; // 受保护字段，子类可访问 public void TakeDamage(float damage) { health -= damage; if (health <= 0) Die(); } protected virtual void Die() // 受保护的虚方法 { Debug.Log("Enemy died."); Destroy(gameObject); } public virtual void Attack() { } // 可被重写的攻击方法 } public class GoblinEnemy : BaseEnemy { public override void Attack() { Debug.Log("Goblin swings a club!"); // 实现哥布林具体的攻击逻辑 } protected override void Die() { Debug.Log("Goblin lets out a groan and falls."); // 哥布林特有的死亡效果，如播放声音、生成小型掉落 base.Die(); // 可选：调用基类的Die方法执行通用销毁逻辑 } }

4. 从可视化到代码：核心工作流解析

理解了OOP思想后，我们来看看在Unity中，如何将可视化的编辑与面向对象的代码无缝结合。

4.1 Inspector与脚本的桥梁：序列化字段

这是连接可视化编辑和逻辑代码的生命线。当你将一个public字段或带有[SerializeField]属性的private字段声明在脚本中时，Unity会自动将其显示在Inspector面板中。

public class Weapon : MonoBehaviour { // 公开字段，Inspector可见，其他脚本也可直接访问（需谨慎） public int damage = 10; // 序列化私有字段，Inspector可见，但代码外部无法直接访问，推荐方式 [SerializeField] private float attackRange = 2.0f; // 非序列化私有字段，Inspector不可见，纯内部逻辑使用 private bool isReady = true; // 还可以序列化属性（需要自定义Drawer，进阶用法） [SerializeField] private Sprite weaponIcon; }

为什么这如此重要？它允许设计师、策划甚至你自己，在不修改代码的情况下，调整游戏参数。你可以为同一个Enemy预制体创建多个实例，在Inspector中为它们设置不同的血量、速度、掉落物，而无需编写任何额外的代码。这实现了数据与逻辑的分离，是专业工作流的基础。

4.2 预制体（Prefab）：面向对象的实例化工厂

预制体是Unity中“面向对象”概念的实体化体现。你可以将一个配置好的GameObject（包含其所有组件和子对象）保存为一个.prefab文件，这个文件就是一个蓝图或类。

• 实例化（Instantiate）：在运行时，通过代码Instantiate(enemyPrefab, spawnPosition, Quaternion.identity)，你可以根据这个蓝图创建出无数个完全相同的副本（实例）。这就像用new关键字创建一个类的对象。
• 修改与继承：你可以创建预制体变体（Prefab Variant），它继承自基础预制体，并允许你覆盖或添加组件。这对应了OOP中的继承关系。
• 运行时修改：修改一个实例的属性（如血量），不会影响预制体蓝图。但如果你修改了实例后，通过PrefabUtility.ApplyOverrides将修改应用回预制体，则会更新蓝图。这需要谨慎操作。

常见问题与排查：

• 问题：实例化后的对象没有出现在预期位置，或者组件状态不对。
• 排查：
  1. 检查实例化时传入的位置和旋转参数是否正确。
  2. 确认预制体本身在Prefab编辑模式下的初始状态是否正确。
  3. 检查是否有Awake或Start中的代码重置了某些状态。
  4. 使用Debug.DrawRay或创建临时可视化对象来辅助调试生成点。

4.3 组件间通信：打破GameObject的孤岛

GameObject之间不是孤立的，它们需要交互。Unity提供了几种核心的通信方式，理解它们的适用场景是进阶的关键。

1. 直接引用（最直接，耦合度最高）：

   • 方式：在Inspector中拖拽赋值，或通过GetComponent、Find系列方法在代码中获取。
   • 示例：PlayerController需要引用CameraFollow脚本。直接在PlayerController的public CameraFollow cam;字段上，将摄像机对象拖拽赋值。
   • 优缺点：简单直观，但会创建强耦合。如果CameraFollow脚本被移除或改名，引用会断裂，导致空引用错误。

2. 消息发送（SendMessage/BroadcastMessage，较旧方式）：

   • 方式：gameObject.SendMessage(“TakeDamage”, 10);会调用该GameObject上所有脚本中名为TakeDamage的方法。
   • 优缺点：无需持有引用，字符串调用灵活性高但易拼写错误，且性能较差。不推荐在新项目中作为主要通信手段。

3. 事件系统（UnityEvent与C# Event，推荐）：

   • 方式：这是一种观察者模式。事件发送者定义事件（public UnityEvent OnPlayerDied;），接收者在Inspector中拖拽关联自己的方法，或在代码中订阅（OnPlayerDied.AddListener(MyMethod)）。
   • 示例：一个GameManager定义了OnGameStart事件。UI管理器、音频管理器、敌人生成器都可以监听这个事件，并在游戏开始时执行各自的初始化，而GameManager不需要知道它们的具体存在。
   • 优缺点：解耦程度高，Inspector中配置直观，是连接可视化与代码的利器。C#原生事件性能更好，但无法在Inspector中配置。

4. 脚本化对象（ScriptableObject）与全局管理器（进阶解耦）：

   • ScriptableObject：一种不依赖于GameObject实例的数据容器。可以用来创建共享的配置数据（如游戏设置、武器属性表）。
   • 全局管理器：通过静态类或单例模式（需谨慎使用）提供全局访问点。例如AudioManager.Instance.PlaySound(clip);。
   • 优缺点：能极大解耦系统，但滥用单例会导致代码难以测试和维护。ScriptableObject是管理共享数据的绝佳工具。

实操心得：对于紧密关联的对象（如角色和其手中的武器），使用直接引用或UnityEvent。对于模块间通信（如游戏状态变化通知多个系统），优先考虑事件系统或基于接口的通信。尽量避免使用Find和SendMessage，它们性能开销大且不可靠。

5. 顿悟后的实践：构建一个简单的敌人AI系统

让我们用一个综合例子，将上述所有概念串联起来。我们将创建一个有状态的敌人，它会在巡逻、追击、攻击之间切换，并且其属性可通过Inspector灵活配置。

5.1 系统设计与类结构

首先，我们进行面向对象的设计：

• EnemyData：一个ScriptableObject，存储敌人的基础属性（移动速度、视野范围、攻击力等）。这样我们可以轻松创建“初级哥布林”、“精英哥布林”等不同数据资产。
• EnemyState：一个枚举，定义敌人的状态（Idle, Patrol, Chase, Attack）。
• EnemyController：核心的MonoBehaviour脚本，管理状态机、移动和攻击逻辑。
• FieldOfView：一个可复用的组件，用于处理敌人的视野检测，可以被其他AI使用。

5.2 核心代码实现与解析

1. EnemyData (ScriptableObject)

[CreateAssetMenu(fileName = "NewEnemyData", menuName = "Game/Enemy Data")] public class EnemyData : ScriptableObject { public float moveSpeed = 3.5f; public float chaseSpeed = 5f; public float patrolRange = 10f; public float attackRange = 2f; public float fieldOfViewAngle = 90f; public float fieldOfViewDistance = 15f; public int maxHealth = 100; public int attackDamage = 10; }

2. EnemyController (核心逻辑)

public class EnemyController : MonoBehaviour { [SerializeField] private EnemyData enemyData; // 从Inspector拖入数据资产 [SerializeField] private Transform player; // 拖入玩家Transform private EnemyState currentState; private Vector3 patrolCenter; private float currentHealth; // 引用其他组件 private FieldOfView fov; private UnityEngine.AI.NavMeshAgent agent; void Awake() { agent = GetComponent<UnityEngine.AI.NavMeshAgent>(); fov = GetComponent<FieldOfView>(); patrolCenter = transform.position; // 记录初始位置为巡逻中心 currentHealth = enemyData.maxHealth; } void Start() { TransitionToState(EnemyState.Patrol); } void Update() { switch (currentState) { case EnemyState.Patrol: UpdatePatrolState(); break; case EnemyState.Chase: UpdateChaseState(); break; case EnemyState.Attack: UpdateAttackState(); break; } CheckForStateTransitions(); } private void UpdatePatrolState() { // 简单实现：随机在巡逻范围内移动 if (agent.remainingDistance < 0.5f) { Vector3 randomPoint = patrolCenter + Random.insideUnitSphere * enemyData.patrolRange; UnityEngine.AI.NavMeshHit hit; if (UnityEngine.AI.NavMesh.SamplePosition(randomPoint, out hit, enemyData.patrolRange, UnityEngine.AI.NavMesh.AllAreas)) { agent.SetDestination(hit.position); } } agent.speed = enemyData.moveSpeed; } private void UpdateChaseState() { if (player != null) { agent.SetDestination(player.position); agent.speed = enemyData.chaseSpeed; } } private void UpdateAttackState() { // 停止移动，面向玩家，执行攻击动画或逻辑 agent.isStopped = true; if (player != null) { Vector3 direction = (player.position - transform.position).normalized; direction.y = 0; transform.rotation = Quaternion.Slerp(transform.rotation, Quaternion.LookRotation(direction), Time.deltaTime * 10f); } // 这里可以触发攻击动画或计时器 } private void CheckForStateTransitions() { bool canSeePlayer = fov != null && fov.IsTargetInSight(player); float distToPlayer = player != null ? Vector3.Distance(transform.position, player.position) : Mathf.Infinity; switch (currentState) { case EnemyState.Patrol: if (canSeePlayer) TransitionToState(EnemyState.Chase); break; case EnemyState.Chase: if (!canSeePlayer) TransitionToState(EnemyState.Patrol); else if (distToPlayer <= enemyData.attackRange) TransitionToState(EnemyState.Attack); break; case EnemyState.Attack: if (distToPlayer > enemyData.attackRange) TransitionToState(EnemyState.Chase); break; } } private void TransitionToState(EnemyState newState) { // 退出旧状态 switch (currentState) { case EnemyState.Attack: agent.isStopped = false; break; } // 进入新状态 switch (newState) { case EnemyState.Patrol: Debug.Log(gameObject.name + " entering Patrol state."); break; case EnemyState.Chase: Debug.Log(gameObject.name + " entering Chase state."); break; case EnemyState.Attack: Debug.Log(gameObject.name + " entering Attack state."); break; } currentState = newState; } // 外部调用，例如被玩家攻击时 public void TakeDamage(int damage) { currentHealth -= damage; if (currentHealth <= 0) Die(); // 受到伤害可能触发追击 if (currentState == EnemyState.Patrol && player != null) { TransitionToState(EnemyState.Chase); } } private void Die() { // 播放死亡动画、音效，生成掉落物，销毁对象等 Debug.Log(gameObject.name + " died."); Destroy(gameObject); } } public enum EnemyState { Idle, Patrol, Chase, Attack }

3. FieldOfView (辅助组件)

public class FieldOfView : MonoBehaviour { [SerializeField] private float viewAngle; [SerializeField] private float viewDistance; [SerializeField] private LayerMask targetMask; [SerializeField] private LayerMask obstacleMask; public bool IsTargetInSight(Transform target) { if (target == null) return false; Vector3 dirToTarget = (target.position - transform.position).normalized; float dstToTarget = Vector3.Distance(transform.position, target.position); // 距离检查 if (dstToTarget > viewDistance) return false; // 角度检查 if (Vector3.Angle(transform.forward, dirToTarget) > viewAngle / 2) return false; // 障碍物检查（视线遮挡） if (Physics.Raycast(transform.position, dirToTarget, dstToTarget, obstacleMask)) { return false; } return true; } // 可选：在Scene视图中绘制视野Gizmo，便于调试 void OnDrawGizmosSelected() { Gizmos.color = Color.yellow; Gizmos.DrawWireSphere(transform.position, viewDistance); Vector3 viewAngleA = DirFromAngle(-viewAngle / 2, false); Vector3 viewAngleB = DirFromAngle(viewAngle / 2, false); Gizmos.DrawLine(transform.position, transform.position + viewAngleA * viewDistance); Gizmos.DrawLine(transform.position, transform.position + viewAngleB * viewDistance); } Vector3 DirFromAngle(float angleInDegrees, bool angleIsGlobal) { if (!angleIsGlobal) angleInDegrees += transform.eulerAngles.y; return new Vector3(Mathf.Sin(angleInDegrees * Mathf.Deg2Rad), 0, Mathf.Cos(angleInDegrees * Mathf.Deg2Rad)); } }

5.3 在编辑器中组装与配置

1. 创建EnemyData资产：在Project窗口右键 -> Create -> Game -> Enemy Data，命名为GoblinData。调整各项参数，如将moveSpeed设为3，chaseSpeed设为6。
2. 创建敌人预制体：
   • 在场景中创建一个胶囊体（Capsule），命名为Enemy。
   • 添加NavMeshAgent组件（用于寻路）。
   • 添加FieldOfView组件，设置viewAngle为90，viewDistance为15，targetMask为Player所在的层，obstacleMask为环境障碍物所在的层（如Default）。
   • 添加EnemyController脚本。
   • 将创建好的GoblinData资产拖到EnemyController的Enemy Data字段。
   • 将场景中的玩家对象（如Player）拖到Player字段。
   • 将该GameObject从Hierarchy拖到Project窗口，创建为预制体（如GoblinPrefab）。
3. 烘焙导航网格（NavMesh）：在Window -> AI -> Navigation 打开窗口，在Bake页签下点击Bake，为场景生成可行走区域。
4. 将GoblinPrefab拖入场景，运行游戏。敌人会开始巡逻，当玩家进入其视野范围后，它会开始追击，进入攻击范围后停止并转向玩家。

6. 思维转换后的进阶方向与避坑指南

当你开始习惯用面向对象的思维设计系统后，你会发现Unity的能力边界被大大拓宽了。以下是一些可以继续探索的进阶方向，以及我踩过的一些坑。

6.1 架构设计模式在Unity中的应用

• 组件模式（Component Pattern）：Unity本身就在用。你可以进一步深化，将功能极度单一化。例如，将攻击拆分为AttackInput（输入）、AttackAnimation（动画）、AttackDamage（伤害计算）等多个组件，通过事件或共享数据（如一个AttackContextScriptableObject）通信，使得组合更加灵活。
• 状态模式（State Pattern）：我们上面的敌人AI就是一个简单的状态机。对于更复杂的状态（如玩家角色包含移动、跳跃、攻击、技能等多个状态），可以抽象出IState接口和StateMachine类，让每个状态成为一个独立的类，管理自己的进入、更新、退出逻辑，使代码更清晰。
• 观察者模式（Observer Pattern）：UnityEvent和C# event就是其实现。广泛用于解耦系统，如成就系统监听各种游戏事件（杀死敌人、收集物品），而发出事件的系统完全不需要知道成就系统的存在。
• 单例模式（Singleton Pattern）：谨慎使用。适用于真正的全局管理器（如AudioManager、GameManager）。但要避免滥用，否则会导致代码高度耦合、难以测试。可以考虑使用服务定位器（Service Locator）或依赖注入（Dependency Injection）框架作为替代。

6.2 性能优化意识从第一天开始

面向对象设计得好，也要跑得流畅。一些早期就该养成的习惯：

• 避免在Update中做昂贵操作：如Find、GetComponent、Instantiate/Destroy。在Awake或Start中缓存引用，使用对象池管理频繁创建销毁的对象。
• 理解物理更新（FixedUpdate）与逻辑更新（Update）：所有与Rigidbody直接相关的操作（如AddForce）都应放在FixedUpdate中，否则会因为帧率波动导致物理模拟不稳定。
• 善用Profiler：Window -> Analysis -> Profiler。这是你查找性能瓶颈（CPU/GPU/内存）的最强工具。养成定期查看的习惯。
• Draw Call与合批：过多的材质和网格会增加Draw Call。尽量共享材质，使用精灵图集（Sprite Atlas），对于静态物体勾选Static标志以允许静态合批。

6.3 常见“新秀墙”问题排查

1. 空引用异常（NullReferenceException）：这是Unity新手最常见的错误。

   • 原因：试图访问一个未初始化或已被销毁的对象的成员。
   • 排查：
     • 检查Inspector中所有需要拖拽赋值的公共字段是否都已正确赋值。
     • 检查GetComponent是否在对象确实拥有该组件时调用（可在Awake中用Debug.Log打印检查）。
     • 检查在访问对象前，它是否已经被Destroy（例如，在下一帧访问上一帧已销毁的对象）。
     • 使用?.（空条件运算符）安全地访问可能为空的成员，如target?.transform.position。

2. 脚本生命周期导致的顺序问题：

   • 现象：A脚本在Start中需要B脚本初始化好的数据，但B脚本的Awake可能比A的Start晚执行。
   • 解决：Unity不保证脚本间的Awake/Start顺序。对于有依赖关系的初始化，有两种方法：
     • 延迟初始化：在Update的第一帧进行，并用一个bool isInitialized标志位防止重复初始化。
     • 手动控制顺序：在Project Settings -> Script Execution Order中设置脚本的执行顺序（谨慎使用，容易导致依赖混乱）。

3. 预制体修改未保存：

   • 现象：在场景中修改了预制体实例的属性，但退出运行后修改丢失了。
   • 解决：修改实例后，如果想保存到预制体，需要点击Inspector顶部预制体名称右边的Overrides下拉菜单，选择Apply All。反之，如果想将实例恢复成预制体的样子，选择Revert All。

从依赖可视化编辑器到驾驭面向对象的思想，这个转变会让你真正成为Unity游戏的“创造者”而非“组装工”。你会开始思考如何设计健壮的数据结构、如何构建可复用的系统模块、如何管理复杂的对象生命周期。这个过程充满挑战，但每一次解决一个设计难题，或优雅地实现一个功能，所带来的成就感，远非拖拽几个组件可比。记住，编辑器是你的画布，而C#脚本和面向对象的思想，才是你手中的画笔和颜料。