最直接方式是使用jsonb_path_query，支持sql/json路径表达式一次定位多层嵌套字段，如$.user.profile.tags[*]，避免链式->操作的易错与不可读问题。
用 jsonb_path_query 提取多层嵌套字段最直接
当目标字段藏在两层以上 JSON 结构里（比如 {"user": {"profile": {"tags": ["a", "b"]}}}），-> 和 ->> 链式写法容易出错且不可读。jsonb_path_query 支持 SQL/JSON 路径表达式，一次定位，返回结果集。
常见错误是漏写 $ 根节点或路径中误用双引号——路径里的字符串字面量要用单引号，比如：$.user.profile.tags[*]，不是 $.user."profile"."tags"。
实操建议：
- 路径末尾加
[*]可展开数组，否则只返回整个数组对象 - 若需标量值（如字符串），在外层套
->>或text强转，否则返回的是jsonb类型 - 注意性能：路径查询无法走 GIN 索引，高频查询建议提前物化关键字段
用 jsonb_to_recordset 展开同构数组并 JOIN
遇到类似 {"orders": [{"id": 1, "amt": 100}, {"id": 2, "amt": 200}]} 这种结构，想把它“摊平”成关系表再关联其他表时，jsonb_to_recordset 比手动 jsonb_array_elements + jsonb_populate_record 组合更简洁。
关键点在于类型声明必须严格匹配 JSON 内字段名和类型；字段名不一致或类型错位会导致整行被丢弃（静默失败）。
实操建议：
- 类型声明里用
id int, amt numeric，不能写id integer—— PostgreSQL 对类型名大小写和别名敏感 - 如果 JSON 数组为空或为
null，函数返回空结果集，不会报错，但 JOIN 会丢失主表记录，必要时补LEFT JOIN LATERAL ... ON true - 避免在 WHERE 中对展开后的字段做复杂计算，容易导致 planner 误判，先过滤再展开更稳
jsonb_path_exists 做条件过滤比 @> 更精准
想查 “所有包含 status=‘active’ 且 priority > 5 的 task”，用 data @> '{"status":"active"}' 会漏掉嵌套在 metadata 下的 status；而 jsonb_path_exists(data, '$.**.status ? (@ == "active")') 能穿透任意层级匹配。
但要注意：路径表达式中的 ? () 是过滤器，不是布尔运算符；多个条件要写成 ? (@.status == "active" && @.priority > 5)，不能拆成两个 jsonb_path_exists OR 连接。
实操建议：
- 用
$.**通配所有后代节点时，性能下降明显，优先限定路径前缀（如$.tasks.[*]） - 路径中比较数字时，确保 JSON 里存的是数字而非字符串，否则
@.priority > 5不生效 - GIN 索引对
jsonb_path_exists无效，高频过滤字段建议冗余到普通列
嵌套查询里别在子查询中反复解析同一 JSONB 字段
一个典型反模式：在 SELECT 列表、WHERE、ORDER BY 里分别用三次 data -> 'user' ->> 'name'。每次调用都触发完整解析，CPU 开销翻三倍，尤其数据量大时延迟陡增。
正确做法是用 LATERAL 或 CTE 提前解析一次，后续复用变量名。例如：
SELECT u.name, u.email
FROM logs l,
LATERAL (SELECT l.data -> 'user' ->> 'name' AS name,
l.data -> 'user' ->> 'email' AS email) u
WHERE u.name IS NOT NULL;
这个写法比在 WHERE 里重复写 l.data -> 'user' ->> 'name' 快得多，而且可读性更强。CTE 在复杂嵌套场景下更清晰，但注意 CTE 在旧版 PG（
最容易被忽略的是：即使用了 LATERAL，如果子查询里又嵌套了 jsonb_path_query，仍可能重复解析——要把最外层 JSON 解析和路径查询拆成两级 LATERAL 才真正省事。
