C#如何实现自定义JsonConverter_C# System.Text.Json转换器开发教程【高级】

先说几个关键判断。System.Text.Json 的自定义转换器，说难不难，说简单也不简单，核心在于理解它的类型系统和运行机制。很多开发者卡在注册了却无效、读数据时异常、或者写出的转换器只能处理特定类型的死胡同里。这篇文章就来把这些坑一一填上。

为什么继承 JsonConverter 而不是直接写 JsonConverter

一句话解释：JsonConverter 只是个不带泛型的抽象基类，它天然无法参与类型推导，也得不到编译期的检查；而 JsonConverter 才是真正干活的入口。System.Text.Json 在序列化时，靠的就是这个泛型参数来精准匹配类型。你不指定 T，那 Read 和 Write 方法里的 typeToConvert 参数就形同虚设，运行时要么报 NotSupportedException，要么直接跳过你的转换器——后者更隐蔽，更让人头疼。

一个非常典型的错误场景：注册了转换器，但序列化结果毫无变化，JSON 依然按默认规则处理。大概率就是没继承 JsonConverter，而是误写了 JsonConverter。

• 必须显式指定泛型类型，比如 JsonConverter、JsonConverter>。
• 但注意，如果类型本身含泛型参数（比如 Dictionary），你不能直接写 JsonConverter> 来继承，编译根本过不了。这时候，就得请出 JsonConverterFactory 来动态构造。
• 还有一点容易被忽略：Read 方法里拿到的 ref Utf8JsonReader 必须手动推进。漏掉 reader.Read()，或者误用 reader.Skip()，都会导致后续字段解析错位，整个 JSON 就乱了。

如何正确处理 null 值和意外 token 类型

System.Text.Json 不会帮你兜底。遇到 null、Number 却期待 String、或者字段缺失时，Utf8JsonReader 的 TokenType 就是你唯一的判断依据。不检查？GetString() 会直接抛 InvalidOperationException，GetInt32() 遇到 "true" 也会崩溃。

一个经典场景：反序列化一个可为空的自定义对象，或者兼容前后端字段类型不一致——比如后端传了 "123" 字符串，但 C# 属性是 int?。

• 第一步：先读 reader.TokenType。如果是 JsonTokenType.Null，对可空类型直接 return null，对非空类型则应该 throw。
• 第二步：判断是否为预期类型。比如要读字符串，就检查 reader.TokenType == JsonTokenType.String，否则要么 throw，要么 fallback 处理。
• 第三步：用 reader.TryGet...() 系列方法。比如 TryGetInt32(out int v) 比直接 GetInt32() 更安全，失败时不抛异常，给你留了处理空间。
• 第四步：手动推进 reader。每次成功读一个值后，务必调用 reader.Read() 进入下一个 token，否则下次 Read() 会卡在原地。

什么时候必须用 JsonConverterFactory 而不是普通 JsonConverter

这个问题很关键。当你需要为开放泛型类型（比如 Dictionary、List）提供通用转换逻辑时，JsonConverterFactory 是唯一选择。普通 JsonConverter 只能绑定到闭合类型（比如 Dictionary），编译期就固定死了，没有灵活性。

一个常见的错误做法：试图写 class DictEnumConverter : JsonConverter> —— 编译不过，而且运行时也无法实例化。

• CanConvert(Type typeToConvert) 必须严格判断：检查 IsGenericType、GetGenericTypeDefinition()、泛型参数数量和约束（比如第一个是不是 Enum）。
• CreateConverter(Type type, JsonSerializerOptions options) 里用 Type.MakeGenericType(...) 构造闭合类型，再通过 Activator.CreateInstance 创建对应转换器实例。
• 内部实际转换器（比如 DictionaryEnumConverterInner）仍需继承 JsonConverter>，只是它的 TKey 和 TValue 在工厂里动态确定。
• 别忘了在 CreateConverter 中复用 options：把它传给内部转换器，让它能获取其他已注册的 converter，比如处理 TValue 的 converter 时就需要这个。

[JsonConverter] 特性与全局注册的优先级冲突怎么解

一个很容易踩的坑：特性方式永远高于全局注册。如果你在某个属性上加了 [JsonConverter(typeof(MyConverter))]，哪怕你同时在 JsonSerializerOptions.Converters 里加了另一个转换器，序列化时也只会走特性的那个。

调试时容易误判：以为全局注册生效了，结果发现某字段行为异常，查了半天，其实是类或属性上的特性悄悄覆盖了。

• 特性可作用于三处：类（整个类型）、属性（仅该字段）、泛型类型参数（C# 12+ 支持）。
• 如果类和属性都标了不同转换器，属性级优先级更高。
• 工厂类（JsonConverterFactory）也能被特性引用，比如 [JsonConverter(typeof(DictionaryEnumConverterFactory))]。
• ASP.NET Core 全局配置（AddJsonOptions）注册的转换器，对带特性的成员完全无效——这是设计使然，不是 bug。

说到底，真正难的不是写出 Read 和 Write 方法，而是每次推进 Utf8JsonReader 前，都想清楚当前 token 是什么、下一个应该是什么、null 怎么退、异常怎么抛。System.Text.Json 没有“上下文自动恢复”机制，错一步，整段 JSON 解析就偏移了。这才是关键所在。