.NET 8 重大变更：启用PublishTrimmed后反射式序列化将默认失败
前言
在 .NET 8 中，微软对发布时裁剪(PublishTrimmed)项目中的 System.Text.Json 序列化行为做出了重要调整。这一变更直接影响那些使用反射式序列化且启用了裁剪功能的应用程序。本文将深入解析这一变更的背景、影响范围以及应对策略。
什么是发布时裁剪(PublishTrimmed)
发布时裁剪是 .NET 提供的一项优化功能，它会在发布应用程序时移除未使用的代码，从而显著减小应用程序的体积。这在容器化部署和微服务架构中尤为重要，因为镜像大小直接影响部署效率。
变更内容详解
旧行为分析
在 .NET 8 之前，即使启用了 <PublishTrimmed>true</PublishTrimmed>，System.Text.Json 仍然默认使用反射机制进行序列化。这会导致两个潜在问题：
- 不可预测的行为：由于裁剪会移除未使用的代码，反射式序列化可能在某些情况下意外失败
- 数据不一致：某些属性可能在序列化过程中被意外忽略
// 旧版本中可能成功也可能失败的代码
var result = JsonSerializer.Serialize(new { Value = 42 });
新行为说明
.NET 8 中，当项目启用 PublishTrimmed 时，System.Text.Json 会默认禁用反射式序列化。此时尝试使用反射式序列化会直接抛出异常：
System.InvalidOperationException: Reflection-based serialization has been disabled for this application.
这一变更确保了行为的明确性和一致性，避免了之前版本中可能出现的不可预测问题。
变更原因深度解析
- 安全性考虑：反射式序列化在裁剪后的应用中存在安全隐患
- 性能优化：强制使用源生成器(source generator)可以获得更好的性能
- 可预测性：消除了裁剪后应用可能出现的随机序列化失败
- 最佳实践推广：引导开发者使用更适合裁剪应用的源生成器方式
应对策略
推荐方案：迁移至源生成器
源生成器是 .NET 中处理 JSON 序列化的现代方式，它能在编译时生成序列化代码，完全避免了运行时反射。迁移步骤如下：
- 创建继承自 JsonSerializerContext 的上下文类
- 使用 JsonSerializableAttribute 注册需要序列化的类型
- 使用生成的序列化方法
[JsonSerializable(typeof(MyPoco))]
public partial class MyJsonContext : JsonSerializerContext {}
// 使用生成的序列化方法
var json = JsonSerializer.Serialize(myPoco, MyJsonContext.Default.MyPoco);
临时解决方案：恢复反射式序列化
如果暂时无法迁移到源生成器，可以在项目文件中显式启用反射式序列化：
<PropertyGroup>
<PublishTrimmed>true</PublishTrimmed>
<JsonSerializerIsReflectionEnabledByDefault>true</JsonSerializerIsReflectionEnabledByDefault>
</PropertyGroup>
但需要注意，这不是长期推荐方案，因为：
- 仍然存在裁剪导致序列化失败的风险
- 无法获得源生成器的性能优势
- 未来版本中可能会完全移除反射式支持
最佳实践建议
- 新项目：从一开始就使用源生成器方式
- 现有项目：逐步将关键路径上的序列化迁移到源生成器
- 测试策略：在启用裁剪的情况下进行全面测试
- 依赖检查：确保所有第三方库都支持裁剪环境
总结
这一变更是 .NET 向更安全、更高效的序列化方式迈进的重要一步。虽然短期内可能需要一些迁移工作，但从长远来看，采用源生成器将带来更好的性能、更小的应用体积和更可靠的行为。对于需要发布裁剪应用的开发者来说，理解并适应这一变更至关重要。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
