为什么继承 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 解析就偏移了。这才是关键所在。
