1. 从一次线上故障说起为什么序列化/反序列化不只是“调个方法”上周我们一个核心服务的日志监控突然告警错误率飙升。紧急排查后发现问题出在一个看似简单的场景一个下游服务返回的JSON数据里某个字段的值从预期的数字100变成了字符串100。我们的C#服务用JsonConvert.DeserializeObjectT去反序列化一个int类型的属性直接抛出了JsonSerializationException导致整个处理链路中断。这让我重新审视了JsonConvert.SerializeObject和DeserializeObject这对“老朋友”。很多开发者包括曾经的我都认为它们就是两个简单的工具方法传个对象进去或者传个字符串出来能跑通就行。但这次故障狠狠地教育了我在分布式系统、前后端交互、API设计里序列化和反序列化是数据流动的“咽喉要道”这里的任何一个细微约定不一致都可能引发连锁反应。JsonConvert来自 Newtonsoft.Json也就是 Json.NET尽管 .NET Core 之后官方推出了System.Text.Json但 Json.NET 因其极高的灵活性、丰富的功能和广泛的生态依然是大量存量项目和复杂场景的首选。今天我们就抛开“基本用法”深入JsonConvert的腹腔看看在“能跑”之外我们还需要关注什么。我会结合大量实际踩坑案例聊聊如何通过配置和策略让序列化/反序列化既健壮又高效真正为你的应用保驾护航而不是埋雷。2. 核心配置驯服记JsonSerializerSettings的实战兵法JsonConvert的默认行为在大多数简单场景下是够用的但一旦涉及复杂对象、特殊类型如日期、枚举或者需要与外部系统如JavaScript前端、Java后端交互默认行为往往就成了问题的根源。这时我们必须请出JsonSerializerSettings这个“配置中枢”。它不是一堆枯燥的开关而是一套应对各种边界情况的战术手册。2.1 日期与时间格式跨时区协作的生死线日期时间处理是序列化中最常见的坑之一。.NET的DateTime默认序列化为一个复杂的ISO格式字符串例如2023-10-27T14:30:00.123456708:00。这个格式虽然精确但可能不被其他语言尤其是旧系统的JSON库识别。var order new { Id 1, CreatedTime DateTime.Now }; var json JsonConvert.SerializeObject(order); // 输出可能类似{Id:1,CreatedTime:2023-10-27T14:30:00.123456708:00}问题场景你的C#服务需要和一个只接受Unix时间戳毫秒数的第三方支付网关通信。解决方案使用DateFormatHandling和DateTimeZoneHandling。var settings new JsonSerializerSettings { // 将日期格式化为微软的旧式 JSON 日期格式如 \/Date(16983954000000800)\/ // DateFormatHandling DateFormatHandling.MicrosoftDateFormat, // 更常见的使用自定义格式字符串 DateFormatString yyyy-MM-dd HH:mm:ss, // 关键处理时区信息。默认是 RoundtripKind保留Kind属性但跨系统时常用 Utc 或 Local DateTimeZoneHandling DateTimeZoneHandling.Utc, // 将所有日期时间转换为UTC再序列化 }; var json JsonConvert.SerializeObject(order, settings); // 输出{Id:1,CreatedTime:2023-10-27 06:30:00} (假设本地是8时区转换成了UTC时间)注意DateTimeZoneHandling.Utc非常有用它能保证序列化后的时间字符串是统一的UTC标准避免了因服务器时区不同导致的时间错乱。在反序列化时配合同样的设置可以正确还原。对于只认时间戳的API你可能需要完全自定义一个JsonConverter将DateTime直接转换为long。2.2 空值处理让JSON结构更清晰可控默认情况下JsonConvert会序列化所有属性包括值为null的。这可能导致生成的JSON体积膨胀并且让前端开发者困惑。var person new { Name 张三, Age (int?)null, Address (string)null }; var json JsonConvert.SerializeObject(person); // 输出{Name:张三,Age:null,Address:null}解决方案使用NullValueHandling。var settings new JsonSerializerSettings { NullValueHandling NullValueHandling.Ignore // 忽略值为null的属性 }; var json JsonConvert.SerializeObject(person, settings); // 输出{Name:张三}这个配置在构建API响应时特别有用可以精简数据量。但要注意反序列化时如果JSON中缺少某个属性对应属性会被设置为默认值如null、0而不会报错。这要求你的业务逻辑能妥善处理默认值。2.3 默认值处理区分“未提供”和“就是零”与空值相关的是默认值。一个int类型的属性如果值是0这到底是用户明确设置的0还是字段的默认值、用户根本没传默认序列化会输出这个0。var product new { Id 1, Stock 0, IsActive false }; var json JsonConvert.SerializeObject(product); // 输出{Id:1,Stock:0,IsActive:false}如果你希望忽略那些等于类型默认值的属性例如int的0bool的false可以使用DefaultValueHandling。var settings new JsonSerializerSettings { DefaultValueHandling DefaultValueHandling.Ignore // 忽略等于默认值的属性 }; var json JsonConvert.SerializeObject(product, settings); // 输出{Id:1}实操心得NullValueHandling.Ignore和DefaultValueHandling.Ignore经常结合使用用于构建最精简的API响应或存储文档。但在接收外部数据反序列化时要极其谨慎。忽略反序列化的默认值DefaultValueHandling.IgnoreAndPopulate的某些用法可能导致数据丢失我建议在反序列化端保持默认行为除非有非常明确的目的。2.4 循环引用对象“我中有我”的死锁困局这是面向对象模型序列化时的一个经典问题。例如在订单系统中Order对象有一个Customer属性而Customer对象又有一个Orders列表属性指向其所有订单。public class Order { public int Id; public Customer Customer; } public class Customer { public int Id; public ListOrder Orders; } var customer new Customer { Id 1 }; var order new Order { Id 101, Customer customer }; customer.Orders new ListOrder { order }; // 形成循环引用 // 直接序列化会抛出 JsonSerializationException // var json JsonConvert.SerializeObject(customer); // 错误解决方案JsonSerializerSettings.ReferenceLoopHandlingvar settings new JsonSerializerSettings { ReferenceLoopHandling ReferenceLoopHandling.Ignore // 遇到循环引用时忽略该成员 // 或者使用 Serialize它会用 $id 和 $ref 来标记对象引用 // ReferenceLoopHandling ReferenceLoopHandling.Serialize }; var json JsonConvert.SerializeObject(customer, settings); // 使用 Ignore 时输出中可能没有 Orders 属性或者 Orders 列表为空避免了无限循环。更佳实践对于Web API我强烈建议使用DTO数据传输对象来扁平化你的领域模型从根本上避免将带有循环引用的领域模型直接序列化返回给前端。DTO只包含前端需要的数据比如OrderDto里只放CustomerId而不是整个Customer对象。3. 类型转换与自定义解析当标准套路不够用时开篇提到的字符串数字反序列化失败就是类型转换的典型问题。JsonConvert内置了大多数基本类型的转换但面对非标准格式或复杂逻辑时我们需要更强大的武器JsonConverter。3.1 内置的灵活转换StringEnumConverter与数字字符串枚举处理默认情况下枚举被序列化为其数字值。这不利于可读性和前端使用。public enum OrderStatus { Pending, Processing, Shipped, Completed } var order new { Id 1, Status OrderStatus.Processing }; var json JsonConvert.SerializeObject(order); // 输出{Id:1,Status:1} // 可读性差使用StringEnumConverter可以将其转换为字符串名称。var settings new JsonSerializerSettings { Converters new ListJsonConverter { new StringEnumConverter() } }; var json JsonConvert.SerializeObject(order, settings); // 输出{Id:1,Status:Processing} // 清晰明了数字字符串转换对于开篇那个100的问题除了让上游修正数据我们也可以在反序列化端增加容错。Json.NET 默认不支持将数字字符串直接反序列化为int但我们可以通过配置FloatParseHandling等属性来影响数字解析不过最直接的还是用JsonConverter。3.2 编写自定义JsonConverter解决特定疑难杂症当内置转换器无法满足需求时自定义JsonConverter是终极解决方案。我们需要继承JsonConverter类并重写三个方法CanConvert、WriteJson序列化、ReadJson反序列化。案例处理不稳定的第三方API返回的“数字或字符串”类型字段假设一个天气API返回的temperature字段正常时是数字25但出错时可能是字符串N/A。我们希望反序列化时如果是数字就赋值如果是N/A就赋值为null。首先定义一个可空的模型public class WeatherData { public double? Temperature { get; set; } }然后编写一个针对double?类型的转换器public class TolerantDoubleConverter : JsonConverter { public override bool CanConvert(Type objectType) { // 这个转换器只处理 double? 类型 return objectType typeof(double?); } public override object ReadJson(JsonReader reader, Type objectType, object existingValue, JsonSerializer serializer) { // reader.TokenType 表示当前读取到的JSON令牌类型 switch (reader.TokenType) { case JsonToken.Integer: // JSON数字整数 case JsonToken.Float: // JSON数字浮点数 return Convert.ToDouble(reader.Value); // 安全转换为double case JsonToken.String: // JSON字符串 string strValue (string)reader.Value; if (double.TryParse(strValue, out double result)) { return result; // 字符串能解析为数字 } // 如果是 N/A 或其他非数字字符串返回 null return null; case JsonToken.Null: // JSON的null return null; default: // 对于其他意外类型可以抛出更友好的异常或者返回null throw new JsonSerializationException($无法将 {reader.TokenType} 转换为 double?。); } } public override void WriteJson(JsonWriter writer, object value, JsonSerializer serializer) { // 序列化逻辑如果是null就写null否则直接写数字值 if (value null) { writer.WriteNull(); } else { writer.WriteValue(Convert.ToDouble(value)); } } }使用自定义转换器var settings new JsonSerializerSettings(); settings.Converters.Add(new TolerantDoubleConverter()); string json1 {\Temperature\: 25}; string json2 {\Temperature\: \N/A\}; string json3 {\Temperature\: \30.5\}; var data1 JsonConvert.DeserializeObjectWeatherData(json1, settings); Console.WriteLine(data1.Temperature); // 输出25 var data2 JsonConvert.DeserializeObjectWeatherData(json2, settings); Console.WriteLine(data2.Temperature null); // 输出True var data3 JsonConvert.DeserializeObjectWeatherData(json3, settings); Console.WriteLine(data3.Temperature); // 输出30.5通过这个自定义转换器我们优雅地处理了数据格式不一致的问题使反序列化过程更加健壮。你可以将类似的逻辑应用于int?、DateTime?等类型。实操心得编写JsonConverter时务必仔细处理ReadJson方法中的所有可能的JsonTokenType特别是Null、Integer、Float、String、Boolean等。考虑周全才能避免意外异常。另外CanConvert方法要精确避免影响其他类型的序列化。4. 性能调优与最佳实践在大规模数据面前保持优雅当序列化/反序列化的对象数量巨大、频率很高时例如日志处理、消息队列、缓存存储性能就成为一个不可忽视的因素。4.1 重用JsonSerializerSettings和JsonSerializer创建JsonSerializerSettings和底层的JsonSerializer是有开销的。最直接的优化就是在全局或作用域内重用它们。// 错误示范每次调用都new一个settings public string ToJsonBad(Object obj) { var settings new JsonSerializerSettings { NullValueHandling NullValueHandling.Ignore }; return JsonConvert.SerializeObject(obj, settings); // 每次创建settings实例 } // 正确示范静态或单例重用 public static class JsonHelper { private static readonly JsonSerializerSettings _defaultSettings new JsonSerializerSettings { NullValueHandling NullValueHandling.Ignore, DateFormatHandling DateFormatHandling.IsoDateFormat, // ... 其他全局配置 }; public static string Serialize(object obj) { return JsonConvert.SerializeObject(obj, _defaultSettings); } public static T DeserializeT(string json) { return JsonConvert.DeserializeObjectT(json, _defaultSettings); } }对于更极致的性能场景可以直接创建并重用JsonSerializer实例private static readonly JsonSerializer _serializer JsonSerializer.CreateDefault(); // 或者使用自定义配置创建 // private static readonly JsonSerializer _serializer JsonSerializer.Create(_defaultSettings); public static string SerializeFast(object obj) { using (var sw new StringWriter()) using (var jw new JsonTextWriter(sw)) { _serializer.Serialize(jw, obj); return sw.ToString(); } }4.2 使用流式API处理超大JSONJsonConvert.SerializeObject和DeserializeObject需要将整个JSON字符串加载到内存中。对于几百MB甚至GB级别的JSON文件这会瞬间导致内存溢出OOM。此时应该使用Json.NET提供的流式APIJsonTextReader/JsonTextWriter它们允许你按令牌Token逐个读取或写入内存占用极小。示例流式读取一个超大JSON数组文件并处理其中的每个对象假设有一个巨大的data.json文件内容是一个包含数百万个对象的数组[...]。using (var fileStream File.OpenRead(huge_data.json)) using (var streamReader new StreamReader(fileStream)) using (var jsonReader new JsonTextReader(streamReader)) { var serializer new JsonSerializer(); // 读取开始数组令牌 [ jsonReader.Read(); while (jsonReader.Read()) { if (jsonReader.TokenType JsonToken.StartObject) { // 读取到一个对象开始 {反序列化单个对象 var item serializer.DeserializeMyDataModel(jsonReader); // 处理这个item例如存入数据库或进行过滤 ProcessItem(item); } // 当读到结束数组令牌 ] 时循环结束 if (jsonReader.TokenType JsonToken.EndArray) { break; } } }这种方式只会将当前正在处理的一个对象加载到内存中完美解决了大文件处理问题。写入亦然可以使用JsonTextWriter逐步构建巨大的JSON输出。4.3 合约解析与属性控制精细化管理序列化行为除了全局的JsonSerializerSettings你还可以通过特性Attribute在模型类上精细控制每个属性的序列化行为。[JsonProperty]最常用的特性可以指定JSON属性名、顺序、是否必须等。public class Product { [JsonProperty(product_id)] // 序列化后字段名为 product_id public int Id { get; set; } [JsonProperty(Order -1)] // 让Name属性在JSON中最先出现 public string Name { get; set; } [JsonProperty(Required Required.Always)] // 反序列化时此属性必须存在 public decimal Price { get; set; } [JsonIgnore] // 完全忽略此属性不序列化也不反序列化 public string InternalCode { get; set; } }[JsonIgnore]忽略属性。[JsonConverter(typeof(...))]为特定属性指定自定义转换器优先级高于全局设置。最佳实践建议为API模型显式使用[JsonProperty]这确保了即使你重命名了C#属性序列化后的JSON字段名也不会意外改变保持了API的稳定性。这也是API版本管理的一部分。谨慎使用Required设为Required.Always可以在反序列化时提供早期验证但也要考虑向后兼容性有时Required.Default默认或Required.AllowNull更合适。区分领域模型和DTO不要在你的领域实体Entity上滥用Json.NET特性。这些特性属于基础设施层。应该为不同的应用场景如Web API、消息队列创建专门的DTO并在DTO上应用这些序列化特性。5. 错误处理与调试如何快速定位序列化问题即使配置周全序列化错误仍可能发生。良好的错误处理和调试技巧能帮你快速定位问题。5.1 捕获并分析JsonSerializationException当DeserializeObject失败时会抛出JsonSerializationException。这个异常对象包含了宝贵的信息。try { var obj JsonConvert.DeserializeObjectMyClass(jsonString); } catch (JsonSerializationException ex) { Console.WriteLine($反序列化失败: {ex.Message}); // ex.Path 属性告诉你错误发生在JSON路径的哪个位置 // 例如Error converting value \N/A\ to type System.Int32. Path temperature, line 3, position 25. Console.WriteLine($JSON路径: {ex.Path}); Console.WriteLine($行号: {ex.LineNumber}); Console.WriteLine($位置: {ex.LinePosition}); }ex.Path尤其有用它能直接指引你到出问题的JSON字段。5.2 使用JsonSerializerSettings.Error事件进行容错处理有时你希望遇到个别错误时不要整个反序列化失败而是记录错误并继续处理其他数据。这可以通过订阅Error事件来实现。var settings new JsonSerializerSettings { Error (sender, args) { // args.ErrorContext.Error 包含了具体的异常 Console.WriteLine($处理 {args.ErrorContext.Path} 时出错: {args.ErrorContext.Error.Message}); // 标记此错误已处理反序列化将继续进行 args.ErrorContext.Handled true; // 你可以在这里选择给出错的属性一个默认值 // 例如如果目标是 MyClass 的某个属性 if (args.ErrorContext.OriginalObject is MyClass myObj) { // 根据Path判断是哪个属性出错并赋值 } } }; var result JsonConvert.DeserializeObjectMyClass(problematicJson, settings); // 即使JSON中有格式错误result也不会是null除非整个JSON无效出错的属性会是默认值。这个机制非常适合处理“脏数据”比如从老旧系统或用户输入中获取的不完全规范的JSON。5.3 序列化跟踪与诊断对于复杂的对象有时你只是想看看JsonConvert到底是如何处理它的。除了调试你还可以使用JsonConvert.SerializeObject的重载版本配合JsonSerializer进行更细致的控制或者在自定义转换器内部加入日志。一个简单的诊断方法是序列化成格式化的JSON便于肉眼观察结构var formattedJson JsonConvert.SerializeObject(myObject, Formatting.Indented); Console.WriteLine(formattedJson);对于性能分析可以使用Stopwatch来测量序列化/反序列化大量数据所花费的时间从而定位瓶颈。6. 与System.Text.Json的简要对比与迁移考量自 .NET Core 3.0 起微软推出了内置的System.Text.Json命名空间。它设计目标就是高性能和低内存分配在大多数基准测试中其性能显著优于 Json.NET。主要差异点性能System.Text.Json默认更快内存开销更小。特性丰富度Json.NET 的功能如JsonConverter的灵活性、Error事件、JsonPath支持等目前仍然更丰富。API差异两者API相似但不兼容。例如配置方式不同JsonSerializerOptionsvsJsonSerializerSettings特性也不同[JsonPropertyName]vs[JsonProperty]。默认行为例如System.Text.Json默认属性名采用小写驼峰可配置而 Json.NET 默认保持原样。System.Text.Json对循环引用的处理更严格默认抛出异常。迁移建议新项目如果项目从 .NET Core 3.0 开始且没有特殊复杂的序列化需求如需要大量自定义转换器、处理多态类型优先考虑System.Text.Json。存量项目如果项目严重依赖 Json.NET 的高级特性或者是一个大型代码库不建议盲目迁移。迁移成本可能很高且收益主要体现在高性能场景。可以尝试在新模块或性能关键路径上逐步试用System.Text.Json。混合使用两者可以在同一个项目中并存只需注意引用不同的命名空间即可。但这会增加团队的认知负担。一个快速示例对比// 使用 System.Text.Json 序列化 using System.Text.Json; var options new JsonSerializerOptions { WriteIndented true, PropertyNamingPolicy JsonNamingPolicy.CamelCase }; string json JsonSerializer.Serialize(myObject, options); // 使用 Json.NET 序列化 using Newtonsoft.Json; string json JsonConvert.SerializeObject(myObject, Formatting.Indented);最终选择哪个取决于你的项目具体需求、团队熟悉度和性能要求。对于绝大多数业务应用Json.NET 的成熟度和功能完备性依然是巨大的优势。而对于高性能网络服务、频繁序列化大量数据的场景System.Text.Json是更面向未来的选择。回顾这次线上故障根本原因是我们对数据契约的边界情况考虑不足。序列化和反序列化远不止是简单的函数调用它是系统间、层与层之间数据契约的强制执行者。通过深入理解JsonSerializerSettings、善用JsonConverter、遵循性能最佳实践并建立有效的错误处理机制我们可以将这个潜在的故障点转变为保障系统数据流动稳定可靠的坚实桥梁。在下次调用JsonConvert时不妨多花几分钟思考一下数据的来源是否可靠格式是否可能变化我的配置是否能优雅地应对这些变化
1. 从一次线上故障说起为什么序列化/反序列化不只是“调个方法”上周我们一个核心服务的日志监控突然告警错误率飙升。紧急排查后发现问题出在一个看似简单的场景一个下游服务返回的JSON数据里某个字段的值从预期的数字100变成了字符串100。我们的C#服务用JsonConvert.DeserializeObjectT去反序列化一个int类型的属性直接抛出了JsonSerializationException导致整个处理链路中断。这让我重新审视了JsonConvert.SerializeObject和DeserializeObject这对“老朋友”。很多开发者包括曾经的我都认为它们就是两个简单的工具方法传个对象进去或者传个字符串出来能跑通就行。但这次故障狠狠地教育了我在分布式系统、前后端交互、API设计里序列化和反序列化是数据流动的“咽喉要道”这里的任何一个细微约定不一致都可能引发连锁反应。JsonConvert来自 Newtonsoft.Json也就是 Json.NET尽管 .NET Core 之后官方推出了System.Text.Json但 Json.NET 因其极高的灵活性、丰富的功能和广泛的生态依然是大量存量项目和复杂场景的首选。今天我们就抛开“基本用法”深入JsonConvert的腹腔看看在“能跑”之外我们还需要关注什么。我会结合大量实际踩坑案例聊聊如何通过配置和策略让序列化/反序列化既健壮又高效真正为你的应用保驾护航而不是埋雷。2. 核心配置驯服记JsonSerializerSettings的实战兵法JsonConvert的默认行为在大多数简单场景下是够用的但一旦涉及复杂对象、特殊类型如日期、枚举或者需要与外部系统如JavaScript前端、Java后端交互默认行为往往就成了问题的根源。这时我们必须请出JsonSerializerSettings这个“配置中枢”。它不是一堆枯燥的开关而是一套应对各种边界情况的战术手册。2.1 日期与时间格式跨时区协作的生死线日期时间处理是序列化中最常见的坑之一。.NET的DateTime默认序列化为一个复杂的ISO格式字符串例如2023-10-27T14:30:00.123456708:00。这个格式虽然精确但可能不被其他语言尤其是旧系统的JSON库识别。var order new { Id 1, CreatedTime DateTime.Now }; var json JsonConvert.SerializeObject(order); // 输出可能类似{Id:1,CreatedTime:2023-10-27T14:30:00.123456708:00}问题场景你的C#服务需要和一个只接受Unix时间戳毫秒数的第三方支付网关通信。解决方案使用DateFormatHandling和DateTimeZoneHandling。var settings new JsonSerializerSettings { // 将日期格式化为微软的旧式 JSON 日期格式如 \/Date(16983954000000800)\/ // DateFormatHandling DateFormatHandling.MicrosoftDateFormat, // 更常见的使用自定义格式字符串 DateFormatString yyyy-MM-dd HH:mm:ss, // 关键处理时区信息。默认是 RoundtripKind保留Kind属性但跨系统时常用 Utc 或 Local DateTimeZoneHandling DateTimeZoneHandling.Utc, // 将所有日期时间转换为UTC再序列化 }; var json JsonConvert.SerializeObject(order, settings); // 输出{Id:1,CreatedTime:2023-10-27 06:30:00} (假设本地是8时区转换成了UTC时间)注意DateTimeZoneHandling.Utc非常有用它能保证序列化后的时间字符串是统一的UTC标准避免了因服务器时区不同导致的时间错乱。在反序列化时配合同样的设置可以正确还原。对于只认时间戳的API你可能需要完全自定义一个JsonConverter将DateTime直接转换为long。2.2 空值处理让JSON结构更清晰可控默认情况下JsonConvert会序列化所有属性包括值为null的。这可能导致生成的JSON体积膨胀并且让前端开发者困惑。var person new { Name 张三, Age (int?)null, Address (string)null }; var json JsonConvert.SerializeObject(person); // 输出{Name:张三,Age:null,Address:null}解决方案使用NullValueHandling。var settings new JsonSerializerSettings { NullValueHandling NullValueHandling.Ignore // 忽略值为null的属性 }; var json JsonConvert.SerializeObject(person, settings); // 输出{Name:张三}这个配置在构建API响应时特别有用可以精简数据量。但要注意反序列化时如果JSON中缺少某个属性对应属性会被设置为默认值如null、0而不会报错。这要求你的业务逻辑能妥善处理默认值。2.3 默认值处理区分“未提供”和“就是零”与空值相关的是默认值。一个int类型的属性如果值是0这到底是用户明确设置的0还是字段的默认值、用户根本没传默认序列化会输出这个0。var product new { Id 1, Stock 0, IsActive false }; var json JsonConvert.SerializeObject(product); // 输出{Id:1,Stock:0,IsActive:false}如果你希望忽略那些等于类型默认值的属性例如int的0bool的false可以使用DefaultValueHandling。var settings new JsonSerializerSettings { DefaultValueHandling DefaultValueHandling.Ignore // 忽略等于默认值的属性 }; var json JsonConvert.SerializeObject(product, settings); // 输出{Id:1}实操心得NullValueHandling.Ignore和DefaultValueHandling.Ignore经常结合使用用于构建最精简的API响应或存储文档。但在接收外部数据反序列化时要极其谨慎。忽略反序列化的默认值DefaultValueHandling.IgnoreAndPopulate的某些用法可能导致数据丢失我建议在反序列化端保持默认行为除非有非常明确的目的。2.4 循环引用对象“我中有我”的死锁困局这是面向对象模型序列化时的一个经典问题。例如在订单系统中Order对象有一个Customer属性而Customer对象又有一个Orders列表属性指向其所有订单。public class Order { public int Id; public Customer Customer; } public class Customer { public int Id; public ListOrder Orders; } var customer new Customer { Id 1 }; var order new Order { Id 101, Customer customer }; customer.Orders new ListOrder { order }; // 形成循环引用 // 直接序列化会抛出 JsonSerializationException // var json JsonConvert.SerializeObject(customer); // 错误解决方案JsonSerializerSettings.ReferenceLoopHandlingvar settings new JsonSerializerSettings { ReferenceLoopHandling ReferenceLoopHandling.Ignore // 遇到循环引用时忽略该成员 // 或者使用 Serialize它会用 $id 和 $ref 来标记对象引用 // ReferenceLoopHandling ReferenceLoopHandling.Serialize }; var json JsonConvert.SerializeObject(customer, settings); // 使用 Ignore 时输出中可能没有 Orders 属性或者 Orders 列表为空避免了无限循环。更佳实践对于Web API我强烈建议使用DTO数据传输对象来扁平化你的领域模型从根本上避免将带有循环引用的领域模型直接序列化返回给前端。DTO只包含前端需要的数据比如OrderDto里只放CustomerId而不是整个Customer对象。3. 类型转换与自定义解析当标准套路不够用时开篇提到的字符串数字反序列化失败就是类型转换的典型问题。JsonConvert内置了大多数基本类型的转换但面对非标准格式或复杂逻辑时我们需要更强大的武器JsonConverter。3.1 内置的灵活转换StringEnumConverter与数字字符串枚举处理默认情况下枚举被序列化为其数字值。这不利于可读性和前端使用。public enum OrderStatus { Pending, Processing, Shipped, Completed } var order new { Id 1, Status OrderStatus.Processing }; var json JsonConvert.SerializeObject(order); // 输出{Id:1,Status:1} // 可读性差使用StringEnumConverter可以将其转换为字符串名称。var settings new JsonSerializerSettings { Converters new ListJsonConverter { new StringEnumConverter() } }; var json JsonConvert.SerializeObject(order, settings); // 输出{Id:1,Status:Processing} // 清晰明了数字字符串转换对于开篇那个100的问题除了让上游修正数据我们也可以在反序列化端增加容错。Json.NET 默认不支持将数字字符串直接反序列化为int但我们可以通过配置FloatParseHandling等属性来影响数字解析不过最直接的还是用JsonConverter。3.2 编写自定义JsonConverter解决特定疑难杂症当内置转换器无法满足需求时自定义JsonConverter是终极解决方案。我们需要继承JsonConverter类并重写三个方法CanConvert、WriteJson序列化、ReadJson反序列化。案例处理不稳定的第三方API返回的“数字或字符串”类型字段假设一个天气API返回的temperature字段正常时是数字25但出错时可能是字符串N/A。我们希望反序列化时如果是数字就赋值如果是N/A就赋值为null。首先定义一个可空的模型public class WeatherData { public double? Temperature { get; set; } }然后编写一个针对double?类型的转换器public class TolerantDoubleConverter : JsonConverter { public override bool CanConvert(Type objectType) { // 这个转换器只处理 double? 类型 return objectType typeof(double?); } public override object ReadJson(JsonReader reader, Type objectType, object existingValue, JsonSerializer serializer) { // reader.TokenType 表示当前读取到的JSON令牌类型 switch (reader.TokenType) { case JsonToken.Integer: // JSON数字整数 case JsonToken.Float: // JSON数字浮点数 return Convert.ToDouble(reader.Value); // 安全转换为double case JsonToken.String: // JSON字符串 string strValue (string)reader.Value; if (double.TryParse(strValue, out double result)) { return result; // 字符串能解析为数字 } // 如果是 N/A 或其他非数字字符串返回 null return null; case JsonToken.Null: // JSON的null return null; default: // 对于其他意外类型可以抛出更友好的异常或者返回null throw new JsonSerializationException($无法将 {reader.TokenType} 转换为 double?。); } } public override void WriteJson(JsonWriter writer, object value, JsonSerializer serializer) { // 序列化逻辑如果是null就写null否则直接写数字值 if (value null) { writer.WriteNull(); } else { writer.WriteValue(Convert.ToDouble(value)); } } }使用自定义转换器var settings new JsonSerializerSettings(); settings.Converters.Add(new TolerantDoubleConverter()); string json1 {\Temperature\: 25}; string json2 {\Temperature\: \N/A\}; string json3 {\Temperature\: \30.5\}; var data1 JsonConvert.DeserializeObjectWeatherData(json1, settings); Console.WriteLine(data1.Temperature); // 输出25 var data2 JsonConvert.DeserializeObjectWeatherData(json2, settings); Console.WriteLine(data2.Temperature null); // 输出True var data3 JsonConvert.DeserializeObjectWeatherData(json3, settings); Console.WriteLine(data3.Temperature); // 输出30.5通过这个自定义转换器我们优雅地处理了数据格式不一致的问题使反序列化过程更加健壮。你可以将类似的逻辑应用于int?、DateTime?等类型。实操心得编写JsonConverter时务必仔细处理ReadJson方法中的所有可能的JsonTokenType特别是Null、Integer、Float、String、Boolean等。考虑周全才能避免意外异常。另外CanConvert方法要精确避免影响其他类型的序列化。4. 性能调优与最佳实践在大规模数据面前保持优雅当序列化/反序列化的对象数量巨大、频率很高时例如日志处理、消息队列、缓存存储性能就成为一个不可忽视的因素。4.1 重用JsonSerializerSettings和JsonSerializer创建JsonSerializerSettings和底层的JsonSerializer是有开销的。最直接的优化就是在全局或作用域内重用它们。// 错误示范每次调用都new一个settings public string ToJsonBad(Object obj) { var settings new JsonSerializerSettings { NullValueHandling NullValueHandling.Ignore }; return JsonConvert.SerializeObject(obj, settings); // 每次创建settings实例 } // 正确示范静态或单例重用 public static class JsonHelper { private static readonly JsonSerializerSettings _defaultSettings new JsonSerializerSettings { NullValueHandling NullValueHandling.Ignore, DateFormatHandling DateFormatHandling.IsoDateFormat, // ... 其他全局配置 }; public static string Serialize(object obj) { return JsonConvert.SerializeObject(obj, _defaultSettings); } public static T DeserializeT(string json) { return JsonConvert.DeserializeObjectT(json, _defaultSettings); } }对于更极致的性能场景可以直接创建并重用JsonSerializer实例private static readonly JsonSerializer _serializer JsonSerializer.CreateDefault(); // 或者使用自定义配置创建 // private static readonly JsonSerializer _serializer JsonSerializer.Create(_defaultSettings); public static string SerializeFast(object obj) { using (var sw new StringWriter()) using (var jw new JsonTextWriter(sw)) { _serializer.Serialize(jw, obj); return sw.ToString(); } }4.2 使用流式API处理超大JSONJsonConvert.SerializeObject和DeserializeObject需要将整个JSON字符串加载到内存中。对于几百MB甚至GB级别的JSON文件这会瞬间导致内存溢出OOM。此时应该使用Json.NET提供的流式APIJsonTextReader/JsonTextWriter它们允许你按令牌Token逐个读取或写入内存占用极小。示例流式读取一个超大JSON数组文件并处理其中的每个对象假设有一个巨大的data.json文件内容是一个包含数百万个对象的数组[...]。using (var fileStream File.OpenRead(huge_data.json)) using (var streamReader new StreamReader(fileStream)) using (var jsonReader new JsonTextReader(streamReader)) { var serializer new JsonSerializer(); // 读取开始数组令牌 [ jsonReader.Read(); while (jsonReader.Read()) { if (jsonReader.TokenType JsonToken.StartObject) { // 读取到一个对象开始 {反序列化单个对象 var item serializer.DeserializeMyDataModel(jsonReader); // 处理这个item例如存入数据库或进行过滤 ProcessItem(item); } // 当读到结束数组令牌 ] 时循环结束 if (jsonReader.TokenType JsonToken.EndArray) { break; } } }这种方式只会将当前正在处理的一个对象加载到内存中完美解决了大文件处理问题。写入亦然可以使用JsonTextWriter逐步构建巨大的JSON输出。4.3 合约解析与属性控制精细化管理序列化行为除了全局的JsonSerializerSettings你还可以通过特性Attribute在模型类上精细控制每个属性的序列化行为。[JsonProperty]最常用的特性可以指定JSON属性名、顺序、是否必须等。public class Product { [JsonProperty(product_id)] // 序列化后字段名为 product_id public int Id { get; set; } [JsonProperty(Order -1)] // 让Name属性在JSON中最先出现 public string Name { get; set; } [JsonProperty(Required Required.Always)] // 反序列化时此属性必须存在 public decimal Price { get; set; } [JsonIgnore] // 完全忽略此属性不序列化也不反序列化 public string InternalCode { get; set; } }[JsonIgnore]忽略属性。[JsonConverter(typeof(...))]为特定属性指定自定义转换器优先级高于全局设置。最佳实践建议为API模型显式使用[JsonProperty]这确保了即使你重命名了C#属性序列化后的JSON字段名也不会意外改变保持了API的稳定性。这也是API版本管理的一部分。谨慎使用Required设为Required.Always可以在反序列化时提供早期验证但也要考虑向后兼容性有时Required.Default默认或Required.AllowNull更合适。区分领域模型和DTO不要在你的领域实体Entity上滥用Json.NET特性。这些特性属于基础设施层。应该为不同的应用场景如Web API、消息队列创建专门的DTO并在DTO上应用这些序列化特性。5. 错误处理与调试如何快速定位序列化问题即使配置周全序列化错误仍可能发生。良好的错误处理和调试技巧能帮你快速定位问题。5.1 捕获并分析JsonSerializationException当DeserializeObject失败时会抛出JsonSerializationException。这个异常对象包含了宝贵的信息。try { var obj JsonConvert.DeserializeObjectMyClass(jsonString); } catch (JsonSerializationException ex) { Console.WriteLine($反序列化失败: {ex.Message}); // ex.Path 属性告诉你错误发生在JSON路径的哪个位置 // 例如Error converting value \N/A\ to type System.Int32. Path temperature, line 3, position 25. Console.WriteLine($JSON路径: {ex.Path}); Console.WriteLine($行号: {ex.LineNumber}); Console.WriteLine($位置: {ex.LinePosition}); }ex.Path尤其有用它能直接指引你到出问题的JSON字段。5.2 使用JsonSerializerSettings.Error事件进行容错处理有时你希望遇到个别错误时不要整个反序列化失败而是记录错误并继续处理其他数据。这可以通过订阅Error事件来实现。var settings new JsonSerializerSettings { Error (sender, args) { // args.ErrorContext.Error 包含了具体的异常 Console.WriteLine($处理 {args.ErrorContext.Path} 时出错: {args.ErrorContext.Error.Message}); // 标记此错误已处理反序列化将继续进行 args.ErrorContext.Handled true; // 你可以在这里选择给出错的属性一个默认值 // 例如如果目标是 MyClass 的某个属性 if (args.ErrorContext.OriginalObject is MyClass myObj) { // 根据Path判断是哪个属性出错并赋值 } } }; var result JsonConvert.DeserializeObjectMyClass(problematicJson, settings); // 即使JSON中有格式错误result也不会是null除非整个JSON无效出错的属性会是默认值。这个机制非常适合处理“脏数据”比如从老旧系统或用户输入中获取的不完全规范的JSON。5.3 序列化跟踪与诊断对于复杂的对象有时你只是想看看JsonConvert到底是如何处理它的。除了调试你还可以使用JsonConvert.SerializeObject的重载版本配合JsonSerializer进行更细致的控制或者在自定义转换器内部加入日志。一个简单的诊断方法是序列化成格式化的JSON便于肉眼观察结构var formattedJson JsonConvert.SerializeObject(myObject, Formatting.Indented); Console.WriteLine(formattedJson);对于性能分析可以使用Stopwatch来测量序列化/反序列化大量数据所花费的时间从而定位瓶颈。6. 与System.Text.Json的简要对比与迁移考量自 .NET Core 3.0 起微软推出了内置的System.Text.Json命名空间。它设计目标就是高性能和低内存分配在大多数基准测试中其性能显著优于 Json.NET。主要差异点性能System.Text.Json默认更快内存开销更小。特性丰富度Json.NET 的功能如JsonConverter的灵活性、Error事件、JsonPath支持等目前仍然更丰富。API差异两者API相似但不兼容。例如配置方式不同JsonSerializerOptionsvsJsonSerializerSettings特性也不同[JsonPropertyName]vs[JsonProperty]。默认行为例如System.Text.Json默认属性名采用小写驼峰可配置而 Json.NET 默认保持原样。System.Text.Json对循环引用的处理更严格默认抛出异常。迁移建议新项目如果项目从 .NET Core 3.0 开始且没有特殊复杂的序列化需求如需要大量自定义转换器、处理多态类型优先考虑System.Text.Json。存量项目如果项目严重依赖 Json.NET 的高级特性或者是一个大型代码库不建议盲目迁移。迁移成本可能很高且收益主要体现在高性能场景。可以尝试在新模块或性能关键路径上逐步试用System.Text.Json。混合使用两者可以在同一个项目中并存只需注意引用不同的命名空间即可。但这会增加团队的认知负担。一个快速示例对比// 使用 System.Text.Json 序列化 using System.Text.Json; var options new JsonSerializerOptions { WriteIndented true, PropertyNamingPolicy JsonNamingPolicy.CamelCase }; string json JsonSerializer.Serialize(myObject, options); // 使用 Json.NET 序列化 using Newtonsoft.Json; string json JsonConvert.SerializeObject(myObject, Formatting.Indented);最终选择哪个取决于你的项目具体需求、团队熟悉度和性能要求。对于绝大多数业务应用Json.NET 的成熟度和功能完备性依然是巨大的优势。而对于高性能网络服务、频繁序列化大量数据的场景System.Text.Json是更面向未来的选择。回顾这次线上故障根本原因是我们对数据契约的边界情况考虑不足。序列化和反序列化远不止是简单的函数调用它是系统间、层与层之间数据契约的强制执行者。通过深入理解JsonSerializerSettings、善用JsonConverter、遵循性能最佳实践并建立有效的错误处理机制我们可以将这个潜在的故障点转变为保障系统数据流动稳定可靠的坚实桥梁。在下次调用JsonConvert时不妨多花几分钟思考一下数据的来源是否可靠格式是否可能变化我的配置是否能优雅地应对这些变化
