应优先用 jsonserializer.deserialize；仅当处理大文件（>10mb）或高吞吐固定结构json（如kafka日志）时，才用utf8jsonreader手动解析以避免反射与分配开销。
Utf8JsonReader 不是“拿来就能快”的工具，它是给明确知道 JSON 结构、且愿意手动跳过无关字段的人用的。直接上 JsonSerializer.Deserialize 更省事；真要榨干性能，就得自己 Read()、GetString()、TryGetInt32() 一步步走。
什么时候该用 Utf8JsonReader 而不是 Deserialize
你手里的 JSON 文件大于 10 MB，或者每秒要解析成百上千个 JSON 片段（比如日志行、MQ 消息体），且结构高度固定——这时 Deserialize 的反射+对象分配开销就显眼了。而 Utf8JsonReader 是 ref struct，全程栈上操作，不分配中间对象，也不做字段名匹配，只管读字节流。
- 典型场景：解析 Kafka 中每个消息的
{"id":123,"ts":"2026-05-14T15:00:00Z","status":"ok"}，只取id和ts字段存入结构体 - 不适合场景：JSON 字段名动态变化、嵌套深且不规则、需要把整个树转成
JsonElement或object - 注意：它不支持注释和尾逗号——
ReadCommentHandling这类选项对它无效，必须提前清理或确保输入合规
Read() 后 TokenType 判断顺序不能错
Utf8JsonReader 是状态机驱动的，Read() 每次推进一个 token，但 token 类型决定下一步怎么取值。常见错误是看到 JsonTokenType.PropertyName 就直接调 GetString()，结果拿到的是属性名字符串，不是值。
- 正确流程：先
Read()→ 判断reader.TokenType == JsonTokenType.PropertyName→ 再Read()→ 此时才可能拿到JsonTokenType.String或JsonTokenType.Number - 如果跳过第二次
Read()，后续所有GetXXX()都会返回默认值或抛InvalidOperationException - 对数组或对象，要用
reader.TokenType == JsonTokenType.StartArray或StartObject触发循环，靠CurrentDepth控制嵌套退出
GetString() 和 ValueSpan 的区别很关键
GetString() 返回的是新分配的 string，而 ValueSpan 是只读切片，指向原始 UTF-8 字节数组里的一段内存。如果你只是比对字段名或提取短字符串（如状态码 "error"），用 ValueSpan + SequenceEqual 更快；但要传给其他方法或持久化，就得用 GetString()。
-
reader.ValueSpan仅在当前 token 值能塞进单个ReadOnlySpan<byte></byte>时有效（即没跨 segment）；否则得用ValueSequence，但处理复杂得多 - 别在循环里反复调
GetString()处理同一字段——比如反复解析"id"字符串，应提前缓存ReadOnlySpan<byte> idName = Encoding.UTF8.GetBytes("id")</byte>，再用reader.ValueSpan.SequenceEqual(idName) -
GetString()对null值返回null，但对空字符串""返回空字符串，不是null
ParseValue(ref Utf8JsonReader) 的真实用途
JsonElement.ParseValue(ref Utf8JsonReader) 看起来像“自动解析子树”，但它不是帮你省事的捷径——它会把当前 token 及其所有嵌套内容（直到匹配的 } 或 ]）完整加载进内存，生成一个 JsonElement。这等于放弃了流式优势，回到了 JsonDocument 的开销模型。
- 只在你需要临时把某一段 JSON（比如某个嵌套对象）当完整子文档处理，且确定它不会太大时才用
- 误用场景：在大数组里对每个元素都调一次
ParseValue，结果内存暴涨，GC 频繁 - 替代思路：用
reader.CurrentDepth记录起始深度，手动Read()直到CurrentDepth回到起始值，期间只取所需字段
真正难的不是写对第一个 Read()，而是保证整个 token 流不跳步、不漏判、不越界——尤其当 JSON 里混着 null、缺失字段、或意外多一层嵌套时，CurrentDepth 和 TokenType 的组合判断很容易出错。建议先用小样例跑通路径，再加边界 case 断言。
