UWP启用原生工具链的Release版本中System.Text.Json序列化复杂对象卡顿的问题排查与解决咨询

兄弟，我太懂这种Debug跑的飞起，一到Release（还开了原生工具链）就卡得要死的崩溃感了！结合你提供的复杂模型和场景，我来拆解下问题根源和可行的解决办法：

问题核心原因 #

启用原生工具链后，UWP的Release构建会触发.NET的IL裁剪（Trimming）和AOT预编译优化——这俩操作会把程序里没被「明确引用」的反射元数据砍掉。而你用的System.Text.Json默认依赖反射来序列化对象，你的模型又包含了递归引用、枚举、动态object类型、继承结构这些高度依赖反射元数据的复杂结构，结果就是序列化时JsonSerializer找不到必要的元数据，要么陷入无限反射重试的循环，要么走了极低性能的 fallback 路径，直接卡主。

可行的解决办法 #

办法一：给模型添加反射元数据保留标记，阻止裁剪工具砍掉关键类型 #

你可以在模型类上添加[DynamicDependency]属性，明确告诉裁剪工具要保留这些类型的所有反射信息。比如给根类型及所有关联的复杂类型、枚举添加：

using System.Diagnostics.CodeAnalysis;

[DynamicDependency(DynamicallyAccessedMemberTypes.All, typeof(WeatherCondition))]
[DynamicDependency(DynamicallyAccessedMemberTypes.All, typeof(TemperatureUnit))]
[DynamicDependency(DynamicallyAccessedMemberTypes.All, typeof(AlertSeverity))]
[DynamicDependency(DynamicallyAccessedMemberTypes.All, typeof(TemperatureReading))]
[DynamicDependency(DynamicallyAccessedMemberTypes.All, typeof(WeatherReport))]
// 把所有涉及的枚举、记录类型都加上
public record CompleteWeatherData(...) { }

或者更省心的方式，直接在你的.NET Standard类库的.csproj文件里添加配置，告诉裁剪工具不要裁剪整个模型类库的元数据：

<ItemGroup>
  <TrimmerRootAssembly Include="WeatherApp.Models" />
</ItemGroup>

这个方法改动小，但缺点是会略微增加安装包体积。

办法二：改用System.Text.Json的源生成器（强烈推荐） #

源生成器会在编译时直接生成序列化/反序列化的代码，完全绕开反射，从根源上避免裁剪工具的影响，而且性能还会提升一大截。步骤很简单：

1. 给你的.NET Standard类库安装和System.Text.Json同版本的System.Text.Json.SourceGeneration NuGet包；
2. 创建一个继承自JsonSerializerContext的部分类，给所有需要序列化的模型类型添加[JsonSerializable]标记：

   using System.Text.Json.Serialization;
   
   [JsonSerializable(typeof(CompleteWeatherData))]
   [JsonSerializable(typeof(WeatherReport))]
   [JsonSerializable(typeof(DailyForecast))]
   // 把所有要序列化的类型都列在这里
   public partial class WeatherJsonContext : JsonSerializerContext { }
   

3. 序列化时改用这个上下文，而不是默认的无参方法：

   var json = JsonSerializer.Serialize(yourCompleteWeatherData, WeatherJsonContext.Default.CompleteWeatherData);
   

这个方法是最优解，既解决了卡顿问题，又提升了序列化性能，还能在编译时提前发现序列化的问题。

办法三：处理递归引用的问题 #

你的WeatherReport里有递归属性PreviousReport，System.Text.Json默认不处理循环引用，在Debug模式下反射路径可能没触发死循环，但Release原生编译后，可能因为元数据缺失导致循环引用检测失效，直接陷入无限递归卡主。你可以在序列化时配置循环引用处理：

var options = new JsonSerializerOptions
{
    ReferenceHandler = ReferenceHandler.IgnoreCycles, // 忽略循环引用，避免死循环
    // 也可以用ReferenceHandler.Preserve来保留引用，但会生成额外的$id标记
};
var json = JsonSerializer.Serialize(yourWeatherReport, options);

办法四：优化动态类型的处理 #

你的WeatherMetadata里有Dictionary<string, object>和object RawData，这些动态类型非常依赖反射元数据。如果可以的话，尽量把RawData改成具体的类型（比如JsonElement），或者给可能的类型添加[DynamicDependency]标记，告诉裁剪工具保留这些类型的元数据。

总结 #

优先尝试源生成器方案，既能彻底解决问题又提升性能；如果暂时不想改代码，就用Trimmer配置或者DynamicDependency保留元数据，同时记得处理递归引用的问题。

内容来源于stack exchange