为什么 JsonSerializerContext 能在高并发下提升性能
因为
JsonSerializerContext预编译了类型序列化逻辑，避免每次调用
JsonSerializer.Serialize时重复反射、生成委托、构建缓存键。在高并发场景下，反复创建
JsonSerializerOptions或依赖默认上下文会触发锁竞争和 GC 压力，而静态复用的
JsonSerializerContext子类是线程安全且零分配（对已知类型）。
如何正确定义和使用 JsonSerializerContext 子类
必须继承抽象基类
JsonSerializerContext，用
[JsonSerializable]标记要支持的类型，并启用源生成（Source Generator）。不能手动 new 它，也不能把它当普通类随意实例化。 项目需启用源生成：在
.csproj中添加
<propertygroup><enabledefaultjsontypeinforesolver>true</enabledefaultjsontypeinforesolver></propertygroup>（.NET 7+ 推荐），或显式引用
System.Text.Json.SourceGeneration包
JsonSerializerContext子类必须是
public sealed，且构造函数为
internal或
protected每个上下文应聚焦一组相关类型，避免把几十个 DTO 全塞进一个上下文——类型过多会导致生成代码膨胀、编译变慢、热重载失败
public static partial class MyJsonContext : JsonSerializerContext
{
[JsonSerializable(typeof(Order))]
[JsonSerializable(typeof(List<Order>))]
[JsonSerializable(typeof(Dictionary<string, decimal>))]
public static partial JsonTypeInfo<Order> Order { get; }
public static partial JsonTypeInfo<List<Order>> OrderList { get; }
}
高并发中怎么传参、怎么选 API
核心原则：复用同一个
JsonSerializerContext实例，且优先使用泛型重载，避免运行时类型擦除带来的装箱或反射回退。 序列化时用
JsonSerializer.Serialize(output, value, context.Order)，而不是
JsonSerializer.Serialize(output, value, options)—— 后者绕过源生成，退化为传统路径 反序列化必须指定具体
JsonTypeInfo<t></t>，例如
JsonSerializer.Deserialize<order>(input, MyJsonContext.Order)</order>；若只传
context不传
JsonTypeInfo，会触发内部查找逻辑，失去性能优势 不要在请求处理中 new 上下文实例：所有
JsonSerializerContext子类都应通过静态属性暴露，如
MyJsonContext.Default或直接用生成的
static partial属性
容易被忽略的坑和兼容性限制
源生成不是万能的，很多动态场景它不支持，强行用反而引发运行时异常或静默退化。
不支持运行时才确定的泛型参数（如T来自方法参数且未在
[JsonSerializable]中声明） 不支持
object、
dynamic、
ExpandoObject等无固定结构类型——它们仍走反射路径，且无法被
JsonSerializerContext捕获 .NET 6 的源生成是实验性功能，.NET 7+ 才稳定；若项目混用旧版 SDK 或 CI 环境未升级，可能生成失败但不报错，导致上线后性能骤降 调试时注意：生成的代码在
obj/Debug/...下，若清理不彻底，可能引用旧版
JsonTypeInfo导致序列化结果不一致
最常出问题的是「以为加了
[JsonSerializable]就万事大吉」，实际没检查生成是否成功、没验证泛型绑定是否精确、也没压测对比分配率——这些地方一漏，高并发下的性能收益就归零。
