1. 项目概述为什么Unity序列化值得你花时间研究如果你在Unity里做过稍微复杂点的项目比如一个带存档功能的RPG或者一个需要动态配置关卡数据的编辑器工具那你大概率已经和序列化打过交道了。你可能只是简单地给一个字段加上[SerializeField]属性让它能在Inspector面板里显示和编辑然后就没再深究。但就是这个看似简单的机制背后却支撑着Unity编辑器的整个工作流、预制体Prefab系统、场景Scene的保存与加载甚至是资源Asset的导入与引用管理。可以说不理解序列化你就很难真正驾驭Unity引擎尤其是在处理性能优化、数据持久化、编辑器扩展或者跨版本兼容性这些棘手问题时会感到处处掣肘。我刚开始接触Unity时也踩过不少序列化的“坑”。比如辛辛苦苦写了一个自定义的类里面放了一堆数据结果保存场景后重新打开数据全丢了又比如想通过脚本动态修改预制体某个实例的属性却发现修改“不生效”或者影响了所有实例再比如项目资源一多序列化数据膨胀导致场景加载慢得像蜗牛。这些问题归根结底都是对Unity序列化机制理解不透彻造成的。所以这次我们不谈那些浮于表面的API调用而是真正“深入”进去。我会结合自己这些年踩过的坑和积累的经验从Unity序列化的核心设计思想讲起拆解它的工作流程、不同序列化器的特点、性能瓶颈所在以及如何在实际项目中高效、安全地使用它。无论你是想优化项目性能还是打算开发复杂的编辑器工具或者仅仅是希望自己的代码行为更可预测这篇文章都会给你带来实实在在的帮助。2. Unity序列化的核心机制与设计哲学2.1 序列化是什么Unity为何如此依赖它在计算机科学中序列化Serialization通常指将对象的状态信息转换为可以存储或传输的形式如字节流、JSON、XML的过程。反序列化Deserialization则是其逆过程。在Unity的语境下序列化的含义要更具体也更关键。Unity的序列化系统首要目标是为了驱动编辑器。当你把一个脚本组件拖到GameObject上并在Inspector里调整它的公共字段时你并没有直接修改运行时的内存对象。你修改的是该组件序列化后的数据。这些数据与场景文件.unity或预制体文件.prefab存储在一起。当你点击运行Play按钮Unity会反序列化这些数据在内存中重建出对应的组件和对象。当你停止运行这些运行时对象被销毁但序列化数据保持不变确保了你的编辑成果不会丢失。这种设计带来了几个核心优势非破坏性编辑编辑与运行时分离编辑操作安全可逆。引用持久化Unity通过序列化系统管理资源如材质、网格、其他预制体之间的引用。它并不是存储文件路径字符串而是生成一个全局唯一的GUID存储在.meta文件中和文件ID通过这两个标识符来定位资源。这保证了即使移动了资源文件只要.meta文件跟着引用就不会断裂。预制体系统的基础预制体的本质是一份序列化数据的模板。实例化预制体就是反序列化这份数据创建一个新对象。对预制体资源的修改会通过序列化差异Prefab Overrides系统同步到所有实例或反之这套复杂的逻辑完全构建在序列化之上。2.2 Unity默认序列化器YAML与二进制Unity主要使用两种格式来存储序列化数据YAML文本用于人类可读的场景和预制体二进制用于更高效的运行时资产包如AssetBundle。在Editor环境下我们主要和YAML打交道。你可以通过将编辑器设置为“Force Text”模式来查看这些YAML文件。打开一个简单的.prefab文件你会看到类似下面的结构--- !u!1 100000000 GameObject: m_ObjectHideFlags: 0 m_CorrespondingSourceObject: {fileID: 0} m_PrefabInstance: {fileID: 0} m_PrefabAsset: {fileID: 0} serializedVersion: 6 m_Component: - component: {fileID: 100000001} m_Name: MyCube --- !u!4 100000001 Transform: m_ObjectHideFlags: 0 m_CorrespondingSourceObject: {fileID: 0} m_PrefabInstance: {fileID: 0} m_PrefabAsset: {fileID: 0} serializedVersion: 2 m_LocalPosition: {x: 0, y: 0, z: 0} m_LocalRotation: {x: 0, y: 0, z: 0, w: 1} m_LocalScale: {x: 1, y: 1, z: 1}每一段以---开头的都是一个被序列化的对象。!u!1表示这是一个GameObject类型Class ID为1100000000是这个对象在文件内的唯一ID。组件列表通过文件ID{fileID: 100000001}进行引用。这种基于ID的引用网络构成了整个场景或预制体的数据图。注意直接手动编辑这些YAML文件是非常危险的操作极易导致文件损坏。了解它们是为了更好地理解原理而非进行日常操作。2.3 什么会被序列化规则与陷阱Unity不会序列化你的所有字段。它遵循一套明确的规则公共字段public fields默认会被序列化。标记了[SerializeField]的私有或受保护字段这是让非公共字段出现在Inspector并得以保存的关键。标记了[Serializable]的自定义结构体或类如果你想在Inspector中编辑一个自定义类型或者让它成为序列化数据的一部分这个属性是必须的。继承自UnityEngine.Object的类型如GameObject,Component,Material,Texture等Unity会序列化对它们的引用通过GUID和FileID。不会被序列化的包括属性Properties静态字段Static fields标记了[NonSerialized]或[System.NonSerialized]的字段只读字段readonly fields字典DictionaryTKey, TValue—— 这是一个著名的陷阱Unity的默认序列化器不支持直接序列化字典。你需要通过将其包装在一个可序列化的类中或者使用数组/list来模拟键值对。一个常见的陷阱示例using UnityEngine; using System.Collections.Generic; public class BadExample : MonoBehaviour { // 这个字典在Inspector中不可见数据也不会被保存 public Dictionarystring, int playerScores new Dictionarystring, int(); // 正确的做法使用可序列化的类来包装 [System.Serializable] public class ScoreEntry { public string playerName; public int score; } public ListScoreEntry serializableScores new ListScoreEntry(); }理解这些规则是避免数据丢失的第一步。在团队协作中明确哪些数据是“设计时配置”需要序列化哪些是“运行时状态”不需要序列化对于保持项目架构清晰至关重要。3. 深入自定义序列化与ISerializationCallbackReceiver当你需要序列化Unity默认不支持的类型如复杂的自定义类、字典、第三方库数据结构或者需要在序列化/反序列化的前后执行一些自定义逻辑如数据验证、缓存重建时就需要更强大的工具。3.1 使用[Serializable]与字段控制对于自定义的非 MonoBehaviour 类或结构体[Serializable]是入门券。但光有这个还不够你还需要注意其内部字段的可序列化性。[System.Serializable] public class CharacterStats { public string characterName; public int level; public float health; // 如果ResourceData本身也是自定义类它也必须标记为[Serializable] public ResourceData mana; [System.NonSerialized] // 这个字段不会被序列化常用于运行时缓存 public bool isInitialized false; } [System.Serializable] public class ResourceData { public float current; public float max; }3.2 实现 ISerializationCallbackReceiver 接口这是Unity提供的一个强大接口包含两个方法OnBeforeSerialize()和OnAfterDeserialize()。它允许你在序列化前后“插一脚”。典型应用场景1序列化字典这是最经典的用法。Unity不能直接序列化Dictionary但我们可以用两个List来分别存储键和值在序列化前后进行转换。using UnityEngine; using System.Collections.Generic; [System.Serializable] public class SerializableDictionaryTKey, TValue : ISerializationCallbackReceiver { // 这是我们实际使用的字典 private DictionaryTKey, TValue _dictionary new DictionaryTKey, TValue(); // 这两个列表用于Unity的序列化系统 [SerializeField] private ListTKey _keys new ListTKey(); [SerializeField] private ListTValue _values new ListTValue(); // 提供类似字典的访问接口 public TValue this[TKey key] { get _dictionary[key]; set _dictionary[key] value; } public bool ContainsKey(TKey key) _dictionary.ContainsKey(key); // ... 其他字典方法 // 在Unity即将序列化此对象之前调用 public void OnBeforeSerialize() { _keys.Clear(); _values.Clear(); foreach (var kvp in _dictionary) { _keys.Add(kvp.Key); _values.Add(kvp.Value); } // 注意这里假设键和值都是Unity可序列化的类型 } // 在Unity反序列化此对象之后调用 public void OnAfterDeserialize() { _dictionary.Clear(); if (_keys.Count ! _values.Count) { Debug.LogError($键值数量不匹配Keys: {_keys.Count}, Values: {_values.Count}); // 处理错误例如清空数据或尝试修复 return; } for (int i 0; i _keys.Count; i) { // 注意如果存在重复键这里会抛出异常。根据需求可以选择覆盖或跳过。 if (!_dictionary.ContainsKey(_keys[i])) { _dictionary.Add(_keys[i], _values[i]); } else { Debug.LogWarning($发现重复键: {_keys[i]}已跳过。); } } } } // 使用示例 public class GameManager : MonoBehaviour { public SerializableDictionarystring, int itemCounts new SerializableDictionarystring, int(); void Start() { itemCounts[Potion] 5; itemCounts[Sword] 1; // 现在itemCounts可以在Inspector中显示虽然不直观并且其数据会随场景/预制体保存。 } }实操心得在OnAfterDeserialize中一定要加入健壮性检查。因为YAML文件可能被人为修改损坏或者在不同版本间出现兼容性问题。检查列表长度是否一致、键是否重复能有效防止反序列化后程序出现不可预知的行为。典型应用场景2重建运行时缓存或引用有些数据为了运行效率我们会预先计算并缓存起来但这些缓存数据不需要保存。我们可以在反序列化后重建它们。public class SkillDatabase : MonoBehaviour, ISerializationCallbackReceiver { // 设计时配置技能ID和预制体引用的列表 [SerializeField] private Liststring _skillIds new Liststring(); [SerializeField] private ListGameObject _skillPrefabs new ListGameObject(); // 运行时缓存用于快速查找的字典 private Dictionarystring, GameObject _skillCache; public GameObject GetSkillPrefabById(string id) { if (_skillCache.TryGetValue(id, out GameObject prefab)) return prefab; return null; } public void OnBeforeSerialize() { // 如果我们允许运行时动态添加技能可能需要在这里将_cache同步回两个List。 // 但更常见的模式是_skillIds和_skillPrefabs是设计时配置运行时只读。 // 所以这里可能什么都不做。 } public void OnAfterDeserialize() { // 反序列化后重建运行时缓存 RebuildCache(); } private void RebuildCache() { _skillCache new Dictionarystring, GameObject(); for (int i 0; i Mathf.Min(_skillIds.Count, _skillPrefabs.Count); i) { if (!string.IsNullOrEmpty(_skillIds[i]) _skillPrefabs[i] ! null) { _skillCache[_skillIds[i]] _skillPrefabs[i]; } } Debug.Log($技能缓存重建完成共 {_skillCache.Count} 项。); } void Awake() { // 确保Awake时缓存也已建立应对脚本动态添加等情况 if (_skillCache null) RebuildCache(); } }3.3 自定义序列化属性与PropertyDrawer有时你希望以特殊的方式在Inspector中显示和编辑序列化数据而不仅仅是默认的字段展开。这就需要用到PropertyAttribute和PropertyDrawer。例如你想为一个取值范围在0-100的整数创建一个滑动条// 1. 定义属性 public class RangeSliderAttribute : PropertyAttribute { public readonly float Min; public readonly float Max; public RangeSliderAttribute(float min, float max) { Min min; Max max; } } // 2. 定义对应的Drawer #if UNITY_EDITOR using UnityEditor; [CustomPropertyDrawer(typeof(RangeSliderAttribute))] public class RangeSliderDrawer : PropertyDrawer { public override void OnGUI(Rect position, SerializedProperty property, GUIContent label) { var rangeAttr (RangeSliderAttribute)attribute; if (property.propertyType SerializedPropertyType.Integer) { EditorGUI.IntSlider(position, property, (int)rangeAttr.Min, (int)rangeAttr.Max, label); } else if (property.propertyType SerializedPropertyType.Float) { EditorGUI.Slider(position, property, rangeAttr.Min, rangeAttr.Max, label); } else { EditorGUI.LabelField(position, label.text, RangeSlider只能用于int或float类型。); } } } #endif // 3. 使用 public class PlayerStats : MonoBehaviour { [RangeSlider(0, 100)] public int health; [RangeSlider(0f, 1f)] public float attackCriticalChance; }通过自定义PropertyDrawer你可以为特定的数据类型创建极其友好和高效的编辑界面这在大规模数据配置时能极大提升策划和设计师的工作效率。SerializedProperty对象是Unity编辑器序列化系统在GUI层面的体现通过它你可以安全地读取和修改序列化字段的值。4. 性能考量与高级话题4.1 序列化数据体积优化随着项目规模增长场景和预制体文件可能会变得非常大导致打开、保存、加载速度变慢。优化序列化数据体积是项目后期必须面对的挑战。1. 精简不必要的序列化字段这是最直接有效的方法。定期审查你的MonoBehaviour脚本那些仅在运行时计算、不需要配置的中间变量是否误标记了public或[SerializeField]那些庞大的配置数据数组是否真的每个实例都需要能否移到一个共享的ScriptableObject资产中2. 使用[SerializeField]替代无意义的public如果一个字段只需要在Inspector中显示而不需要被其他类直接访问那么应该将其设为private或protected然后加上[SerializeField]。这遵循了面向对象封装的原则也避免了其他脚本意外依赖它。3. 警惕引用型数据的重复序列化如果一个预制体引用了同一个材质球100次这个材质球的引用信息GUID和FileID会在预制体数据中重复100次吗不会Unity的序列化系统会对同一对象的引用进行优化存储。但如果你有100个不同的字符串每个都包含很长的路径或JSON文本它们就会被完整地存储100次。对于这种情况考虑使用共享的ScriptableObject或建立索引机制。4. 对大型数组或列表使用[NonSerialized]配合运行时初始化如果有一个很大的默认配置数组每次实例化都序列化它会很浪费。可以这样做public class BigDataContainer : MonoBehaviour { [System.NonSerialized] // 不保存到磁盘 public int[] hugeArray; void Awake() { if (hugeArray null || hugeArray.Length 0) { // 在运行时初始化默认值 hugeArray new int[10000]; // ... 填充默认数据 } } }这样预制体或场景文件中就不会包含这10000个整数的数据只在运行时内存中存在。代价是失去了在编辑器中直观配置这些数据的能力需根据实际情况权衡。4.2 ScriptableObject序列化数据的强大容器ScriptableObject是Unity中用于存储大量独立于游戏对象的数据的基类。它本身就是一个可序列化的资产.asset文件。为什么使用ScriptableObject数据共享一个ScriptableObject资产可以被多个预制体、场景或组件引用避免数据重复。内存高效即使被引用1000次内存中也只有一份数据实例。热重载支持在Editor模式下修改ScriptableObject资产并保存运行时引用了该资产的对象可以立即看到变化需配合OnValidate等方法非常适合做游戏平衡性调整。逻辑与数据分离将配置数据从MonoBehaviour脚本中剥离出来使脚本更专注于行为逻辑。创建和使用示例// 1. 创建数据类 using UnityEngine; [CreateAssetMenu(fileName NewWeaponData, menuName Game Data/Weapon)] public class WeaponData : ScriptableObject { public string weaponName; public int damage; public float attackSpeed; public GameObject projectilePrefab; public AudioClip attackSound; } // 2. 在编辑器中使用右键 Create - Game Data - Weapon // 3. 在MonoBehaviour中引用 public class WeaponController : MonoBehaviour { public WeaponData currentWeaponData; // 拖拽WeaponData资产到这里 void Attack() { if (currentWeaponData.projectilePrefab ! null) { Instantiate(currentWeaponData.projectilePrefab, transform.position, transform.rotation); } // 使用 currentWeaponData.damage 等... } }ScriptableObject的序列化它和MonoBehaviour一样其公共字段和标记了[SerializeField]的字段会被序列化到.asset文件中。对它的引用也是通过GUID和FileID来维护的。4.3 预制体变体Prefab Variant与序列化覆盖预制体变体是管理相似但略有不同对象的神器。从序列化角度看变体存储的是与其父预制体Base Prefab的差异部分。序列化覆盖Prefab Overrides 当你创建一个预制体实例并修改了它的某个属性如Transform的位置这个修改就是该实例的一个“覆盖”。在Inspector中被覆盖的属性名会是粗体。你可以选择“Apply”将这个覆盖应用回预制体资源或者“Revert”撤销它。变体的序列化原理 变体文件本身只序列化那些与父预制体不同的组件和属性。例如父预制体有一个Enemy脚本health为100。你创建一个变体只将health改为150。那么变体文件中只会序列化这个Enemy脚本组件以及health字段的差异值。其他完全相同的部分如模型引用、其他组件则通过引用父预制体来获得。实操心得处理嵌套预制体与覆盖的复杂性当预制体嵌套其他预制体时覆盖关系会变得复杂。一个常见的坑是你修改了一个嵌套预制体实例的属性然后应用Apply到根预制体可能会意外地将修改应用到所有使用该嵌套预制体的地方。我的建议是明确预制体层级结构避免过深的嵌套。应用覆盖前使用“Open Prefab”模式仔细检查影响的范围。对于需要大量差异化配置的物体考虑使用ScriptableObject来存储配置数据让预制体通过引用不同的数据资产来产生变化这比创建大量变体更容易管理。4.4 版本兼容性与序列化迁移随着项目迭代你的数据结构可能会改变。比如在PlayerStats类中你把public int mana;改成了public ResourceData manaResource;。旧版本项目中的预制体和场景里保存的仍然是int类型的mana数据当用新代码打开时Unity的反序列化过程可能会失败字段不匹配导致数据丢失。Unity的默认行为 Unity的序列化系统在一定程度上是容错的。如果字段类型完全改变如int到ResourceData旧数据通常会丢失字段变为默认值。如果只是字段改名Unity有时能通过元数据尝试匹配但并不可靠。手动处理版本迁移 对于重要的、广泛使用的数据类实现版本迁移是必要的。可以通过实现ISerializationCallbackReceiver来做到。[System.Serializable] public class PlayerStats_V2 : ISerializationCallbackReceiver { public ResourceData manaResource; // 旧版本的字段标记为过时且不序列化 [System.NonSerialized] [System.Obsolete(Use manaResource instead)] private int _manaBackingField; // 这个属性仅用于兼容旧序列化数据 [SerializeField] private int mana { get _manaBackingField; set { _manaBackingField value; // 如果从旧数据反序列化到了这个属性在这里进行迁移 if (manaResource null) manaResource new ResourceData(); manaResource.current value; manaResource.max value; // 假设旧版本最大法力等于当前值或需要一个默认最大值 } } public void OnBeforeSerialize() { // 序列化前确保兼容性字段是空的我们不希望保存旧格式 // _manaBackingField 0; // 可选清空旧数据 } public void OnAfterDeserialize() { // 反序列化后如果 mana 字段被读取了即旧数据迁移逻辑已在属性的setter中执行。 // 可以在这里做一些额外的清理或验证。 if (manaResource null) { manaResource new ResourceData { current 100, max 100 }; // 提供新版本的默认值 } } }这种方法有点“黑科技”利用了Unity会序列化属性背后的私有支持字段如果它有[SerializeField]的特性。更系统化的方案是为整个数据类维护一个版本号字段在OnAfterDeserialize中根据版本号执行不同的迁移逻辑。对于大型项目可能需要编写专门的迁移工具来批量更新预制体和场景文件。5. 常见问题排查与实战技巧5.1 数据丢失的典型场景与修复问题1字段在Inspector中显示为默认值编辑后无法保存。原因该字段可能没有被正确序列化。检查它是否是public或标记了[SerializeField]。如果它是一个自定义类/结构体是否忘了加[System.Serializable]属性排查在脚本文件中右键点击该字段选择“Find References”确保没有其他代码意外地在其Awake()或Start()中将其重置。问题2预制体实例的修改无法应用Apply回原预制体。原因可能该实例已经不再是原预制体的直接实例例如它被嵌套在另一个预制体中或者你修改的是预制体资源本身。也可能是该属性被标记为“不可覆盖”某些特殊组件属性。解决在Hierarchy中选中实例查看Inspector顶部的预制体操作按钮。确认显示的是“Overrides”。尝试在预制体模式下Open Prefab直接编辑。问题3场景加载后脚本中动态赋值的引用如public GameObject target;为null。原因这是序列化引用与运行时引用的经典混淆。你在运行时如Start()中通过GameObject.Find或GetComponent获取的引用不会被自动序列化保存到场景文件。下次加载场景时这些字段又是null。解决设计时赋值如果引用对象在场景编辑时就已存在直接在Inspector中拖拽赋值。这是最可靠的方式。运行时查找并缓存在Awake()或Start()中查找并考虑使用[System.NonSerialized]明确表示这是运行时缓存。使用唯一标识符如果对象是动态生成的序列化一个唯一ID如string类型的targetId在加载后根据ID去查找。这需要你自己维护一个ID到对象的映射表。5.2 编辑器脚本中的序列化操作当你编写编辑器扩展工具时经常需要以编程方式读取或修改序列化数据如批量修改大量预制体的某个属性。这时你需要使用SerializedObject和SerializedPropertyAPI。#if UNITY_EDITOR using UnityEditor; using UnityEngine; public static class BatchPrefabModifier { [MenuItem(Tools/Batch Modify Prefab Health)] public static void BatchModifyHealth() { // 1. 获取所有选中的预制体资产 var selectedObjects Selection.GetFilteredGameObject(SelectionMode.Assets); foreach (GameObject prefabAsset in selectedObjects) { // 2. 为整个GameObject创建一个SerializedObject SerializedObject serializedPrefab new SerializedObject(prefabAsset); // 3. 假设每个预制体根节点上有一个Enemy脚本 // 我们需要找到这个组件。更通用的做法是遍历所有组件。 var enemyComponent prefabAsset.GetComponentEnemy(); if (enemyComponent ! null) { // 4. 针对该特定组件实例创建SerializedObject SerializedObject serializedEnemy new SerializedObject(enemyComponent); // 5. 找到要修改的属性 SerializedProperty healthProperty serializedEnemy.FindProperty(health); if (healthProperty ! null healthProperty.propertyType SerializedPropertyType.Integer) { // 6. 修改属性值 healthProperty.intValue 200; // 7. 应用修改到目标对象 serializedEnemy.ApplyModifiedProperties(); // 8. 记得也要应用回预制体资产如果修改了GameObject的SerializedObject // serializedPrefab.ApplyModifiedProperties(); Debug.Log($已修改预制体 {prefabAsset.name} 的health为200。); } } // 9. 保存资产 EditorUtility.SetDirty(prefabAsset); } AssetDatabase.SaveAssets(); Debug.Log(批量修改完成。); } } #endif重要提示编辑器脚本中的序列化操作必须包裹在#if UNITY_EDITOR条件编译指令中并且要放在Editor文件夹下。SerializedObject/SerializedPropertyAPI是唯一安全、可靠地在编辑器代码中修改序列化数据的方式直接修改对象的字段不会触发Unity的序列化脏标记可能导致修改不被保存。5.3 第三方序列化方案与Unity的集成对于复杂的游戏数据如整个游戏的配置表、存档系统Unity自带的序列化可能不够灵活或性能不佳。这时可以考虑集成第三方序列化库如Json.NET (Newtonsoft.Json)或System.Text.Json.NET Core后内置。为什么选择第三方JSON库跨平台和语言兼容性JSON是通用格式便于与服务器、其他工具链交换数据。更丰富的特性支持多态类型序列化、更灵活的循环引用处理、更强大的自定义转换器。性能对于大量数据的序列化/反序列化专门的JSON库可能比Unity的YAML系统更快尤其是在构建后运行时。集成示例使用Json.NET通过Unity的Package Manager或手动将Json.NET的DLL添加到项目。将需要保存的数据设计为纯粹的C#类POCO不要继承MonoBehaviour。使用JsonConvert.SerializeObject和DeserializeObject进行转换。using Newtonsoft.Json; using System.IO; using UnityEngine; [System.Serializable] // 这个标记对Json.NET不是必须的但保留它以便Unity Inspector可能用到。 public class GameSaveData { public string playerName; public int playerLevel; public Vector3 lastCheckpointPosition; // Json.NET可以处理一些Unity基础类型但复杂类型需要自定义转换器。 public ListInventoryItem inventory; } public class SaveSystem { private string _saveFilePath; public SaveSystem(string fileName) { _saveFilePath Path.Combine(Application.persistentDataPath, fileName); } public void SaveGame(GameSaveData data) { // 配置Json.NET处理Unity类型如Vector3 JsonSerializerSettings settings new JsonSerializerSettings { Converters new ListJsonConverter { new UnityVector3Converter() }, // 需要自定义转换器 Formatting Formatting.Indented }; string json JsonConvert.SerializeObject(data, settings); File.WriteAllText(_saveFilePath, json); Debug.Log($游戏已保存至: {_saveFilePath}); } public GameSaveData LoadGame() { if (!File.Exists(_saveFilePath)) return null; string json File.ReadAllText(_saveFilePath); JsonSerializerSettings settings new JsonSerializerSettings { Converters new ListJsonConverter { new UnityVector3Converter() } }; GameSaveData data JsonConvert.DeserializeObjectGameSaveData(json, settings); return data; } } // 自定义转换器示例需引用 Newtonsoft.Json public class UnityVector3Converter : JsonConverterVector3 { public override void WriteJson(JsonWriter writer, Vector3 value, JsonSerializer serializer) { writer.WriteStartObject(); writer.WritePropertyName(x); writer.WriteValue(value.x); writer.WritePropertyName(y); writer.WriteValue(value.y); writer.WritePropertyName(z); writer.WriteValue(value.z); writer.WriteEndObject(); } public override Vector3 ReadJson(JsonReader reader, Type objectType, Vector3 existingValue, bool hasExistingValue, JsonSerializer serializer) { // 简化实现实际需要更健壮的解析 var obj serializer.DeserializeDictionarystring, float(reader); return new Vector3(obj[x], obj[y], obj[z]); } }注意事项类型安全JSON是弱类型的反序列化时如果数据结构不匹配会抛出异常要做好错误处理。版本控制和Unity序列化一样数据结构变更需要考虑向前/向后兼容可以像之前一样在数据类中加入版本号字段和迁移逻辑。性能对于频繁存取的极小数据二进制格式如BinaryFormatter但已过时或自定义二进制格式可能更快但JSON在可读性和调试便利性上优势巨大。Unity类型Vector3、Quaternion、Color等Unity特有类型Json.NET默认无法处理需要编写自定义的JsonConverter如上例所示。深入理解Unity序列化就像是拿到了引擎编辑器和数据管理层的“钥匙”。它不再是一个黑盒你知道Inspector里的每一个输入框背后数据是如何流动和存储的你知道预制体变体和覆盖是如何计算的你也知道当场景加载时内存中发生了什么。这份理解能让你在遇到诡异的数据丢失问题时快速定位在需要深度定制编辑器时得心应手在规划项目数据架构时做出更明智的决策。从被动地使用功能到主动地设计和掌控流程这正是从Unity使用者迈向资深开发者的关键一步。
