System.Text.Json吞吐量更高但默认限制多，Newtonsoft.Json GC压力大；正确复用实例、禁用冗余配置、线程安全转换器是关键。
System.Text.Json 序列化吞吐量明显更高，但默认不支持循环引用和某些类型
在 Web API 或微服务高频请求场景下，System.Text.Json 的序列化/反序列化吞吐量通常比 Newtonsoft.Json 高 1.5–2.5 倍，尤其在小对象（如 DTO）密集读写时。这源于它基于 Span 和零分配设计，避免了大量字符串拼接与中间 StringBuilder 缓冲区。但它的默认行为更“严格”：不处理对象图中的循环引用、不支持 DataTable 或 ExpandoObject、对 Dictionary 的键类型要求更死板。
Newtonsoft.Json 在高并发下 GC 压力更大，尤其使用默认设置时
典型表现是 Gen 0 GC 频率陡增，甚至触发 Gen 1，导致请求延迟毛刺。原因包括：JToken 层级结构堆分配多、默认启用 TypeNameHandling 时写入额外元数据、JsonConvert.SerializeObject 每次调用都可能新建内部缓存上下文（除非显式复用 JsonSerializer 实例）。实操建议：
- 始终复用
JsonSerializer实例（而非反复调用静态JsonConvert方法） - 禁用
TypeNameHandling，除非真需要反序列化为运行时未知类型 - 对已知结构的 JSON，优先用
JObject.Parse()+ 显式属性访问，而非DeserializeObject()
高并发下 System.Text.Json 的坑：自定义转换器 + 同步锁易成瓶颈
当需要兼容旧系统（如日期格式为 "yyyy-MM-dd"）、或处理 DBNull、KeyValuePair 等特殊值时，常需注册自定义 JsonConverter。若转换器内部用了 lock、Monitor.Enter 或非线程安全的静态缓存（如 ConcurrentDictionary 误用为普通 Dictionary），会直接拖垮吞吐。示例错误写法：
public class BadDateConverter : JsonConverter
{
private static readonly Dictionary _cache = new(); // 非线程安全！
public override DateTime Read(...){ ... }
public override void Write(...){ ... }
}
正确做法是：用 ConcurrentDictionary、避免锁、或把缓存逻辑移到上层（如 ASP.NET Core 的 HttpContext.Items）。
