你有没有被嵌套JSON折磨过？
上次抓了个电商订单接口，返回数据套了五层。领导要"所有金额超100的商品名"，手动翻到眼花。
后来用JSON Path写一行：$.orders[?(@.amount > 100)].productName，三秒出结果。
JSON Path 不是 XML 的 XPath，专门用来定位 JSON 里的字段。今天讲5个真实场景，每个都配好表达式，直接抄。
场景一：接口调试，快速定位字段
后端改了接口，返回结构变了一版。你要确认 data.users 里每个用户的 profile.name 还在不在。
表达式：$.data.users[*].profile.name
把接口返回贴进工具，跑一遍就知道。
navbox 上有在线 JSON Path 查询工具，粘贴 JSON、输入表达式，结果即时显示。不用起本地环境，比 F12 一层层展开快多了。
场景二：数据清洗，批量抽字段
爬了300个商品页，存成 JSON 数组。你现在只要价格和库存两个字段。
表达式：$.products[*].price，再写一遍 $.products[*].stock。
两个结果分别导出，直接拼表。比写 Python 脚本解析省事，数据量在几千条以内都够用。
场景三：测试断言，先验证再写脚本
写自动化测试前，先手动验证一下断言路径对不对。
比如要断言"第一条订单的收货人姓名是张三"。
表达式：$.orders[0].receiver.name
先在线工具里确认能匹配到，再写进测试代码。避免脚本跑起来才发现路径写错，省你反复调试的时间。
场景四：日志提取，秒级找到关键行
服务打出来的结构化日志，一条几千行 JSON。你要找所有状态码为500的请求。
表达式：$.logs[?(@.statusCode == 500)]
配合时间戳过滤：$.logs[?(@.statusCode == 500 && @.timestamp > 1700000000)]
排障时特别好用，比 grep 精准，比读日志快。
场景五：ETL 迁移，旧系统抽数据
从老系统的 JSON 存档里把用户信息抽出来，导入新数据库。
写三个表达式分别提取：
$.users[*].id
$.users[*].email
$.users[*].createdAt
三列数据对齐，生成 CSV 直接导入。
关键技巧：多条表达式提取时，保证数组长度一致，否则错位。在线工具能帮你验证长度是否对得上。
常用表达式速查
| 需求 | 表达式 |
|---|---|
| 取某个字段 | $.users[0].name |
| 取所有某字段 | $.users[*].name |
| 条件过滤 | $.users[?(@.age > 18)] |
| 深度搜索 | ..email（不管嵌套多深） |
| 取前3条 | $.items[0:3] |
| 多条件 | $.orders[?(@.amount > 100 && @.status == "paid")] |
几个坑提前说
[] 里的下标从0开始，不是1。初学时最常见的错。
过滤条件里 @ 代表当前元素，写 $.users[?(@.age > 18)]，@.age 指每个用户的 age 字段。
字符串要加引号，@.status == "paid" 不能写成 @.status == paid。
嵌套太深就换 ..，..fieldName 会从根节点开始递归搜索，不用写完整路径。
动手试一下
找一份你今天接触过的 JSON 数据，写个表达式试着提取。
在线工具粘贴跑一遍，三秒看结果。
你上次定位嵌套字段，用了多久？