C#的序列化技术通过将应用程序中的对象状态转换为一种可持久化（如文件存储）或可传输的格式（如网络传输），从而实现桌面应用数据的保存。当需要时，这些数据可以被反序列化回内存中的对象，让应用恢复到之前的状态。这对于保存用户设置、应用配置、用户生成的数据（比如游戏存档、笔记）等场景至关重要。
解决方案
保存桌面应用数据，我们通常会定义一个或多个数据模型类（POCO，Plain Old CLR Objects），这些类包含了我们需要保存的所有数据。然后，利用C#内置或第三方提供的序列化器，将这些类的实例（即我们应用的状态数据）写入到文件系统。反之，当应用启动或需要加载数据时，再从文件中读取这些数据，通过反序列化操作重新构建内存中的对象。
以一个简单的用户设置为例，我们可能有一个
UserSettings类：
public class UserSettings
{
public string UserName { get; set; }
public bool EnableDarkMode { get; set; }
public int FontSize { get; set; }
public DateTime LastLogin { get; set; } // 示例：DateTime类型
}保存这个对象到文件，通常的流程会是这样：
-
创建
UserSettings类的实例并填充数据。 选择一个序列化器（比如
System.Text.Json或
Newtonsoft.Json）。 打开一个文件流（FileStream），指定保存路径。通常，我们会选择用户应用程序数据目录，比如
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)，这样可以确保有写入权限且数据不会污染系统盘。 调用序列化器的
Serialize方法，将对象写入文件流。 关闭文件流。
加载数据时，流程则反过来：
-
打开之前保存数据的文件流。
调用序列化器的
Deserialize方法，从文件流中读取数据并重建
UserSettings对象。 关闭文件流。
这个过程听起来有点像魔法，但本质上就是把内存中的复杂数据结构，变成了一串文本或二进制数据，方便存储和传输。
C#中常用的序列化技术有哪些，它们各有什么优缺点？
在C#的世界里，序列化技术选项还挺多的，每种都有自己的“脾气”和适用场景。我个人在项目中用得比较多的，主要是XML和JSON相关的序列化。
1. System.Xml.Serialization.XmlSerializer
这是.NET Framework和.NET Core/5+中都内置的XML序列化器。
优点：
人类可读性强： 生成的XML文件内容清晰，有时非开发人员也能看懂或手动修改。 互操作性好： XML作为一种通用数据交换格式，与其他系统或语言交互时非常方便。 适用于配置： 很多时候，应用程序的配置就是用XML来存储的，因为它结构化，易于理解。缺点：
相对冗余： XML标签比较多，文件体积通常比JSON或二进制大。
性能一般： 对于大量数据或频繁的序列化/反序列化操作，性能可能不如JSON或二进制。
限制较多： 被序列化的类需要有公共的无参构造函数，且只能序列化公共属性和字段。处理复杂类型（如字典）有时会比较麻烦。
代码示例：
using System.Xml.Serialization;
using System.IO;
public static void SaveXml(UserSettings settings, string filePath)
{
XmlSerializer serializer = new XmlSerializer(typeof(UserSettings));
using (FileStream stream = new FileStream(filePath, FileMode.Create))
{
serializer.Serialize(stream, settings);
}
}
public static UserSettings LoadXml(string filePath)
{
if (!File.Exists(filePath)) return null;
XmlSerializer serializer = new XmlSerializer(typeof(UserSettings));
using (FileStream stream = new FileStream(filePath, FileMode.Open))
{
return (UserSettings)serializer.Deserialize(stream);
}
}
2. System.Text.Json
(内置于.NET Core/5+，推荐)
这是.NET Core 3.1及更高版本中内置的JSON序列化器，性能优异，是微软官方推荐的现代JSON解决方案。
优点：
轻量高效： JSON格式本身比XML简洁，System.Text.Json的性能也非常好。 易于理解： JSON的语法简洁，同样具有很好的可读性。 现代标准： 在Web API和现代应用中广泛使用，学习成本低。 灵活性： 支持异步操作，可以处理循环引用（通过配置），对复杂类型有较好的支持。
缺点：
相对较新： 在旧的.NET Framework项目中可能需要额外引入。
配置项： 虽然灵活，但有时需要一些配置（如属性命名策略、日期格式）来满足特定需求。
代码示例：
using System.Text.Json;
using System.IO;
public static void SaveJson(UserSettings settings, string filePath)
{
var options = new JsonSerializerOptions { WriteIndented = true }; // 方便阅读
string jsonString = JsonSerializer.Serialize(settings, options);
File.WriteAllText(filePath, jsonString);
}
public static UserSettings LoadJson(string filePath)
{
if (!File.Exists(filePath)) return null;
string jsonString = File.ReadAllText(filePath);
return JsonSerializer.Deserialize<UserSettings>(jsonString);
}
3. Newtonsoft.Json
(第三方库，广泛使用)
这是目前C#社区中最流行、功能最强大的第三方JSON序列化库，几乎是事实标准。
优点：
功能强大： 提供了极其丰富的配置选项和功能，包括自定义转换器、循环引用处理、版本控制、JSON Path查询等。 兼容性好： 可以在各种.NET项目中无缝使用。 社区支持： 庞大的用户群体和活跃的社区，遇到问题很容易找到解决方案。缺点：
第三方依赖： 需要通过NuGet安装，增加了项目依赖。
性能略低于System.Text.Json
： 在某些极端性能场景下，
System.Text.Json可能更快，但对于大多数应用而言，
Newtonsoft.Json的性能已经足够优秀。
代码示例：
using Newtonsoft.Json;
using System.IO;
public static void SaveNewtonsoftJson(UserSettings settings, string filePath)
{
string jsonString = JsonConvert.SerializeObject(settings, Formatting.Indented);
File.WriteAllText(filePath, jsonString);
}
public static UserSettings LoadNewtonsoftJson(string filePath)
{
if (!File.Exists(filePath)) return null;
string jsonString = File.ReadAllText(filePath);
return JsonConvert.DeserializeObject<UserSettings>(jsonString);
}
4. System.Runtime.Serialization.DataContractSerializer
主要用于WCF服务，但也可以用于文件序列化。它允许更精细地控制哪些成员被序列化，即使是私有成员也可以。
[DataContract]和
[DataMember]属性，可以精确控制序列化的成员。 版本容错： 对数据结构的变化有较好的容错性。 缺点： 使用略复杂： 相比
XmlSerializer和JSON序列化，需要更多的属性标记。 生成的XML不如
XmlSerializer友好： XML结构可能更复杂，可读性稍差。
5. System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
这个是将对象序列化为二进制格式。
BinaryFormatter存在严重的反序列化漏洞，当反序列化来自不可信源的数据时，攻击者可以通过构造恶意负载来执行任意代码。微软官方已明确不推荐使用此序列化器，尤其是在处理外部或不可信数据时。 版本兼容性差： 对对象结构的变化非常敏感，一旦类定义发生微小变化，旧数据可能就无法反序列化。 不可读： 生成的二进制文件无法直接阅读或修改。
就我个人经验而言，对于新的桌面应用，我几乎总是倾向于使用
System.Text.Json。如果项目历史悠久，或者有与旧系统兼容的需求，可能会考虑
XmlSerializer。
Newtonsoft.Json依然是处理复杂JSON场景的强大工具，但在.NET 5+项目中，如果
System.Text.Json能满足需求，我更倾向于官方内置方案。
BinaryFormatter？除非你真的知道自己在做什么，并且能完全控制数据源，否则，尽量避开它。
如何选择合适的序列化方式来保存不同类型的应用数据？
选择合适的序列化方式，就像选择合适的工具来完成一项工作，需要考虑数据的特性、应用的需求以及未来的扩展性。这里有一些我个人在做选择时会考量的点：
数据类型与结构复杂性：
简单配置/用户设置： 如果数据结构相对扁平，字段不多，System.Text.Json或
XmlSerializer都很好。JSON更简洁，XML更具自我描述性。我通常会选JSON，因为它更现代、更轻量。 复杂对象图/深度嵌套数据： 比如一个包含多个列表、字典，甚至循环引用的复杂应用状态。
Newtonsoft.Json的强大配置能力在这里会非常有优势，它可以轻松处理循环引用，或者通过自定义转换器来精细控制序列化过程。
System.Text.Json也能做到，但可能需要更多代码。 私有字段或非公共成员： 如果你的数据模型需要序列化私有字段或非公共属性，
BinaryFormatter虽然能做到，但考虑到安全性，这通常不是一个好选择。更好的做法是重构数据模型，或使用
DataContractSerializer配合
[DataMember]标记，或者为
Newtonsoft.Json编写自定义
JsonConverter。
性能与文件大小：
大量数据/频繁读写： 如果你的应用需要保存或加载大量数据（比如几MB甚至几十MB），或者需要频繁进行序列化操作，那么性能和文件大小就变得很重要。JSON通常比XML更紧凑，System.Text.Json在性能上表现出色。二进制格式虽然更小更快，但代价是可读性和安全性。 小规模数据： 对于几KB的配置或设置文件，性能差异几乎可以忽略不计，这时可读性、易用性、兼容性会是更重要的考量。
可读性与手动修改需求：
需要人工编辑： 如果你的配置文件可能需要用户或管理员手动打开、阅读甚至修改（例如，一个游戏的配置文件，玩家可能想手动调整某些参数），那么XML或JSON是最佳选择。它们都是文本格式，用任何文本编辑器都能打开。 无需人工干预： 如果数据只是程序内部使用，不希望被用户随意修改，那么二进制格式理论上也可以，但安全性问题还是需要警惕。互操作性与跨平台：
与其他系统/语言交互： 如果你的桌面应用数据可能需要与其他平台（如Web服务、移动应用）或用其他语言编写的程序进行数据交换，那么JSON或XML是毋庸置疑的首选。它们是业界通用的数据交换格式。安全性考量：
数据来源： 如果你要反序列化的数据可能来自不可信的来源（比如用户上传的文件），那么绝对不要使用BinaryFormatter。它存在严重的反序列化漏洞。即使是JSON或XML，也需要对反序列化后的数据进行严格的验证和沙箱处理，防止注入攻击或其他恶意行为。 数据敏感性： 对于敏感数据（如用户凭证、个人隐私信息），无论选择哪种序列化方式，都应该在序列化前进行加密，并在反序列化后解密。
综合来看，我的通用建议是：优先选择System.Text.Json
或Newtonsoft.Json
。 它们在性能、灵活性、可读性和互操作性之间取得了很好的平衡。只有在有非常特殊的XML兼容性需求时，才考虑
XmlSerializer。而
BinaryFormatter，除非你是一个安全专家并且有非常明确的理由和严格的控制措施，否则请远离它。
序列化过程中可能遇到的常见问题及应对策略？
即便序列化看起来很直接，但在实际开发中，我们还是会遇到一些“小麻烦”。这些问题处理不好，轻则数据丢失，重则应用崩溃。
版本兼容性问题（Schema Evolution）： 这是最常见也最令人头疼的问题之一。当你的应用程序发布了新版本，数据模型类（例如
UserSettings）可能增加了新属性、删除了旧属性、或者改变了某个属性的类型。这时，新版本尝试加载旧版本保存的数据，或者旧版本尝试加载新版本保存的数据，就可能出现问题。 新增属性： JSON：
System.Text.Json和
Newtonsoft.Json通常能很好地处理。新版本加载旧数据时，新增的属性会保持其默认值；旧版本加载新数据时，会忽略新属性。 XML (
XmlSerializer)： 新增属性通常不会导致反序列化失败，它们会被忽略。 策略： 确保新属性有合理的默认值，或在反序列化后进行检查和初始化。 删除属性： JSON/XML： 加载旧数据时，删除的属性会简单地被忽略。 策略： 确保删除的属性不再是应用运行所必需的。如果旧数据中存在这些属性，它们会被丢弃。 修改属性类型或重命名属性： JSON/XML： 这通常会导致反序列化失败或数据丢失。例如，将
int改为
string。 策略：
Newtonsoft.Json： 可以使用
[JsonProperty("oldName")]来映射旧的属性名，或编写自定义JsonConverter来处理类型转换。 数据迁移： 在应用启动时，检测数据版本。如果发现是旧版本数据，先加载到临时对象，然后手动将其迁移到新版本的数据模型，再保存。这虽然麻烦，但最稳妥。 保持向后兼容： 尽量避免修改现有属性的类型，如果必须修改，考虑新增一个属性，并逐步淘汰旧属性。
循环引用问题： 当你的对象图中有A引用B，B又引用A的情况时，序列化器可能会陷入无限循环，最终导致栈溢出。
场景： 比如一个Order对象引用
Customer，而
Customer对象又包含一个
List<Order>。 策略：
Newtonsoft.Json： 提供了
ReferenceLoopHandling.Serialize（尝试序列化引用）、
ReferenceLoopHandling.Ignore（忽略循环引用，可能导致数据不完整）或
ReferenceLoopHandling.Error（抛出错误）。通常设置为
Ignore是一个简单的解决方案，但要确保忽略的引用不会导致数据逻辑错误。
System.Text.Json： 默认会抛出异常。你可以通过
JsonSerializerOptions设置
ReferenceHandler = ReferenceHandler.Preserve来处理循环引用，它会使用JSON
$id和
$ref机制。 重构对象模型： 最根本的解决办法是重新设计对象模型，打破循环引用。例如，
Customer对象只存储
Order的ID列表，而不是直接引用
Order对象。
性能瓶颈： 对于非常大的对象图或需要频繁进行序列化/反序列化操作的场景，性能可能会成为问题。
策略： 选择高效的序列化器：System.Text.Json通常比
XmlSerializer更快。 异步操作： 对于大型文件的读写，使用异步文件I/O (
File.WriteAllTextAsync,
File.ReadAllTextAsync)，可以避免阻塞UI线程，提升用户体验。 分块序列化： 如果数据量巨大，考虑将数据拆分成多个小块分别序列化和保存，或者使用流式序列化（例如
System.Text.Json的
JsonSerializer.SerializeAsync）。 只序列化必要数据： 检查你的数据模型，是否包含了不必要的、可以运行时计算或从其他地方获取的数据。减少序列化的数据量。
安全性问题（特别针对BinaryFormatter
）：
前面已经强调过，
BinaryFormatter的反序列化漏洞是一个严重的安全隐患。 策略： 避免使用
BinaryFormatter： 这是最直接有效的策略。 数据验证与沙箱： 如果确实无法避免使用，必须对反序列化的数据进行严格的验证。考虑在独立的、受限的进程或沙箱环境中进行反序列化，以限制潜在的恶意代码执行范围。
文件路径与权限问题： 桌面应用保存数据时，经常会遇到文件路径不存在或没有写入权限的问题。
策略： 使用标准路径： 始终将用户数据保存到操作系统推荐的特殊文件夹，如Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)（漫游数据，如设置）、
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)（本地数据，如缓存）或
Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments)（用户文档）。这些路径通常具有用户写入权限。 **创建目录
