C#怎么操作JSON路径查询 C#如何用JsonPath或System.Text.Json查询嵌套JSON数据【技巧】

JsonPath 不是 System.Text.Json 原生功能，需依赖 Newtonsoft.Json 等第三方库；手动遍历 JsonElement 要用 TryGetProperty 和类型检查防崩溃；固定路径应优先使用强类型反序列化而非 JsonPath。JsonPath 在 C# 里根本不是 .NET 原生支持的System.Text.Json 自带的 JsonElement 和 JsonProperty 没有内置 JsonPath 解析能力。你写 $..name 或 $.data[?(@.age > 30)]，直接报错——它压根不认识这语法。想用 JsonPath，必须引入第三方库，最常用的是 Newtonsoft.Json（即 Json.NET）搭配 JToken.SelectTokens()；或者用轻量替代方案 Manatee.Json 或 JsonPath.Net。但注意：System.Text.Json 本身不提供 SelectTokens，别在官方文档里白找。如果你项目已用 Newtonsoft.Json，直接上 JObject.Parse(json).SelectTokens("path")如果坚持用 System.Text.Json，只能手动遍历 JsonElement，或封装递归查找逻辑（比如匹配字段名、数组索引、简单条件）混合使用两种解析器容易出问题：比如把 JsonElement 强转成 JToken 会抛 InvalidOperationExceptionSystem.Text.Json 手动查嵌套字段怎么写才不崩没有 JsonPath，就得靠 GetProperty() 和 EnumerateArray() 一层层钻。关键不是“能不能”，而是“怎么避免空引用崩溃”和“路径不存在时安静失败”。比如查 $.store.book[0].author，不能连写 root.GetProperty("store").GetProperty("book")[0].GetProperty("author")——中间任意一环为 null 或类型不对（比如 "book" 是字符串不是对象），立刻炸。永远用 TryGetProperty("xxx", out var result) 替代 GetProperty()数组访问前先确认是 JsonValueKind.Array，再用 EnumerateArray() 遍历，别硬用 [0]类型检查不能少：取值前用 result.ValueKind == JsonValueKind.String 判断，否则 result.GetString() 可能返回 null 而非抛异常路径深了建议写个辅助方法，传入 JsonElement 和 string[] path，逐段 TryGetPropertyNewtonsoft.Json 的 SelectTokens 性能和坑点SelectTokens 写起来爽，$.items[*].price 一行搞定，但它不是零成本魔法。底层要构建 AST、遍历整棵树，对大 JSON（>1MB）或高频调用场景，比手写 GetProperty 慢 3–5 倍。更麻烦的是语义陷阱：比如 $..id 默认深度优先遍历所有层级，可能返回意外的嵌套字段；[?(@.status == 'active')] 中字符串比较默认区分大小写，而 System.Text.Json 默认不支持这种表达式。用 SelectTokens 前先 JObject.Parse(json)，别反复解析同一份 JSON 字符串过滤表达式里避免复杂逻辑，[?(@.x > @.y)] 这种跨字段比较在某些版本会静默失败结果是 IEnumerable<jtoken></jtoken>，别直接 .ToList() 存着——JToken 是引用，原 JObject 被 GC 后它就失效若只取第一个匹配项，用 SelectToken（单数）比 SelectTokens（复数）略快且语义更明确什么时候该放弃 JsonPath，改用序列化模型如果你查的路径是固定的（比如总要取 response.data.items[].name），而且结构稳定，硬写 JsonPath 或手动遍历反而增加维护成本。这时候直接定义 C# 类，用 System.Text.Json.JsonSerializer.Deserialize<t>()</t> 更安全、更快、IDE 还能补全。JsonPath 真正有用，是当路径来自配置、用户输入或需要动态拼接时——比如 API 返回结构不统一，靠字段名开关控制提取逻辑。模型类字段加 [JsonPropertyName("api_field_name")] 处理命名差异不确定是否存在字段，用 string? 或可空类型（如 int?），反序列化自动为 null嵌套数组用 List<t></t>，别用 T[] ——后者反序列化失败时不报错，而是整个对象为 null别为了“灵活”把所有字段都定义成 JsonElement，那等于放弃了类型安全和性能优势真正难的从来不是怎么写路径表达式，而是判断：这个查询到底是临时调试用，还是会长期嵌在业务逻辑里。后者几乎总是该收进模型类。