在使用Agile.NET对程序进行混淆后，经常碰到Json序列化失效的情况，同时开发者也很关心如何保留Json字段名；这类问题的核心往往在于混淆过程中的重命名操作。根据Agile.NET的官方说明，该工具会重命名命名空间、类名、方法签名、字段以及方法实现中用到的元数据构造，而Json序列化的过程通常需要借助反射来获取类名、属性名、字段名以及特性信息。一旦这些名称被混淆修改，而前端、配置文件、缓存或者第三方系统仍然按照原先的字段名来传递数据，那么反序列化时就会遇到字段值为空、字段缺失，或者接口返回的字段变成简短乱码等问题。

　　一、为什么混淆后Json序列化会失效

　　Json序列化出现问题，并不是说混淆本身不能用；真正的原因在于，那些参与Json映射的对象被一并重命名了。尤其是DTO、ViewModel、接口请求类、接口返回类还有配置类，这些类型原本就要求字段名称与外部保持一致。

　　1、属性名被重命名：默认情况下，System.Text.Json会根据.NET属性名来生成Json中的字段名；当然，开发人员也可以通过命名策略或者自定义特性来修改这个行为。微软的文档里指出，使用JsonPropertyName特性可以为单个属性单独指定Json名称，并且这个指定的名称优先于其他命名策略。如果混淆后属性名发生了变化，而代码中又没有通过特性等方式固定Json字段名，那么序列化得到的结果就可能与原本的接口约定不同。

　　2、字段参与序列化：有些项目不仅仅序列化公共属性（public property），还会开启对字段的序列化，或者借助Newtonsoft.Json把私有成员也包含到映射范围里。根据Json.NET的文档，JsonPropertyAttribute可以用来指定Json属性名，同时也能将非公有的属性纳入序列化。这些成员如果被混淆重命名，产生的问题往往更加隐蔽，不容易被发现。

　　3、接口模型被当成内部代码混淆：业务逻辑相关的类重命名或许影响不大，但那些作为外部契约的类就不能随意修改了。例如LoginRequest中的userName和password，OrderDto里的orderId和productName，这些字段名与前端页面、后端服务、接口文档以及数据库缓存都有关联。一旦混淆引起字段名变动，而调用方依然沿用旧的字段名发送数据，反序列化时就会填充为默认值。

　　4、特性或反射逻辑被破坏：部分代码会借助反射来查找指定的属性名，或者依赖Json相关的特性、DataMember名称以及枚举字符串名称。混淆之后要是成员名发生了改变，反射查找就很可能找不到对应的对象；如果特性在处理时被错误修改，Json库同样无法依照预期完成映射。

　　二、如何配置才能保留Json字段名

　　配置的基本思路并不复杂：内部实现代码依然可以混淆，但涉及Json交互的边界部分需要保持不变。不建议对整个项目彻底关闭混淆，也不用把所有的类都排除在外，关键是只排除那些接口模型、配置模型以及需要被反射访问的成员。

　　1、将DTO的命名空间添加进排除列表：最好把所有的Json请求类和返回类统一放置在固定的命名空间中，像Project.Api.Models、Project.Contracts或者Project.DTO。接着在Agile.NET的排除规则或重命名设置里，针对这些命名空间关闭重命名功能，其他的保护选项可以保留。这样一来，字段名就能保持稳定，而业务代码的保护也不会被削弱。

　　2、对关键类关闭成员重命名：如果无法按照命名空间进行排除，也可以针对具体的类来配置排除项。需要特别留意的类型有Request、Response、Dto、ViewModel、Config、Options、Message、Event等。至于类名要不要保留，取决于外部是否直接引用了它；而属性名和字段名通常都需要保留下来。

　　3、利用Json特性固定字段名：对于接口中用到的字段，推荐显式地写出对应的Json字段名。如果用的是System.Text.Json，就使用JsonPropertyName特性；如果是Newtonsoft.Json，则使用JsonProperty特性。这样做之后，就算代码里的命名在后续发生调整，Json的输出依然可以维持稳定。同时需要留意，这些特性本身应该被保留，相关成员也不要被配置成会干扰映射的模式。

　　4、借助ObfuscationAttribute辅助控制：.NET框架提供了ObfuscationAttribute特性，按照微软文档的说明，它的Exclude属性用来告知混淆工具是否要把某个类型或成员排除在混淆范围之外。对于Json模型类，可以将Exclude设置为true，并让这个规则应用到成员级别。不过实际能不能生效，还得看Agile.NET当前的版本是否会读取这个特性，以及项目中混淆规则的优先级设置。

　　三、混淆后如何验证Json相关问题

　　完成配置之后，不能仅仅检查程序能否正常启动，还得专门进行一轮Json的回归测试。原因在于，很多序列化方面的问题并不会在启动阶段就报错，往往是在接口调用、配置读取或者消息反序列化的时候才会显露出来。

　　1、对比混淆前后的Json文本：挑选几个具有代表性的对象，在混淆前和混淆后分别执行一次序列化操作，然后核对字段名有没有发生变化。查看时需要重点关注大小写、下划线、驼峰命名方式、枚举值以及嵌套对象里的字段。

　　2、进行反序列化测试：拿真实的接口返回Json或者历史缓存的Json数据，对混淆后的程序集进行反序列化，检查各个字段的值能不能被正确填充。仅仅测试序列化过程是不够的，因为很多问题恰恰发生在从外部读回Json数据的时刻。

　　3、检查接口边界类：将控制器接收的参数、API返回的对象、消息队列中的对象、配置文件里的对象以及插件通信使用的对象整理成一份清单。凡是需要跨越进程、系统或者版本进行传递的对象，都不应该让它们的字段名随意变动。

　　4、保留内部代码的保护：Json字段名的保留并不意味着整个项目都不做混淆了。可以只把契约层的模型排除掉，而其他的服务类、算法类、工具类还有内部方法，照样可以开启重命名、控制流混淆和字符串保护。这种策略既能保障接口的稳定，也能保持代码保护的效果。

　　总结

　　总结而言，Agile.NET混淆后Json序列化之所以失效，主因在于Json映射所依赖的类名、属性名、字段名还有反射信息被混淆操作重命名了。针对如何配置以保留Json字段名，比较推荐的做法是：按照命名空间或者按类将DTO、Request、Response、Config等外部契约对象排除在重命名之外，同时利用JsonPropertyName或JsonProperty特性来显式固定字段名；之后再通过对比混淆前后的Json以及真实的反射序列化测试来确认结果。让内部实现保持混淆，而外部数据契约维持稳定，这算是一种相对稳妥的处理方式。