企业官网建设流程全解析

1. 项目概述：为什么你的毕业设计需要一个好架构？

又到了一年一度的毕业设计选题季，对于计算机、数字媒体技术、软件工程甚至艺术设计相关专业的同学来说，Unity3D无疑是一个极具吸引力的选择。它上手快、资源多、效果炫酷，能做出看起来“很厉害”的东西。但每年我都看到大量同学，选题时雄心勃勃，中期答辩时焦头烂额，最终答辩时草草收场。核心问题往往不是创意不够，而是项目从一开始就“长歪了”——代码乱成一团麻，功能加不进去，Bug越改越多，最后只能硬着头皮交一个半成品。

这就是我们今天要聊的核心：从零构建一个可落地的入门级项目架构。这听起来有点“工程化”，似乎是大项目才需要考虑的。但恰恰相反，对于毕业设计这种周期短（通常3-6个月）、个人或小团队作战、且对完整性和可演示性要求极高的项目，一个清晰、稳固的底层架构，是你能否顺利毕业、甚至做出亮点的决定性因素。它不是为了炫技，而是为了让你能把有限的精力，集中在实现核心玩法和打磨表现效果上，而不是每天都在和莫名其妙的报错、无法复用的代码作斗争。

结合最近的热搜词来看，大家的关注点很分散：有想导入SolidWorks模型做机械仿真的，有想做UGUI动态照片墙的，有想接视频流做应用的，当然更多的是想做各种小游戏。无论你的具体方向是什么，底层架构的逻辑是相通的。一个好的架构，就像乐高积木的底板，无论你最后想拼城堡还是飞船，有了它，每一块积木（功能模块）都能稳稳地找到自己的位置，并且可以轻松地组合、替换和扩展。接下来，我们就一步步拆解，如何为你的毕业设计搭建这样一块“底板”。

2. 架构核心思想：面向数据与模块化设计

在动手写第一行代码之前，我们必须统一思想。对于Unity入门级项目，我不建议一开始就追求ECS（实体组件系统）或复杂的框架。我们的目标是：清晰、解耦、易扩展。两个最核心且实用的思想是：面向数据设计和模块化。

2.1 摒弃“万物皆MonoBehaviour”的思维定式

很多Unity新手的项目里，GameObject上挂满了脚本，脚本之间你找我、我找你，GetComponent满天飞，A脚本里直接public B b;然后在Inspector里拖拽赋值。这种“面向Inspector编程”在原型阶段很快，但一旦项目规模超过3个场景、10个功能，就会立刻变成灾难。数据散落在各处，修改一个数值需要翻好几个脚本；脚本间高度耦合，想替换一个功能牵一发而动全身。

面向数据设计，就是要把“数据”和“行为”分开思考。数据是什么？是玩家的血量、金币数、背包里的物品列表、游戏的配置参数（如移动速度、伤害值）。行为是什么？是处理输入、播放动画、更新UI显示、执行伤害计算。

我们的目标是：创建一个唯一、权威的数据中心。所有核心的游戏状态数据都存储在这里，其他模块（如UI、角色控制、存档系统）通过访问这个中心来读取或修改数据，而不是彼此直接通信。这样做的好处是：

1. 状态清晰：游戏运行到任何时刻，所有关键数据的状态一目了然。
2. 调试方便：数据异常时，只需检查数据中心，无需在几十个GameObject间跳转。
3. 易于持久化：存档时，只需要序列化这个数据中心即可。
4. 逻辑解耦：UI模块不需要知道角色控制器是否存在，它只关心“玩家当前血量”这个数据有没有变化。

2.2 模块化：像搭积木一样组织你的功能

模块化就是把不同的功能封装成独立的“积木块”。每个积木块（模块）职责单一，内部高内聚，对外通过定义好的接口（或事件）与其他模块通信，实现低耦合。

对于一个典型的毕业设计项目，我们可以初步规划出以下几个核心模块：

• 数据管理层：前面提到的数据中心，负责所有游戏数据的存储、验证和通知。
• UI管理层：管理所有界面（如开始菜单、HUD、背包、设置面板）的打开、关闭和刷新。
• 输入管理层：统一处理玩家输入（键盘、鼠标、手柄），并将其转化为抽象的游戏内指令（如“移动”、“跳跃”、“交互”）。
• 场景/关卡管理器：负责场景加载、卸载，以及关卡内逻辑的协调（如出生点、胜利条件判断）。
• 音频管理器：统一管理背景音乐和音效的播放、音量控制。
• 对象池管理器：对于需要频繁创建和销毁的对象（如子弹、特效、敌人），使用对象池重用，极大提升性能。

注意：不要一开始就试图实现所有模块。根据你的项目类型（如2D平台跳跃、3D探索解谜、UI交互应用）来识别最核心、最急需的2-3个模块优先实现。例如，一个动态照片墙项目，UI管理层和数据管理层就是绝对核心；而一个STG射击游戏，对象池管理器和输入管理层则至关重要。

3. 可落地架构蓝图：基于单例与事件总线的实践

理论说完了，我们来点实在的。下面我给出一个在多个毕业设计项目中得到验证的、轻量且强壮的架构蓝图。它主要基于两个核心模式：单例模式和事件总线模式。

3.1 核心架构模式解析

1. 单例模式（Singleton）：确保一个类只有一个实例，并提供一个全局访问点。对于管理器类（如GameManager、UIManager、AudioManager），单例模式非常合适，因为你通常只需要一个它们来控制全局。

• 为什么用它：避免重复创建，方便全局访问。比如，在任何脚本里，你都可以通过UIManager.Instance来打开一个面板，而无需费力地去查找这个对象。
• 注意事项：要小心处理单例的生命周期，尤其是在场景切换时。我们通常使用“惰性初始化”并在Awake或Start中确保唯一性，同时考虑使用DontDestroyOnLoad让核心管理器在场景切换时不销毁。

2. 事件总线模式（Event Bus）：这是一个发布-订阅模式的中央调度实现。模块之间不直接调用对方的方法，而是通过“事件”来通信。一个模块“发布”一个事件（如“玩家血量变化”），其他“订阅”了该事件的模块（如UI模块）就会自动收到通知并做出反应。

• 为什么用它：这是实现模块间解耦的“神器”。数据模块修改了血量，它只需要发布一个OnHealthChanged事件，并附带新的血量值。UI模块订阅了这个事件，收到后自动更新血条显示。两者完全不知道对方的存在，修改或替换其中任何一个，都不会影响另一个。
• 实操心得：自己实现一个简单的事件总线并不复杂，大约50行代码。这对于毕业设计完全足够，也能让你深刻理解其原理。不建议初学者直接导入复杂的第三方框架，增加学习成本。

3.2 目录结构规划：良好的开始是成功的一半

在Unity Project面板中，一个清晰的项目文件夹结构能极大提升开发效率。我推荐如下结构：

Assets/ ├── [YourProjectName]/ // 项目主文件夹，以你的项目名命名 │ ├── Art/ // 美术资源 │ │ ├── Materials/ │ │ ├── Models/ │ │ ├── Textures/ │ │ └── Sprites/ │ ├── Audio/ // 音频资源 │ │ ├── BGM/ │ │ └── SFX/ │ ├── Prefabs/ // 预制体 │ │ ├── UI/ │ │ ├── Characters/ │ │ └── Environment/ │ ├── Scripts/ // 脚本（核心） │ │ ├── Core/ // 核心架构脚本 │ │ │ ├── Managers/ // 各种管理器 │ │ │ │ ├── GameManager.cs │ │ │ │ ├── UIManager.cs │ │ │ │ └── EventManager.cs (事件总线) │ │ │ ├── Data/ // 数据相关 │ │ │ │ ├── GameData.cs (数据中心) │ │ │ │ └── SO_Settings.asset (ScriptableObject配置) │ │ │ └── Utilities/ // 工具类 │ │ │ └── Extensions.cs │ │ ├── Gameplay/ // 游戏逻辑脚本 │ │ │ ├── Character/ │ │ │ ├── Inventory/ │ │ │ └── ... │ │ └── UI/ // 纯UI逻辑脚本 │ │ ├── Panel_MainMenu.cs │ │ └── UI_HealthBar.cs │ ├── Scenes/ // 场景文件 │ │ ├── 0_Startup.unity // 启动场景（仅包含核心管理器） │ │ ├── 1_MainMenu.unity │ │ └── 2_Level01.unity │ └── Settings/ // 项目设置文件 │ └── InputSystem.inputactions // 新版输入系统配置 └── Plugins/ // 第三方插件

关键点解释：

• 0_Startup.unity场景：这是一个空场景，只包含一个GameManager预制体（它身上挂载了所有核心管理器脚本）。游戏从此场景启动，它负责初始化所有管理器，然后根据情况加载第一个真正的场景（如主菜单）。这保证了管理器的唯一性和持久性。
• Core/文件夹：这是你架构的“心脏”。里面的脚本是项目基石，一旦确定，在开发中后期很少改动。
• ScriptableObject：用于存储不绑定于特定场景的配置数据，如角色属性表、物品数据库、音效列表。它像是一个可编辑的资产文件，可以在Inspector中方便地配置，又能在运行时被脚本读取，是分离数据和逻辑的利器。

4. 核心模块实现详解与代码实战

有了蓝图，我们来用代码“浇筑”几个最关键的模块。我会提供最精简但完整的实现，你可以直接以此为起点进行扩展。

4.1 事件总线（EventManager）实现

这是解耦的核心。我们实现一个支持带参数事件的简单版本。

// EventManager.cs using System; using System.Collections.Generic; using UnityEngine; public class EventManager : MonoBehaviour { // 单例实例 public static EventManager Instance { get; private set; } // 使用字典存储事件类型和对应的回调列表 private Dictionary<string, Action<object>> eventDictionary; private void Awake() { if (Instance != null && Instance != this) { Destroy(gameObject); return; } Instance = this; eventDictionary = new Dictionary<string, Action<object>>(); DontDestroyOnLoad(gameObject); // 常驻，跨场景 } // 订阅事件 public void StartListening(string eventName, Action<object> listener) { if (eventDictionary.TryGetValue(eventName, out Action<object> thisEvent)) { thisEvent += listener; eventDictionary[eventName] = thisEvent; } else { thisEvent += listener; eventDictionary.Add(eventName, thisEvent); } } // 取消订阅 public void StopListening(string eventName, Action<object> listener) { if (eventDictionary.TryGetValue(eventName, out Action<object> thisEvent)) { thisEvent -= listener; eventDictionary[eventName] = thisEvent; } } // 触发事件 public void TriggerEvent(string eventName, object eventParam = null) { if (eventDictionary.TryGetValue(eventName, out Action<object> thisEvent)) { thisEvent?.Invoke(eventParam); } } }

使用示例：假设玩家血量变化。

1. 数据层发布事件（在修改血量的地方）：

   // 假设在PlayerData类中 public void TakeDamage(int damage) { CurrentHealth -= damage; // 发布事件，传递当前血量作为参数 EventManager.Instance.TriggerEvent("OnHealthChanged", CurrentHealth); }

2. UI层订阅事件（在血条UI脚本的Start或OnEnable中）：

   void Start() { EventManager.Instance.StartListening("OnHealthChanged", OnHealthChangedHandler); } void OnDisable() { EventManager.Instance.StopListening("OnHealthChanged", OnHealthChangedHandler); } private void OnHealthChangedHandler(object newHealth) { int health = (int)newHealth; // 更新血条UI的显示 healthBarImage.fillAmount = health / (float)maxHealth; }

这样，数据层和UI层就完全解耦了。

4.2 游戏数据中心（GameData）实现

使用C#的属性和字段来封装数据，并结合事件通知。

// GameData.cs using System; using UnityEngine; [System.Serializable] // 可序列化，便于存档 public class GameData { // 单例，方便全局访问 private static GameData _instance; public static GameData Instance { get { if (_instance == null) { _instance = new GameData(); _instance.Init(); // 初始化默认值 } return _instance; } } // 玩家数据 public int PlayerLevel { get; private set; } public int CurrentHealth { get; private set; } public int MaxHealth { get; private set; } public int Coins { get; private set; } // 初始化数据 private void Init() { PlayerLevel = 1; MaxHealth = 100; CurrentHealth = MaxHealth; Coins = 0; } // 修改数据的方法，内部触发事件 public void ModifyHealth(int delta) { int previousHealth = CurrentHealth; CurrentHealth = Mathf.Clamp(CurrentHealth + delta, 0, MaxHealth); // 数据变化时，除了通过事件总线，也可以直接在这里触发一些逻辑（可选） if (CurrentHealth != previousHealth) { EventManager.Instance?.TriggerEvent("OnHealthChanged", CurrentHealth); if (CurrentHealth <= 0) { EventManager.Instance?.TriggerEvent("OnPlayerDied", null); } } } public void AddCoins(int amount) { Coins += amount; EventManager.Instance?.TriggerEvent("OnCoinChanged", Coins); } // 存档和读档方法（简化版，实际需处理文件IO） public void Save() { /* 将this序列化到文件 */ } public void Load() { /* 从文件反序列化到_instance */ } }

要点：所有对核心数据的修改，都通过GameData提供的方法（如ModifyHealth）进行，而不是直接修改字段。这保证了数据修改的入口唯一，且能统一触发相关事件和逻辑。

4.3 UI管理器（UIManager）实现

负责管理UI面板的堆栈（用于处理返回逻辑）和显隐。

// UIManager.cs using System.Collections.Generic; using UnityEngine; public class UIManager : MonoBehaviour { public static UIManager Instance { get; private set; } // 当前打开的面板堆栈 private Stack<UIPanelBase> panelStack; // 所有面板的预制体引用字典（可通过Resources加载或Inspector拖拽） public Dictionary<string, GameObject> panelPrefabDict; [SerializeField] private Transform panelRoot; // UI面板的父节点 void Awake() { Instance = this; panelStack = new Stack<UIPanelBase>(); panelPrefabDict = new Dictionary<string, GameObject>(); // 初始化，例如从Resources文件夹加载所有Panel预制体 // InitPanels(); } // 打开一个面板 public void OpenPanel<T>(string panelName, object data = null) where T : UIPanelBase { // 如果面板已在栈顶，则不做处理 if (panelStack.Count > 0 && panelStack.Peek().PanelName == panelName) return; // 从字典获取或实例化面板 if (!panelPrefabDict.ContainsKey(panelName)) { Debug.LogError($"Panel {panelName} not found in dictionary!"); return; } GameObject go = Instantiate(panelPrefabDict[panelName], panelRoot); T panel = go.GetComponent<T>(); if (panel == null) { Debug.LogError($"Panel {panelName} doesn't have component {typeof(T).Name}!"); Destroy(go); return; } // 隐藏当前栈顶面板（可根据需求调整，比如不隐藏） if (panelStack.Count > 0) { panelStack.Peek().OnPause(); } // 新面板入栈并初始化 panelStack.Push(panel); panel.Init(data); panel.OnOpen(); } // 关闭当前面板（返回） public void CloseCurrentPanel() { if (panelStack.Count == 0) return; UIPanelBase topPanel = panelStack.Pop(); topPanel.OnClose(); Destroy(topPanel.gameObject); // 恢复下一个面板 if (panelStack.Count > 0) { panelStack.Peek().OnResume(); } } // 获取栈顶面板 public UIPanelBase GetTopPanel() { return panelStack.Count > 0 ? panelStack.Peek() : null; } } // 所有UI面板的基类 public abstract class UIPanelBase : MonoBehaviour { public abstract string PanelName { get; } public virtual void Init(object data) { } public virtual void OnOpen() { } public virtual void OnClose() { } public virtual void OnPause() { gameObject.SetActive(false); } // 默认隐藏 public virtual void OnResume() { gameObject.SetActive(true); } // 默认显示 }

使用方式：每个具体的UI面板（如Panel_MainMenu）继承自UIPanelBase，实现自己的逻辑。打开面板时调用UIManager.Instance.OpenPanel<Panel_MainMenu>("MainMenu")。

5. 针对不同选题的架构适配与实战要点

架构是通用的，但不同选题的侧重点不同。下面结合热搜词，给出具体建议。

5.1 针对“UGUI + DoTween动态照片墙”

• 架构重点：UI管理层和数据管理层是绝对核心。
• 数据层设计：创建一个PhotoWallData类，管理所有照片的信息（ID、路径、标题、描述、位置索引等）。使用List<PhotoInfo>存储。
• UI层设计：UIManager管理主界面、详情页等。每个照片元素是一个独立的UI预制体，挂载PhotoItem脚本，它响应点击事件，并通过事件总线发布"OnPhotoClicked"事件，传递照片ID。详情面板订阅此事件，根据ID从PhotoWallData中读取数据并显示。
• 动效集成：在PhotoItem的OnOpen或Init方法中，使用DoTween序列（Sequence）编写入场动画。将DoTween的调用封装好，确保在面板关闭或对象销毁时，通过OnDestroy方法调用DOTween.Kill()来避免内存泄漏和空引用错误。
• 实操心得：大量UI元素同时播放动画时，性能是关键。使用DoTween的SetUpdate(true)可以让动画不受Time.timeScale影响（适用于暂停菜单），但要注意。对于照片墙，更推荐使用Canvas Group控制透明度渐变和RectTransform的位移缩放，比直接改变Image的color和transform更高效。

5.2 针对“SolidWorks模型导入Unity3D”的机械仿真/展示

• 架构重点：场景/关卡管理器、数据管理层（存储模型状态、关节参数）、输入管理层。
• 模型处理：在SolidWorks中导出为FBX格式时，务必注意单位统一（建议在Unity中1单位=1米），并合理设置原点。导入Unity后，可能需要针对模型创建Prefab，并为其添加自定义脚本MechanicalPart，用于控制该部件的运动逻辑（如旋转、平移）。
• 数据驱动：将机械装置的运行参数（如电机转速、行程距离）定义在ScriptableObject资产中（如SO_MachineConfig）。GameData中存储当前运行状态。通过UI滑块或输入框修改GameData中的数据，触发事件。MechanicalPart脚本订阅这些事件，根据数据驱动模型运动。
• 交互控制：使用Unity的新输入系统（Input System）配置输入动作。InputManager将这些输入转化为“增加转速”、“反向运动”等抽象指令，并调用GameData的相应修改方法，从而驱动整个系统。这样，输入逻辑与具体的模型操作完全解耦。
• 踩坑提醒：导入的复杂装配体可能由多个子网格组成。确保在Unity中正确设置碰撞体（对于不需要物理碰撞的展示，可以用简单的Box Collider代替Mesh Collider以提升性能）。如果涉及运动学计算，注意在FixedUpdate中处理与物理相关的变换。

5.3 针对“Unity3D简单小游戏项目”（如2D平台跳跃、3D收集）

• 架构重点：对象池管理器（用于子弹、敌人、特效）、输入管理器、游戏状态管理（通过GameData管理分数、生命、关卡）。
• 对象池实现：这是性能优化的关键。实现一个通用的ObjectPool类，用于管理某种Prefab的实例队列。

  public class ObjectPool : MonoBehaviour { public GameObject prefab; public int initialSize = 10; private Queue<GameObject> pool = new Queue<GameObject>(); void Start() { for(int i=0; i<initialSize; i++) CreateNewObject(); } private GameObject CreateNewObject() { var obj = Instantiate(prefab, transform); obj.SetActive(false); obj.GetComponent<IPoolable>()?.OnPoolCreate(); // 可选接口 return obj; } public GameObject GetObject() { if(pool.Count == 0) CreateNewObject(); var obj = pool.Dequeue(); obj.SetActive(true); obj.GetComponent<IPoolable>()?.OnPoolGet(); return obj; } public void ReturnObject(GameObject obj) { obj.SetActive(false); pool.Enqueue(obj); obj.GetComponent<IPoolable>()?.OnPoolReturn(); } }

• 游戏流程控制：在GameManager中定义游戏状态枚举（如Menu, Playing, Paused, GameOver）。通过事件切换状态。其他模块（如UI、输入、生成器）根据当前状态决定自己的行为（例如，在Playing状态才接收游戏输入，在Paused状态暂停计时器和动画）。

6. 开发流程、版本控制与答辩准备

有了架构，如何高效地推进项目？

6.1 迭代开发流程建议

1. 第1-2周：奠基与原型：搭建上述核心架构（EventManager, GameData, UIManager）。同时，用最简陋的方块和图形，实现一个最核心的游戏循环（比如角色能移动、跳跃、碰到敌人失败）。这个阶段的目标是验证架构是否通畅，事件通信是否正常，而不是追求美术效果。
2. 第3-8周：功能迭代：每周定1-2个小目标（如“实现背包系统”、“完成第一个关卡的地图搭建”、“集成音频”）。遵循“数据驱动”原则，每添加一个新功能，先思考它涉及哪些数据（加到GameData），需要哪些事件（在EventManager中定义），最后才是UI和表现层。每完成一个功能，进行一次简单的集成测试。
3. 第9-12周：内容填充与抛光：导入美术资源、音效，调整数值平衡，打磨手感，制作过场动画和UI特效。此时，因为架构清晰，替换资源、调整参数会非常方便。
4. 第13-14周：测试与调试：全面测试，修复Bug。撰写设计文档和用户手册。准备答辩演示稿和视频录制。

6.2 必须使用的工具：版本控制（Git）

无论项目大小，必须使用Git。在项目第一天就初始化Git仓库（可以使用GitHub、Gitee或GitLab）。每天有意义的改动都进行提交（Commit），并写好清晰的提交信息。

• 分支策略：主分支（main）保持稳定。为每个新功能创建一个特性分支（feature/xxx），开发完成并测试后，合并回主分支。这能让你大胆尝试而不怕搞坏主项目。
• .gitignore：务必使用Unity官方的.gitignore文件，避免将Library、Temp等文件夹提交，这些文件巨大且在不同电脑上会重建。
• 实操心得：在Unity中，除了代码，Prefab、Scene、ScriptableObject等资源文件的合并冲突处理起来很麻烦。因此，团队协作或自己开发时，尽量通过沟通或规划，避免多人同时修改同一个场景或预制体。如果必须修改，可以考虑将大预制体拆分成更小的、职责单一的部分。

6.3 毕业设计答辩展示技巧

你的代码架构是“内功”，答辩时要通过“外功”展示出来。

1. 演示视频：录制一段3-5分钟的精剪视频。开头10秒展示最吸引人的游戏画面或功能，中间演示核心玩法、特色系统，最后展示完整的游戏流程（从开始到结束）。配上简洁的字幕和背景音乐。
2. 答辩PPT：
   • 不要花大量篇幅讲Unity基础、C#语法。重点讲你的设计和实现亮点。
   • 专门用一页PPT展示你的项目架构图（可以用简单的框图画出Manager、Data、Event之间的关系），并解释这样设计的好处（解耦、易扩展、易维护）。
   • 用对比法：可以贴一小段“糟糕代码”的例子（比如脚本间直接引用），再展示你如何使用事件总线解决了这个问题，并强调带来的好处。
   • 展示关键类的代码截图（如EventManager、GameData），但不要全屏贴代码，只圈出核心方法（如TriggerEvent,ModifyHealth）。
   • 展示游戏运行时的数据流动：可以画一个简单的时序图，说明“玩家点击按钮 -> 输入管理器 -> 修改GameData -> 触发事件 -> UI更新”这个过程。
3. 回答提问：老师常问“某个功能是怎么实现的？”、“如果让你加一个XX功能，怎么做？”。这时，清晰的架构就是你最好的回答。你可以说：“因为我的游戏数据是中心化管理的，要加一个新属性，我只需要在GameData里添加一个字段和对应的事件，然后在相关模块订阅这个事件即可，不会影响其他已有代码。” 这体现了你的工程化思维，绝对是加分项。

7. 常见问题排查与性能优化要点

在开发过程中，你一定会遇到下面这些问题。

7.1 架构相关典型问题

1. 事件监听导致的内存泄漏：这是最常见的问题。在MonoBehaviour脚本中订阅了事件，但在对象销毁（OnDestroy）时没有取消订阅。这样，事件总线会一直持有对该对象方法的引用，阻止其被垃圾回收。

   • 解决方案：严格遵守“谁订阅，谁取消”的原则。在OnEnable中订阅，在OnDisable中取消订阅。或者使用C#的弱事件模式，但入门项目自己实现的事件总线，牢记手动取消订阅即可。

   void OnEnable() { EventManager.Instance.StartListening("MyEvent", MyHandler); } void OnDisable() { EventManager.Instance.StopListening("MyEvent", MyHandler); }

2. 单例冲突或空引用：在场景中有多个单例对象，或者访问单例时它还未被初始化。

   • 解决方案：确保单例在Awake中正确赋值，并使用DontDestroyOnLoad。访问单例时，如果可能为null，使用空值检查（if(UIManager.Instance != null)）。更稳健的做法是，提供一个Initialize方法，在游戏启动场景中确保所有管理器按顺序初始化完毕。

3. ScriptableObject数据在运行时被意外修改：ScriptableObject是资产文件，在Play模式下修改其值，退出Play模式后修改会保留（除非勾选了不保存）。

   • 解决方案：对于需要运行时动态修改的配置，不要直接引用ScriptableObject实例。可以将其数据在运行时复制到普通的C#类或GameData中。或者，明确区分“设计期配置”和“运行期数据”。

7.2 入门级性能优化清单

毕业设计项目通常不需要极致优化，但避免明显卡顿是基本要求。

1. Draw Call优化：这是造成卡顿的首要元凶。对于2D项目，使用Sprite Atlas（精灵图集）将多个小图打包成一张大图。对于3D项目，尽可能合并使用相同材质的静态物体（Static Batching），或使用GPU Instancing绘制大量相同物体。
2. 物理性能：减少不必要的刚体和碰撞体。对于不会移动的环境，使用静态碰撞体。避免在每帧（Update）中频繁使用Raycast或OverlapSphere，可以考虑隔几帧检测一次。
3. 对象池：如前所述，对于子弹、特效、敌人等频繁生成销毁的对象，必须使用对象池。这是投入产出比最高的优化。
4. UI优化：UGUI的Canvas重建开销很大。避免频繁改变UI元素的属性（如位置、颜色、文本）。将动态变化的UI元素（如血条、分数）放在单独的Canvas下，与静态UI分离。使用Canvas Group控制一组UI的显隐，而不是分别设置SetActive。
5. 资源管理：及时卸载不用的资源（Resources.UnloadUnusedAssets）。对于从网络下载或动态加载的AssetBundle，在使用完毕后要记得卸载（AssetBundle.Unload(true)）。

记住，架构的价值在于让开发过程变得有序和可预测。它不能代替你的游戏创意和内容，但它能确保你的创意和内容，能够稳定、高效地被构建出来，而不是在代码的泥潭中半途而废。从第一个脚本开始，就尝试用更清晰的方式去组织你的代码，你会发现，完成一个毕业设计项目，并没有想象中那么困难。