如何在自定义Json Converter中反序列化前处理输入Json字符串

首先先指出现有代码的几个直接阻塞运行的问题：

• CustomParsing方法直接给未初始化的modifiedJsonString变量做正则替换，变量初始值为null，运行就会抛异常
• 正则替换的字段值带了多余空格（比如把SomeAddr替换成"AddressLine1 "，末尾的空格会导致反序列化时匹配不到实体类字段）
• CanConvert直接返回true会导致这个Converter被应用到所有类型的序列化/反序列化流程，大概率触发无限递归
• 把Converter挂在每个属性上会导致嵌套结构被反复预处理，逻辑重复出错

关于四个核心问题的说明 #

1. 解析逻辑能否和实体类整合又保持低耦合 #

完全可以，但不要把解析逻辑直接写进实体类本身：

• 直接在Client类里加静态解析方法、自定义构造函数处理格式兼容，会把纯数据模型和外部Json格式的适配逻辑强耦合，后续第三方返回格式变更时需要反复修改实体类，违反单一职责。
• 低耦合的整合方式：把所有字段映射、值转换规则统一封装在Converter内部，实体类保持纯POCO结构，不带任何解析相关代码。如果规则比较多，可以单独抽一层映射规则存储类，Converter只负责读取规则执行转换，完全和实体类解耦。

2. 现有Converter方案如何实现正常返回对象 #

思路整体可行，但要重构核心逻辑，不要靠字符串正则做预处理，ReadJson的通用返回逻辑不需要硬编码指定反序列化的泛型类型，具体实现步骤：

• 加载原始Json为JToken结构，全程基于结构树做修改，不要转成字符串用正则处理
• 预处理过程直接在JToken层面操作：重命名字段、提取嵌套的内层值、转换字段值，所有操作不依赖Json的文本格式，不会出现误匹配
• 预处理完成后，直接调用token.ToObject(objectType, serializer)返回目标类型的实例即可，不需要硬编码RootObject之类的具体类型，Converter可以通用适配所有需要预处理的类型

举个替代正则的预处理示例：

// 处理IsPublic到IsPrivate的转换
if (token["IsPublic"] != null)
{
    var isPublicValue = (bool)token["IsPublic"];
    token["IsPrivate"] = !isPublicValue;
    token.Remove("IsPublic");
}
// 处理嵌套包装的字段，比如把MyName下的CustName提到外层Name字段
if (token["MyName"]?["CustName"] != null)
{
    token["Name"] = token["MyName"]["CustName"];
    token.Remove("MyName");
}

注意：把Converter直接挂在Client类的层级，不要挂在每个属性上，避免重复触发解析。

3. 带传参基类构造函数的场景适配 #

Newtonsoft.Json的ToObject方法本身就支持自动匹配带参数的构造函数，不需要手写实例化逻辑：

• 只要预处理完的JToken里的字段名，和构造函数的参数名匹配（可通过serializer的设置控制是否大小写不敏感），ToObject会自动调用匹配的构造函数实例化对象
• 如果基类构造函数需要的参数来自Json的特定字段，只要在预处理JToken的时候，把对应值放到和构造参数同名的位置即可，不管嵌套层级有多深，处理逻辑都和无参构造的场景完全一致。
• 不需要因为构造函数带参数就手写复杂的实例化逻辑，JToken结构修正正确的情况下，反序列化流程和普通无参类没有区别。

4. 现有实现思路的缺陷和更优方案 #

纯正则匹配Json字符串的思路从根上稳定性极差，常见踩坑点：

• 如果字段值本身包含"CarName":这类文本，正则会触发误替换
• Json字段顺序变更、字段末尾没有逗号、值为多行转义字符串的时候，正则匹配规则会直接失效
• 嵌套层级变深时，正则的匹配范围很容易错配到其他字段

更可靠的替代方案：

• 放弃字符串正则替换，全程用JToken的结构化操作做预处理，所有修改基于Json结构树，和文本格式无关，零误匹配风险
• 对于简单的字段名映射，不需要写自定义Converter，直接用[JsonProperty]特性配置多名称映射即可，减少自定义逻辑的维护成本
• 对于IsPublic转IsPrivate这类单字段值转换，单独写一个小的布尔类型Converter处理即可，不需要在整个对象层级的Converter里塞零散逻辑
• 注意示例Json里IsPublic的值是字符串"True"而非布尔类型，正则方案处理这种字符串类型的布尔值很容易出现类型转换错误，结构化的JToken操作可以自动完成类型兼容。

内容的提问来源于stack exchange，提问作者stackMeUp