企业官网建设流程全解析

简介：这是一份面向Unity3D开发者和模拟经营游戏爱好者的完整农场经营游戏源码包，基于Unity4.6.1与C#脚本开发。玩法覆盖从小型农场到大型农场的全成长路径，包含多种动物饲养、资源积累与市场交易等核心经营环节，并设计了熊闯入农场的随机事件，玩家通过连续点击将其捕获并贩卖，增添操作互动乐趣。压缩包共2000个文件，大小约160.18MB，其中包含807个C#脚本、217个预制体、122个动画控制器、121个动画片段以及大量PNG场景与UI贴图，项目目录结构清晰，可直接导入Unity运行和二次修改。目前已有4417人学习下载。通过学习这套源码，可以掌握模拟经营游戏的系统拆解、场景组织、动画控制、点击交互和随机事件触发等实战技巧，适合用于个人学习、毕业设计或独立游戏项目的基础框架。

1. Unity3D农场模拟经营：一个「种收养卖」闭环的完整工程

在编辑器里选中一个作物预制体，把生长时间从 20 改成 120，回到游戏界面，农田里的作物立刻按新数值生长，全程不用改一行代码——这是打开这个 Unity3D《farm business》农场模拟经营游戏源码后最先感觉到的部分。它不是一个只渲染了几块田的演示 Demo，而是把种植、浇水、收获、动物喂养、售卖、时间流转、存档读取这一整条经营链路都做成了可复用的系统模块。

这个项目比较适合两类人：一类是刚开始做 Unity3D 游戏、想要一份能跑通完整玩法循环的参考工程的人；另一类是打算做课设或练手作品，想在经营模拟题材里快速拥有一个可持续扩展的底子的开发者。它的价值不在画面表现，而在于状态机的设计、数据与表现分离的思路、以及一套不需要第三方插件就能完成的数据存档方案。接下来照着工程结构一层层拆开看。

2. 技术选型与工程结构：不依赖第三方插件的轻量架构

2.1 技术栈与选型理由

这个工程的技术栈非常收敛，运行起来的主路径上几乎看不到任何第三方插件的身影：Unity3D 自带的 UGUI 做界面层，C# 脚本负责所有游戏系统，ScriptableObject 充当数据配置的载体，JsonUtility 完成存档落地。这种选型的直接好处是导入工程以后不需要解决插件版本冲突，也不会遇到某些资源包因为许可证或平台限制而报错的问题。我一般会建议手里有这种工程的时候，先按住冲动不急着升级渲染管线或换 UI 框架，而是把它原本的这套轻量组合吃透。

游戏里涉及的交互不算复杂，核心无非是点击地块、选择种子、等待成熟、收获、卖给商店，所以 UGUI 的 Button、Text、Image 加上 ScrollRect 已经完全够用。ScriptableObject 在这类经营模拟游戏里简直是天然契合的数据容器——一种作物可以是一份独立的资产，成熟时长、出售价格、生长阶段图标全部配置在 Inspector 里，策划改数值不会误伤代码逻辑。

2.2 目录结构：Assets 下的功能分区

工程内部的资源组织是标准的 Unity 功能分区，没有出现所有脚本堆在一个大文件夹里的情况。打开 Assets 目录之后大概能看到如下结构：

Assets/ |-- Scenes/ // 游戏主场景、启动场景 |-- Scripts/ | |-- Core/ // 游戏入口、单例基类、管理器注册 | |-- Farming/ // 种植、土地、作物状态相关脚本 | |-- Animal/ // 动物数据、饲养、产出逻辑 | |-- Economy/ // 金币、商店、背包系统 | |-- Save/ // 存档实体类与读写器 | |-- UI/ // 面板控制器与事件监听 |-- Data/ // ScriptableObject 资产：作物配置、动物配置、商店价格表 |-- Prefabs/ // 作物预制体、动物预制体、UI 控件预制体 |-- Art/ // 图片、动画、字体等静态资源 |-- Plugins/ // （默认无第三方依赖）

这种分区方式让「改配置」和「改代码」天然隔离。Data 目录下存放的是各种 ScriptableObject 资产文件，它是设计数据和逻辑实现之间的桥梁；Prefabs 里是挂在场景中带表现组件的预制体。这样在设计上就形成了一条单向依赖：Prefab 引用 ScriptableObject，Script 读取 ScriptableObject，而 Script 不反向依赖任何具体预制体。

2.3 数据驱动：ScriptableObject 作为核心配置层

项目的很多逻辑都依赖数据配置与代码逻辑的分离。以作物为例，每种作物都有一个对应的 ScriptableObject 资产，里面定义生长阶段数量、各阶段时长、成熟后的售价。代码里只依赖一个统一的CropData类型，不用关心具体是哪种作物。

// CropData.cs using UnityEngine; [CreateAssetMenu(fileName = "NewCrop", menuName = "Farm/Crop Data")] public class CropData : ScriptableObject { [Header("基础信息")] public string cropName; public Sprite[] phaseSprites; // 每个生长阶段的图标 [Header("生长参数")] public int totalPhases = 4; // 一共几个生长阶段 public float phaseDuration = 20f; // 每个阶段持续秒数 [Header("经济参数")] public int buyPrice; // 种子价格 public int sellPrice; // 成熟后售出价格 }

这段定义是整个种植系统的数据基础。CreateAssetMenu让开发者可以在 Unity 编辑器里通过右键菜单直接创建新的作物资产，不用编写额外的编辑器脚本。phaseSprites是每个生长阶段的贴图序列，配合生长阶段索引既能驱动 Sprite 变化，也能为以后加生长动画留好接口。总阶段数和单阶段时长共同决定了作物从播下到可收获的绝对时间，这也让调整游戏节奏变得非常直观。

这里想强调一个参数设计层面的细节：把buyPrice和sellPrice拆在两个字段里而不是写死一个差价，是为了以后做商店价格波动、节日特卖或者商人系统预留空间。到时候只需要在购买流程里加一个价格系数运算，而不需要改动数据资产本身的结构。

3. 核心模块拆解：种植、动物、时间、存档四段关键代码

3.1 种植系统：从播种到收获的状态机

种植模块是这个工程里最值得读的部分。它没有把每棵作物做成一个复杂的个体，而是让地块（FarmSlot）承担状态管理，地块上的作物表现只是一个随状态切换的 Sprite。简化后的核心逻辑是这样的：

// FarmSlot.cs using UnityEngine; public class FarmSlot : MonoBehaviour { public enum SlotState { Empty, Planted, Growing, Mature, Wilted } [SerializeField] private SpriteRenderer cropSprite; [SerializeField] private CropData currentCrop; private SlotState state = SlotState.Empty; private int currentPhase = 0; private float phaseTimer = 0f; public bool CanPlant => state == SlotState.Empty; // 外部调用：在地块上种下指定作物 public void PlantCrop(CropData data) { if (!CanPlant) return; currentCrop = data; currentPhase = 0; phaseTimer = 0f; state = SlotState.Planted; UpdateVisual(); } // 由 TimeManager 每帧/每固定间隔驱动，而非自行累加时间 public void Tick(float delta) { if (state != SlotState.Planted && state != SlotState.Growing) return; phaseTimer += delta; if (phaseTimer >= currentCrop.phaseDuration) { phaseTimer = 0f; AdvancePhase(); } } private void AdvancePhase() { currentPhase++; if (currentPhase >= currentCrop.totalPhases) { state = SlotState.Mature; } else { state = SlotState.Growing; } UpdateVisual(); } private void UpdateVisual() { if (currentCrop == null) return; if (currentPhase < currentCrop.phaseSprites.Length) { cropSprite.sprite = currentCrop.phaseSprites[currentPhase]; } } }

FarmSlot的状态机用枚举划分了五个阶段，其中Planted和Growing的区分是为了以后能在种植初期做「不可被动物踩踏」或「浇水后跳过此阶段」之类的玩法留接口。Tick方法不从自身聚合 Time.deltaTime，而是等待外部统一驱动——这是整个工程时间系统设计的核心约定，后面讲 TimeManager 的时候还会提到。这样做的最大好处是：暂停游戏、倍速经营、跨天结算都由上层统一控制，地块不需要知道自己处于哪个时间上下文。

参数上，phaseTimer清零时机的选择要注意：它是在到达阈值时归零而不是在开始生长时记录目标时刻，这样可以避免用DateTime或较大数值做比较时产生精度问题。对于单阶段时长 20 秒级别的模拟游戏来说，这个精度绰绰有余。

3.2 动物系统：喂食、心情与产出的关联

动物模块在工程里是和种植并列的第二个资源产出途径。动物的设计比作物多了一层交互反馈：需要玩家主动喂食，喂食后动物在下一产出周期才能给出产物，心情值影响产出数量。核心代码大致如下：

// AnimalController.cs using UnityEngine; public class AnimalController : MonoBehaviour { [SerializeField] private AnimalData animalData; [SerializeField] private int mood = 80; // 心情值 0-100 [SerializeField] private int feedCount = 0; // 本周期已喂食次数 [SerializeField] private float produceTimer = 0f; public bool CanProduce => feedCount >= animalData.requiredFeed; public void Feed() { if (feedCount >= animalData.requiredFeed) return; feedCount++; mood = Mathf.Min(100, mood + animalData.moodGainPerFeed); // 播放吃食动画、显示飘字等表现由外部事件接管 } public void Tick(float delta) { if (!CanProduce) return; produceTimer += delta; if (produceTimer >= animalData.produceInterval) { produceTimer = 0f; Produce(); } } private void Produce() { int amount = Random.Range(animalData.minYield, animalData.maxYield + 1); if (mood > 70) amount++; // 心情好时额外 +1 产量 // 通过事件把产物发给 Inventory 系统 GameEvents.OnAnimalProduce?.Invoke(animalData.productId, amount); } }

这段逻辑里有一个值得注意的经济设计：requiredFeed和produceInterval是两个不同维度的约束条件。requiredFeed是每周期必须凑够的喂食次数，produceInterval是产出计时周期，两者共同作用才能让「喂食→等待→产出」形成可感知的操作节奏。如果只做计时，玩家就会放着不管；如果只做喂食次数，就成了纯点击器的套路。工程把两个条件叠在一起，玩家既要在时间窗口内喂食，又要等待产出计时，模拟经营的「操心感」就出来了。

mood参数对产出的影响在代码里是以固定阈值 70 判断的，实际运行时阈值也可以做成动物数据里的一个可配置字段，这样不同品种的动物对心情的敏感度就能差异化。我在自己做经营类项目时一般会更激进一点：把minYield和maxYield也做成心情的线性插值函数，产量随心情变化而不是跳变。

3.3 时间系统：驱动一切模拟的统一时钟

前面反复提到Tick(delta)是外部驱动的，这个外部就是TimeManager。它不是一个简单的累加器，而是整个模拟世界的心跳源。它对外暴露统一的 Tick 委托，所有需要随时间推进的系统只需注册这个委托，不需要各自持有计时逻辑：

// TimeManager.cs using UnityEngine; using System; public class TimeManager : MonoBehaviour { public static TimeManager Instance { get; private set; } public event Action<int> OnMinuteChanged; public event Action<int> OnDayChanged; [SerializeField] private int minute = 6 * 60; // 从早上 6:00 开始 [SerializeField] private int day = 1; [SerializeField] private float realSecondsPerGameMinute = 1f; private float timer = 0f; private void Awake() { Instance = this; } private void Update() { timer += Time.deltaTime; if (timer >= realSecondsPerGameMinute) { timer -= realSecondsPerGameMinute; AdvanceMinute(); } } private void AdvanceMinute() { minute++; OnMinuteChanged?.Invoke(minute); if (minute >= 24 * 60) { minute = 0; day++; OnDayChanged?.Invoke(day); } } }

这个实现把游戏时间和真实时间做了一次线性映射，realSecondsPerGameMinute = 1f意味着现实 1 秒走游戏内 1 分钟，那么现实 24 分钟就是游戏内一天。这个数值在调试阶段可以临时调成 0.2f 来快速验证跨天逻辑，调成 5f 则变成慢节奏休闲经营。它的巧妙之处在于所有下游系统只需要依赖OnMinuteChanged和OnDayChanged两个事件，自身完全不需要感知真实时间的流速。

这里有一个很容易踩的坑会在避坑章节展开：如果用Time.deltaTime直接驱动，那么游戏在后台切出去再回来时，Time.deltaTime会是一个很大的跳跃值，作物可能瞬间从种子长成大树。比较稳妥的做法是在OnApplicationFocus(false)的时候暂停模拟或者丢弃累积时间增量，工程里的结构已经为这种修复留好了位置。

3.4 存档系统：JsonUtility 结合中转列表的读写方案

存档是经营模拟游戏的后悔药所在。这个工程使用 JsonUtility 作为序列化方案，它能力有限——比如无法直接序列化Dictionary，也无法处理多态类型。因此工程的做法是定义一套纯数据结构的存档实体，再用中转列表解决字典类型的序列化问题。核心实现如下：

// SaveManager.cs using UnityEngine; using System.Collections.Generic; [System.Serializable] public class CropSaveData { public string slotId; // 地块唯一标识 public string cropId; // 作物 ID 或 ScriptableObject 名称 public int phase; public float phaseTimer; } [System.Serializable] public class InventorySaveData { public string itemId; public int amount; } [System.Serializable] public class GameSaveData { public int day; public int minute; public int coin; public List<CropSaveData> crops = new List<CropSaveData>(); public List<InventorySaveData> inventory = new List<InventorySaveData>(); } public class SaveManager : MonoBehaviour { private const string SaveKey = "farm_save_v1"; public void SaveGame() { GameSaveData data = new GameSaveData(); data.day = TimeManager.Instance.GetDay(); data.minute = TimeManager.Instance.GetMinute(); data.coin = EconomyManager.Instance.Coin; // 把字典结构展开成 List 再交给 JsonUtility foreach (KeyValuePair<string, CropSaveData> pair in FarmManager.Instance.GetAllCropSave()) { data.crops.Add(pair.Value); } string json = JsonUtility.ToJson(data); PlayerPrefs.SetString(SaveKey, json); PlayerPrefs.Save(); } public void LoadGame() { string json = PlayerPrefs.GetString(SaveKey, string.Empty); if (string.IsNullOrEmpty(json)) return; GameSaveData data = JsonUtility.FromJson<GameSaveData>(json); // 将 List 还原成字典并分发到各个管理器 } }

这套方案的序列化实体是完全独立于运行时对象的，好处是以后换存档格式（比如换成 JSON.NET 或 SQLite）时只需要动 SaveManager 和序列化实体类，不需要在 FarmSlot 里塞一堆存档字段。slotId作为字符串而非整数，是为了兼容将来地图扩展后的命名规则。cropId存储的是 ScriptableObject 资源的对象名而不是引用，因为直接序列化对象引用在不同平台和资源打包环境下极不稳定。

存档时机上，工程选择在关键节点触发自动保存，比如跨天瞬间、玩家主动打开暂停菜单时。手动存档的入口一般放在设置界面或者背包界面角落，避免玩家误触导致回档。

4. 场景与数据组织：预制体、UI、ScriptableObject 怎么串成一条线

4.1 场景层级：管理器的挂载与加载顺序

打开游戏主场景后，Hierarchy 窗口里可以看到一套非常典型的管理器挂载结构。根节点下一共挂了四个比较核心的物体：TimeManager（统一时钟）、EconomyManager（金币与订单经济）、FarmManager（农田地块容器）、UIManager（所有面板的挂载点和切换控制）。四个管理器在 Awake 里完成自身单例注册，在 Start 里按依赖顺序完成互相绑定。FarmManager 需要拿到 TimeManager 的 Tick 事件，因此它的 Init 方法必须在 TimeManager 之后执行。

这种结构的控制流是单向的：UIManager 只通过公开方法调用 EconomyManager 和 FarmManager 的方法，不直接访问具体地块；FarmManager 只做地块收集和转发事件；TimeManager 只负责发时间事件，不知道也没有必要知道谁在听它的声音。这样改动的容错性有很大提升，比如以后要加一个天气系统，只需要让天气管理器也监听同一个时钟事件，再在 UI 上增加一个表现层切图，不需要侵入种植逻辑。

4.2 UI 面板与事件绑定：从按钮点击到游戏行为

UIManager 管理着店铺面板、背包面板、主界面工具栏和设置面板。关键交互集中在三个地方：购买种子、选择种子种到地块、收获产物放入背包。工程里大量使用了 Unity 的 EventTrigger 与公开方法绑定，例如在种子商店的物品条目预制体上挂了一个ShopItemUI脚本，它把当前商品的数据引用保存在自己的字段里：

// ShopItemUI.cs 的核心片段 public Button buyButton; private CropData boundCrop; public void BindCrop(CropData data) { boundCrop = data; icon.sprite = data.phaseSprites[0]; priceText.text = data.buyPrice.ToString(); } public void OnBuyButtonClicked() { EconomyManager.Instance.TryPurchase(boundCrop); }

按钮的点击事件在 Inspector 的 OnClick 面板里直接绑定到了OnBuyButtonClicked方法，而不是在代码里动态注册。这样做的优点是团队成员可以在不打开脚本的情况下重新绑定 UI 事件；缺点则是重构时如果改了方法签名，所有引用事件都会失效并在 Inspector 里显示 Missing，避坑环节会说到这个现象。

背包面板的数据展示也走了类似路径：背包系统内部是一个以 itemId 为键、数量为值的字典，UI 层每次打开面板时请求一份快照列表并刷新格子，而不是维护一个常驻的 UI 数据副本。这样保证 UI 不会出现「逻辑上有一百个物品，界面只显示八十个」的脏数据情况。

4.3 预制体结构：表现与逻辑分离的复用单元

作物预制体的结构很轻，一个根节点挂FarmSlot脚本，下面有一个子物体持有SpriteRenderer，所有生长阶段的贴图都不放在预制体身上，而是从CropData里读取。这意味着同一套预制体可以种小麦、种萝卜、种南瓜，只需要在游戏运行时把不同的CropData资产传入即可。

这种设计带来一个操作上的改变：做新作物时，正确的流程是先创建一张作物数据资产，然后拖预制体到场景地块并指定数据资产，而不是复制一个新预制体出来改贴图。开发久了就会形成肌肉记忆——打开编辑器先确认数据文件，再考虑要不要动场景。动物预制体和商店条目都是同一思路：数据放进资源，表现留在场景。

Prefab 变体配合数据的组合方式在项目中期扩建的时候优势明显。比如新增一个需要浇水才会继续生长的作物，不需要新建一整棵预制体，只需要在原有作物预制体的基础上增加一个浇水状态图，再在数据资产里加一个needWater布尔字段，修改FarmSlot的AdvancePhase让它检查这个字段即可。

5. 跑起来与避坑：导入工程到稳定运行的实操记录

5.1 从打开 Unity Hub 到点击 Play

拿到工程压缩包后，第一件事不是急着解压双击，而是先打开 Unity Hub，在「项目」标签页里点击「添加」并将解压出来的文件夹直接选中。等待 Unity 编译脚本期间，留意控制台有没有红色报错。工程目标平台建议保持默认的 Windows/Mac 独立平台，在 PC 环境下直接跑最省事。

第一次进入场景时如果看到画面是纯色或相机没有对准农场，需要检查 Hierarchy 里的 Main Camera 是否启用了Clear Flags中的 Solid Color，并且把FarmManager节点下的地块根物体拉入视野。之后在 Game 视图设置 16:9 或 4:3 分辨比，点击 Play 就能开始游戏。

跑通一轮完整流程的建议做法：开局不急着买高级种子，先种三块基础作物，等第一波成熟后卖掉，积累一点金币再购买动物。通过这个流程把种植计时、收获入包、售卖扣钱、背包刷新四个节点全部验证一遍，确认数据流转没有断裂。

5.2 避坑记录：导入与运行阶段的现场还原

下面问题全部是实跑工程或改代码时最容易遇到的，按「现象 → 原因 → 解决」的顺序记录，每条都是实际开发中容易反复横跳的地方。

问题一：导入工程后 Console 报大量 API 兼容错误

现象：打开工程后编译阶段出现十余条以Obsolete或TypeLoadException开头的报错，场景里所有预制体组件丢失图标。

原因：本地 Unity 编辑器版本与工程原始版本之间存在 API 变动，尤其是输入系统或渲染管线相关的层。最典型的是工程原本用的是旧版输入管理器，而本地编辑器把 Active Input Handling 切成了新版 Input System。

解决：在 Edit → Project Settings → Player → Active Input Handling 里切换为Input Manager (Old)或Both，等待重新编译。其余过期 API 可以执行Edit → Project Settings → Editor → Auto-Referenced之外的API Updater自动升级，但升级前建议备份整个工程目录。

问题二：作物在后台切回后瞬间成熟

现象：游戏最小化一段时间后切回来，所有作物直接跳过中间状态进入成熟或枯死。

原因：TimeManager.Update使用Time.deltaTime累加，而游戏挂起期间 Unity 返回的单帧 delta 值远高于正常帧间隔，导致计时器一次性跨过多个生长阶段。

解决：在TimeManager中监听Application.focusChanged或OnApplicationPause，为 false 时记录暂停标志，恢复后的第一帧不累计时间。最小改动是给Update加一个条件判断：如果focus为 false 则跳过累加逻辑。

问题三：商店购买种子成功扣款但背包数量不增加

现象：点击购买按钮后货币数量正确减少，但打开背包面板货物列表仍为空。

原因：经济系统在扣款后调用背包系统的AddItem时传入了新的临时对象，而背包 UI 展示时依据 ID 匹配到的是ScriptableObject资源引用，两边 ID 不是同一个实例。背包内部字典认为这是两个不同物品，查询时就漏掉了。

解决：统一物品数据入口，购买或拾取后在背包里维护Dict<itemId, amount>，金额展示与逻辑匹配都要通过同一份ItemDatabase资产查表，不要直接引用商店面板传入的运行时对象。

问题四：存档写入成功但重新加载后部分地块数据为空

现象：Save 时是有数据的，退出重进后很多slotId命中的地块没有作物。

原因：JsonUtility序列化Dictionary时会直接失败或产生空对象，而工程内如果使用了字典存放cropSaveDict并且直接 ToJson，则输出 JSON 里会缺失字段。

解决：严格使用存档章节展示的「字典转 List」方案，自定义可序列化类承接字典的键值对，反序列化后再还原成字典分发给 FarmManager。这是 JSON.NET 之外最省事的原生方案，也是这个工程选择的路线。

问题五：改完脚本后预制体 Inspector 里出现「Missing Script」警告

现象：某个脚本改了类名或移动到别的命名空间，场景中的预制体组件仍然指向旧脚本，在 Inspector 里显示为红色缺失项。

原因：Unity 以 GUID 和文件相对路径识别脚本引用，类名改变不会自动更新场景引用。

解决：尽量避免改脚本类名；如果必须改，重新拖一次预制体组件并复制原参数，或者用文本编辑器全局搜索旧脚本 GUID 替换为新脚本 GUID。修改完以后务必打开所有场景检查一遍没有 Missing Script 残留再提交版本。

6. 二次开发落点：加作物、调经济、改存档的三个方向

这个工程给了不错的底子，但它更多像一张骨架，肉还得自己长。最容易上手的改造是从数据层切入：新建一个新作物资产，复制CropData资产后重新命名，在 Inspector 里替换phaseSprites的生长阶段贴图，把成熟时长设置为 60、售价调成 35，再把它加进商店的售卖列表即可。整个过程中不需要动一行 C# 代码，因为种植逻辑完全读取数据资产来驱动运行。如果想让新作物表现特殊，比如成熟后需要额外点击一次才能收获，则在FarmSlot的Mature状态里增加一个交互判定分支。

第二个方向是做经济系统上的调整，让「种什么赚钱」成为一个动态问题。目前的sellPrice是静态配置，可以给EconomyManager加一个每日价格波动模块：每天早上根据昨日销售数量生成一个价格系数，乘以基础价得到当日售价。这个改动只需要新增一个PriceFluctuationManager并监听TimeManager.OnDayChanged，在 UI 商店价格文本刷新时查询实时价格即可，不需要重构现有购买链路。

存档系统的改造我建议优先考虑从 PlayerPrefs 迁移到本地文件。原因很简单：随着动物数量、仓库物品数量增长，JSON 字符串会越写越长，PlayerPrefs 在 PC 上处理较长的字符串没有性能问题，但跨平台尤其是 Web 端时会有写入上限的隐患。可以保留现有GameSaveData结构，把SaveManager里的PlayerPrefs.SetString替换为File.WriteAllText，路径放在Application.persistentDataPath下。升级时记得做旧存档兼容，读不到新文件就回退到 PlayerPrefs，防止已有玩家进度丢失。

验证每一次改动有没有做坏原有玩法，我常用的办法是给项目定一条「一日冒烟脚本」：手动操作顺序固定为种地 → 快速调时间到第二天 → 喂食 → 收获 → 售卖 → 存档 → 重进。全程不写自动化测试，就是自己盯着控制台和 UI 数字过一遍。只要这条链路不断，核心体验就还稳着。很多次改完数据配置觉得自己逻辑天衣无缝，结果冒烟测试直接在收获环节翻车——后来养成了习惯，每次改完哪怕只是加一个图标，都会强制走一遍完整的游戏循环，确认不是只改了个「看起来能跑」的假模块。这些都是某次调式到半夜之后的血泪经验，希望帮到你。

本文还有配套的精品资源，点击获取