企业官网建设流程全解析

先说一个我判断“你的游戏到底做没做完”的土办法：把存档相关代码全部注释掉，退出游戏再进一次。如果音量设置、金币、关卡进度、已经解锁的皮肤全部复位，那这游戏在玩家眼里就是没做完，甚至比玩法无聊更致命——玩家只会觉得自己白玩了。Unity里解决“退出再进一切归零”的方案，统一叫Unity数据持久化，但这个词被讲得太宽泛了，从两行PlayerPrefs到一整套加密存档都算了进去。这篇文章我会按真实项目里最常见的选择顺序来讲：先判断你的玩法到底需要哪一级持久化，再讲PlayerPrefs和文件方案各自的边界，接着给出一个可以直接抄进项目的存档管理器，最后把跨平台和移动端最容易踩的坑一次说完。新入行或者一直在用PlayerPrefs一把梭的，都建议完整看一遍，很多坑真不是报错能教给你的。

1. 先想清楚：你的游戏到底需要哪种程度的数据持久化

1.1 数据需求分级：从音量设置到全量存档

我每次做项目前，都会先把“要存的数据”列出来做分级，因为方案选错通常会带来返工，而返工在游戏存储上特别恶心：旧存档格式已经发给测试了，新结构解析不了，就得写迁移器，一次两次还能忍，频繁换方案会耗掉大量时间。按我的经验，游戏数据基本可以分成下面几级。

第一级是设置类数据：音量、画质档位、语言、是否开启震动、上次登录的服务区、新手引导是否看过。这类数据的特点是值少、结构简单、彼此之间没有强关联，用键值对存完全够。第二级是进度类数据：当前关卡、金币、道具、任务进度、拥有的皮肤、剧情选择记录，这类数据天然是一个有嵌套关系的对象，必须整个序列化后才能恢复游戏状态。第三级是超大数据加查询需求：背包里几百件物品、邮件列表、跨服务器的排行榜。这类数据如果硬塞进一个JSON，读写时全量序列化会造成明显卡顿，而且排序、过滤这些操作也很别扭，通常要考虑分文件存储或者本地数据库。

还有一种特殊情况我经常在开发阶段用到：给编辑器设计的配置工具、原型演示用的初始数据，这种数据并不属于玩家存档，更适合用ScriptableObject或者单独的配置文件直接放在Resources或StreamingAssets里。它们跟着包走，只读，但不需要运行时写入，也不是持久化该负责的范畴。很多初学的人会把这两类混在一起，结果把配置文件放到可写目录里，一升级就被覆盖了。

1.2 存档不只是技术问题，它本身就是玩家体验的一部分

我观察到很多团队把存档当成最后才做的“收尾工作”，这是我在实际项目里见过最要命的事情之一。玩家对存档的感知，比对画面渲染的感知更强烈：想象一下玩家打完Boss，激动地退出游戏，第二天打开发现进度还是昨天的，那种失望基本等于直接卸载。存档的位置、多槽位、自动保存的时机、存档损坏后的提示文案，这些都是产品体验的一部分，不是单纯的IO代码。

具体来说，至少要考虑几个问题：存档是单槽还是多槽？多槽位意味着开始界面的“继续游戏”和“新游戏”要严格区分。自动保存的频率怎么定？是过一关存一次，还是回城存一次，还是每30秒静默存一次？如果每30秒存一次，要不要给玩家一个小图标提示？进程被系统杀掉时怎么兜底，是双槽备份还是在写入时就保证原子操作？这些设计一旦错过了项目中期，后面基本没法大改。所以我建议哪怕第一版只用最简单的方式，也要先把存档的入口、出口、备份、迁移这几个壳做好，之后换存储细节就只是替换底层实现而已。

2. PlayerPrefs能撑多久：轻量存储的真实边界

2.1 PlayerPrefs的底层逻辑：一个全局键值表

PlayerPrefs大概是Unity里最早被认识的持久化接口，它本质上就是一个以字符串为键、以基础类型为值的全局表，支持int、float、string三种类型。SetInt、SetFloat、SetString写进去，GetInt、GetFloat、GetString读出来，再没有更多结构上的能力。你没法往里塞一个List，也没法嵌套一个对象，真要存复杂数据只能先手动序列化成字符串再塞进去，取出来再反序列化，维护起来非常痛苦。

更关键的是它的存储位置在不同平台上完全不一样。我做项目时会先确认目标平台，因为PlayerPrefs在Windows上会落到注册表里，在macOS上是plist文件，在Android上是应用私目录里的shared_prefs XML，在iOS上是NSUserDefaults，在WebGL上则通过IndexedDB模拟。不同实现有一个共同点：它不要求你主动指定路径，也不允许你管理文件本身。这意味着玩家换设备、清缓存、重装应用，数据会跟着系统机制走，你没法把存档像文件一样导出来备份或者跨平台迁移。

在Android上还要特别注意一点：系统并不保证每次Set之后都立即同步到磁盘。官方文档里明确建议在关键时机调用PlayerPrefs.Save()强制写入，但即便这样，进程被系统突然杀掉时依然存在丢失的可能。我遇到过不少测试反馈说“设置明明改好了，重进又变回去”，排查半天，基本都是因为没加Save或者在极端时序下没有来得及落盘。

2.2 什么时候继续用PlayerPrefs，什么时候必须换

我的经验边界很简单：如果数据量只有十几个底层字段，而且彼此基本独立，用PlayerPrefs是合理选择。典型的场景就是设置面板。音量、画质、语言、震动开关，每个都是单一值，读取时也就是启动界面做几次Get，写入频繁一点也没什么性能压力。这种情况下引入一套JSON文件反而属于过度设计，还要额外处理路径和文件锁。

一旦数据开始变成“一个有结构的对象”，不管是十几字段还是上百字段，就该果断换到文件持久化。判断标准有三个：第一，字段数量超过你能在PlayerPrefs里维护的极限，大概十来个以上就开始乱了；第二，数据之间出现嵌套、数组、枚举、一对多关系；第三，任何一次修改需要“整体回滚”或者“版本迁移”。这三个信号出现任意一个，PlayerPrefs都不合适。有人会用一个很长的JSON字符串塞进PlayerPrefs的string值里，这种做法不是不能用，但它同时占用了两个方案的缺点：既没有PlayerPrefs的简单直接，也没有文件方案的可读、可备份、可扩展。一旦存档结构升级，你会被这个混合方案折腾到怀疑人生。

这份对比可以很直观地帮你做初步选型：

3. 手写一套够用的存档管理器：从JSON序列化到加密落地

3.1 为什么我建议从JSON文件开始

当你确认需要文件持久化之后，第一个要决定的问题就是文件格式。我强烈建议默认从JSON开始，除非有明确理由不这么做。JSON在文本编辑器里直接可读，这意味着出问题时不用靠猜，打开文件就能看到玩家当前的金币、关卡、道具id到底是合理还是异常。对于开发者来说，这种“看得见的存档”就是最好的调试工具。而且JSON以纯文本保存，天然跨平台，不会遇到二进制格式在字节对齐和大小端上的问题。

相比二进制，JSON的体积确实会大一些，但对于普通游戏的存档来说，几十KB甚至一两百KB几乎可以忽略不计。真正会被体积拖累的项目，一般已经超过了几兆，那时候需要的不是换格式，而是拆文件，这点后面专门说。还有一个容易忽略的好处：JSON存档可以用任何版本管理工具去diff，做自动化测试、做存档对比、做异常分析都很方便，这一点在长期维护的项目里价值极高。

3.2 JsonUtility的硬伤和Json.NET的补充

Unity自带的JsonUtility是官方序列化工具，好处是零依赖、生成和解析速度都不错，能和Unity的Serializable机制天然配合，直接支持public字段以及标了[SerializeField]的私有字段。但它有三个硬伤，我在项目里都踩过。

第一，它不支持Dictionary。哪怕你只是想存一个“道具id到数量”的映射表，JsonUtility也会在序列化时当成一个空对象处理，存进去再读出来数据就飞了。第二，它不支持多态。如果某个字段声明的是基类或者接口类型，运行时塞进去的实际上是子类对象，JsonUtility只会序列化基类里声明的那部分字段，子类的专有字段全部丢失。第三，它不支持属性（property），也不支持JsonIgnore之类的常用特性，序列化行为基本被Unity的序列化规则绑死。此外，如果反序列化时目标类是一个struct，遇到JSON里缺失字段，某些情况下还会报错，而不是静默填默认值。

所以我在项目中的习惯是：用JsonUtility打底，但一旦数据结构里出现Dictionary或者需要多态，就直接换成第三方JSON库。Unity官方通过包管理器提供了Newtonsoft.Json的封装包（包名是com.unity.nuget.newtonsoft-json），安装之后就可以用几乎标准的方式处理字典、属性、字段改名、条件忽略、嵌套迁移这些复杂需求。它的代价是包体积和少量运行时GC，对存档这种低频操作完全不是问题。我在下面的示例代码里先用JsonUtility，因为它零依赖、代码更短，实际项目中你完全可以把序列化那两行替换成Newtonsoft.Json，整体思想和流程不变。

3.3 存档数据结构的设计与版本号

在设计存档类时，我建议先做一个独立的GameData作为“存档快照”，把玩家运行时状态全部装进去。这个类最好单独放一个文件，和业务逻辑类拆开。存档结构的字段一旦上线就不建议随便重命名，因为旧存档里的字段名会和新版对不上，所以我通常会在最初就留一个saveVersion字段。

下面是一个最小但完整的存档结构示例：

using System; using System.Collections.Generic; [Serializable] public class GameData { public int saveVersion = 1; // 存档版本号，迁移用 public string playerName = "Player"; public int gold; public int currentLevel = 1; public bool muted; public float bgmVolume = 0.8f; public List<int> unlockedLevels = new List<int>(); public List<ItemData> items = new List<ItemData>(); } [Serializable] public class ItemData { public string id; public int count; }

我把设置项和进度项放进了同一个对象，因为对绝大多数项目来说，玩家设置和游戏进度在“存档时机”上并没有本质区别，保存时一起写，加载时一起读，反而减少文件数量。如果后续需要更精细的写入频率控制，再拆成多个文件不迟，一开始过度拆分只会增加维护负担。saveVersion这个字段是我最强调的一部分：哪怕现在的版本永远是1，也一定要写。因为游戏一旦上线，你没法控制玩家手里的旧存档，版本号加上迁移逻辑，是唯一能保证“旧档不废”的手段。

3.4 SaveManager核心代码：临时文件、双槽备份与读取回退

接下来就是核心的存档管理器。这个类我一般写成纯C#类，不继承MonoBehaviour，不需要挂到场景里的GameObject上，通过静态Instance访问就行。它的核心责任有三个：把GameData序列化后写入文件、读取文件并反序列化成GameData、处理写入失败和存档损坏。

using System; using System.IO; using System.Text; using UnityEngine; public class SaveManager { public static SaveManager Instance = new SaveManager(); private const string SaveFileName = "save.dat"; private const string BackupFileName = "save.bak"; private const int CurrentVersion = 1; private string SavePath { get { return Path.Combine(Application.persistentDataPath, SaveFileName); } } private string BackupPath { get { return Path.Combine(Application.persistentDataPath, BackupFileName); } } public void Save(GameData data) { try { data.saveVersion = CurrentVersion; string json = JsonUtility.ToJson(data, true); byte[] bytes = Encrypt(Encoding.UTF8.GetBytes(json)); WriteAtomic(SavePath, bytes); WriteAtomic(BackupPath, bytes); } catch (Exception e) { Debug.LogError("存档写入失败: " + e); } } public GameData Load() { byte[] bytes = ReadBytes(SavePath); if (bytes == null) bytes = ReadBytes(BackupPath); if (bytes == null) return CreateDefaultData(); try { string json = Encoding.UTF8.GetString(Decrypt(bytes)); GameData data = JsonUtility.FromJson<GameData>(json); if (data == null) return CreateDefaultData(); Migrate(data); return data; } catch (Exception e) { Debug.LogWarning("主存档解析失败，尝试备份: " + e); byte[] backup = ReadBytes(BackupPath); if (backup != null) { try { string json = Encoding.UTF8.GetString(Decrypt(backup)); GameData data = JsonUtility.FromJson<GameData>(json); if (data != null) { Migrate(data); return data; } } catch { } } return CreateDefaultData(); } } private void WriteAtomic(string path, byte[] bytes) { string tmpPath = path + ".tmp"; File.WriteAllBytes(tmpPath, bytes); if (File.Exists(path)) File.Delete(path); File.Move(tmpPath, path); } private byte[] ReadBytes(string path) { return File.Exists(path) ? File.ReadAllBytes(path) : null; } private GameData CreateDefaultData() { GameData data = new GameData(); data.unlockedLevels.Add(1); return data; } private void Migrate(GameData data) { if (data.saveVersion >= CurrentVersion) return; // 这里根据 data.saveVersion 做逐版本迁移 // 比如此前版本没有 gold 字段，可以从其他字段或默认值补充 data.saveVersion = CurrentVersion; } }

这段代码里最值得解释的是WriteAtomic。直接调用File.WriteAllBytes看起来简单，但一旦游戏在写入过程中崩溃，文件可能只写了一半，下次读取轻则丢字段，重则解析失败。我的做法是先写一个带.tmp后缀的临时文件，写完再删除旧文件并Move替换。这样无论什么时候崩溃，正式路径上的文件要么是旧版完整文件，要么是刚写好的新版完整文件，绝不会出现半个文件。备份文件也保持同一套写入逻辑，等于给存档上了第二道保险。

Load方法里，我设计了“主存档坏了就自动读备份”的回退逻辑。分类讨论一下：正常情况直接读主存档；主存档文件不存在就去读备份；主存档存在但解析失败，打印警告后尝试备份；备份也损坏，才返回默认数据。这种逻辑看起来多了一堆代码，但对玩家来说就是“进度还在”和“进度没了”的天壤之别。很多项目只用单文件，一旦存档损坏就归零，这是我对存档设计里比较深的一条教训。

3.5 加一层简单加密：AES-CBC落地

明文JSON能给开发带来便利，但到了正式上线，尤其是包含内购、货币、道具这类数据的游戏，我建议至少加一层对称加密。为什么要加？不是因为玩家一定会改存档，而是因为不改的成本太低：玩家只需要用文本编辑器打开存档文件，把金币数字从100改成999999，游戏就“通关”了。这种篡改不光是作弊，还会污染你的后台数据分析。加密的目的就是把这个门槛抬高，让普通玩家不能随手改。

我用AES-CBC实现一个最小可用的加解密，密钥和IV放在代码里。先明确一点：客户端里的密钥理论上一定可以被逆向提取，所以这套加密防的是“随手改”，不是“专业黑客”，专业场景要配合服务端校验使用，那是另一套架构。

private static readonly byte[] AesKey = { 0x4F, 0x12, 0xA3, 0x77, 0x1C, 0x9B, 0x2E, 0xD4, 0x63, 0x71, 0x8A, 0x0F, 0x2C, 0xE5, 0x91, 0x48, 0x5D, 0x33, 0xB6, 0x0A, 0x7C, 0x1E, 0xF2, 0xD8, 0x84, 0x69, 0xC0, 0x3D, 0xAA, 0xF5, 0x18, 0x4B }; private static readonly byte[] AesIv = { 0x8F, 0xA2, 0x5C, 0x71, 0xD6, 0x0B, 0x49, 0xE3, 0x27, 0x94, 0x1B, 0x7E, 0xC8, 0x32, 0x6D, 0xF0 }; private static byte[] Encrypt(byte[] plainBytes) { using (Aes aes = Aes.Create()) { aes.Key = AesKey; aes.IV = AesIv; using (MemoryStream ms = new MemoryStream()) { using (CryptoStream cs = new CryptoStream(ms, aes.CreateEncryptor(), CryptoStreamMode.Write)) { cs.Write(plainBytes, 0, plainBytes.Length); } return ms.ToArray(); } } } private static byte[] Decrypt(byte[] encryptedBytes) { using (Aes aes = Aes.Create()) { aes.Key = AesKey; aes.IV = AesIv; using (MemoryStream ms = new MemoryStream()) { using (CryptoStream cs = new CryptoStream(ms, aes.CreateDecryptor(), CryptoStreamMode.Write)) { cs.Write(encryptedBytes, 0, encryptedBytes.Length); } return ms.ToArray(); } } }

注意，这里固定IV的做法仅用于演示。正式项目里，更稳妥的方案是把随机IV拼在密文头部，解密时读取；或者干脆不做对称加密，只做HMAC签名校验，效果一样是让玩家不能随手改。不管选哪种，都要记得密钥不能放在容易被打包的Resources等明文资源里，至少想点办法混淆一下。我见过很多团队做加密，最后密钥就写死在代码里，然后又用base64包了一层，等于没加密。加解密代码一定要和游戏逻辑分开，方便维护和替换。

4. 跨平台存档那些坑：路径、时序、编码与反序列化

4.1 可写路径永远只有一个：persistentDataPath

很多人第一次做存档，都会直接用Application.dataPath，因为在PC编辑器上它看起来完全正常，能读能写。但一旦打包到Android或者iOS，dataPath对应的目录是只读的，写入要么静默失败，要么直接报错。Mac上还有一个更隐蔽的情况，.app目录看起来可写，实际写的是包内容，一校验签名或者更新版本就没了。

正确的可写路径只有一个：Application.persistentDataPath。在移动端它是应用沙盒里的私有目录，App没被删除前数据一直在，系统也不会随便清掉。StreamingAssetsPath则是随包发布的只读目录，适合放初始存档模板、关卡配置文件，不适合运行时写回。这个路径问题的规则很简单：玩家产生的数据一律写到persistentDataPath，资源自带数据放到StreamingAssetsPath或Resources，永远不要在dataPath上做写入操作。

4.2 移动端退出即丢档的时序问题

移动端的保存时机比PC复杂很多。玩家切到后台、按Home键、来电话、屏幕锁定，应用都会经历暂停或失焦事件。很多开发者习惯把存档写到OnApplicationQuit，但移动端这个方法并不靠谱：系统可能不会给你完整的退出回调，进程直接被系统回收的情况太常见了。更合理的方式是重写OnApplicationPause和OnApplicationFocus，这两个回调在切后台时会触发，是移动端保存的关键时机。

我的参考方案是三层配合：第一层，在关键玩法节点主动保存，比如通关、结算、获得重要道具；第二层，监听OnApplicationPause和OnApplicationFocus，在暂停时把当前GameData完整写一次；第三层，OnApplicationQuit里只做简单的兜底，而不做过重的IO。每层都保证是幂等的，随时可以重入，这样即使触发时机奇怪，数据也不会处于中间态。另外要记住，PlayerPrefs和文件相关操作尽量放在主线程做逻辑，在后台线程里访问Unity相关API容易出问题；如果存档非常大，再考虑队列化写入。

4.3 中文乱码、字典序列化和字段改名

编码问题是文件存档里最容易自己坑自己的点。Windows记事本默认的历史编码习惯，以及不同平台对无BOM文本的解析差异，会让中文变成乱码。解决方案很简单：统一用UTF-8显式读写。File.WriteAllText和File.ReadAllText默认行为并不保证一致，最稳的方式是指定Encoding.UTF8，或者像上面的示例那样先转成byte数组再读写。

字典是另一个高频雷区。JsonUtility不支持Dictionary，很多人第一次存道具数量表时就踩了：数据写入不报错，读出来后集合是空的。如果不想上Json.NET，可以用两个平行List来处理映射关系，写一个专门的可序列化包装类：

[Serializable] public class SerializableDict<K, V> { public List<K> keys = new List<K>(); public List<V> values = new List<V>(); public Dictionary<K, V> ToDict() { var dict = new Dictionary<K, V>(); for (int i = 0; i < keys.Count; i++) dict[keys[i]] = values[i]; return dict; } public void FromDict(Dictionary<K, V> source) { keys.Clear(); values.Clear(); foreach (var pair in source) { keys.Add(pair.Key); values.Add(pair.Value); } } }

这段代码避免了很多序列化难题，缺点是按键顺序不保证，还需要运行时转换一下，但对存档这种低频操作足够用了。还有字段改名问题，我吃过一次大亏：上线后为了语义更清晰，把存档里的gold字段改成了playerGold，结果老玩家全部变成0金币，因为反序列化找不到原字段。所以存档字段名一旦对外发布就不要改，真要改就配合版本迁移逻辑，读旧档时先给旧字段赋值到新字段，再递增版本号。

4.4 存档写一半损坏的原子写入细节

前面3.4的代码里已经写了WriteAtomic，这里补充一个更隐蔽的细节：File.Move在同一分区内是原子性比较好的操作，但File.Delete加File.Move之间如果断电，也可能丢掉整个文件。更保险的做法是用File.Replace（Windows下可用）或者自己维护两个轮换文件再配合启动自检。对大多数Unity项目来说，临时文件加Move已经能覆盖99%的情况，但如果你的游戏存档非常值钱，建议写入频率降低，把可靠性放在双槽甚至三槽轮换上去，而不是无限追求单次写入的原子性。

文件损坏的检测也不能只看能不能解析。加密后如果密钥对不上、或者某一位密文被破坏，解密过程可能抛异常，也可能解出来一段奇怪的文本，然后JsonUtility解析失败。所以读取代码一定要包try-catch，并且在出错后不要马上覆盖坏文件，先把它重命名成corrupt_时间戳保存下来，方便后续分析是网络、磁盘还是作弊原因导致的。我实际排查过的一个案例，就是玩家用文件管理器往存档里塞了几行注释，导致解析报错，如果没有保留损坏现场，根本没法判断。

5. 进阶优化：大存档、增量保存与防篡改的朴素套路

5.1 保存时机与频率：不要在Update里写文件

保存频率是持久化设计里另一个容易被忽视的点。最开始的直觉是“数据一变就存”，但战斗中金币每次变动都写文件，哪怕文件只有几KB，也会造成明显的卡顿和耗电，移动端尤其明显。我的习惯是不要实时保存，而是在数据对象上打一个dirty标记，代表需要落盘。每次玩家变化数据只把自己标记为dirty，然后由统一的保存逻辑决定何时真正写文件。通常的落盘节点就是：关卡结束、背包变动后短暂延迟、切换场景前、暂停和退出时。

延迟落盘需要配合“丢失窗口”的取舍：如果玩家改完数据后立刻强杀进程，延迟保存的那一小段时间里数据确实可能没落盘。所以更好的办法是所有关键数值同时往内存里保持一份，并在OnApplicationPause时强制写盘，平时该干啥干啥。移动端切换后台本身就是最危险的时刻，专门处理它，比在Update里频繁写文件更实际。

5.2 增量保存的思想：文件分块，按需重写

当单存档文件开始变得很大，比如包含完整剧情插画、建造记录、几百个NPC状态时，全量序列化整个对象每次都要耗时几十毫秒甚至上百毫秒，玩家会在切场景时感受到卡顿。这时候不要盲目换格式，而是考虑拆文件。我的做法是按域拆分：设置域独立一个文件，金币和进度一个文件，背包和邮件一个文件，互不干扰。每次定时保存只重写有变化的域，没有变化的文件不碰，这样就把单次IO量降下来了。

拆文件之后要额外处理一致性问题：如果两个文件时间不同步，比如进度文件更新了但设置文件没写，启动时怎么合并？最简单的规则是每个文件都带saveTime或者递增写入序号，启动时先读取所有分片，选择最晚的那组做基线，再用各个分片的版本号做合并。这种做法虽然比单文件麻烦，但能支持近乎无限扩张的存档，而且某一分片损坏不会影响其他分片，容错性也好很多。

5.3 防篡改：HMAC签名与密钥现实

前面3.5我用AES举例做加密，但只做加密还不够，因为攻击者仍然可以整体替换一个旧存档，或者用另一个同版本存档覆盖当前进度。更完整的思路是加签名校验。保存时除了密文，再附一个用HMAC-SHA256算出来的摘要；加载时先重新计算摘要，不一致就认为存档被篡改或损坏。HMAC和普通哈希的区别在于它带密钥，没有密钥的人即使能把密文复制过去，也生成不了合法签名。

当然要再次强调，任何纯客户端方案都防不了内存修改和专业的二进制分析。对单机游戏来说，我的建议是不要过度设计：防住“用文本编辑器改存档”这个层次就够了，再往上投入产出比很低。如果你的游戏需要强约束玩家数据，比如竞技类、有排位赛、有交易系统，就必须做服务端校验，把玩家数据的主要副本放到服务器，客户端存档只作为缓存，这时候本地加密反而变成了次要问题。

5.4 存档损坏后的自动恢复：多槽位轮换与最后兜底

存档可靠性最理想的结构是三个槽位轮换加一个“最近一次成功加载”指针。每次保存写slot1，上次保存的slot2自动变成旧一档，slot3再往前推。启动读取时从最新的槽位开始尝试，解析失败就退到更旧的槽位。三槽方案的代价是磁盘占用更大，但能覆盖“写入过程中断电、文件损坏后无法恢复”这一大类灾难。独立小游戏用双槽备份已经够了，大型项目一般三槽起步。

除了技术轮换，UI上的兜底也非常重要。当检测到主存档损坏、自动回退成功时，一定要在启动或开始界面向玩家展示一句提示，比如“检测到存档异常，已为你恢复最近一次正常进度”。不要什么都不说，玩家看到数据少了会以为游戏bug，直接来差评。我在某个项目里就吃过这个亏：自动回退机制运行得很好，玩家进度只丢了一小段，但因为没有任何提示，玩家投诉率反而比丢档的还高。存档逻辑做到最后，拼的不只是技术细节，还有怎么让玩家理解和信任你的这套兜底。

最后再分享一个我最近的体会：存档功能写完之后，先别急着做加密和各种优化，找一个没参与开发的同事，让他把存档文件删掉、改坏、复制粘贴，观察游戏会怎么表现。有一段稳定的兜底逻辑，比写一百行花哨的加密代码更有价值。真正的Unity数据持久化，不是学会某个API就完事，而是你在被真实玩家反复折磨之后，仍然能保证每个人的进度都不被辜负。