postgresql 16 中首选 jsonb_path_query 提取深层嵌套字段，->/->> 适用于单层快速取值，jsonb_to_recordset 摊平同构数组需严格匹配类型声明。
直接说结论：在 PostgreSQL 16 中，jsonb_path_query 是提取多层嵌套字段的首选，-> 和 ->> 适合单层或已知结构的快速取值，而 jsonb_to_recordset 是摊平同构数组最简洁的方式——但类型声明必须一字不差。
用 jsonb_path_query 替代链式 -> 提取深层嵌套字段
当字段藏在三层以上（比如 {"meta": {"user": {"profile": {"id": 123}}}}），硬写 data->'meta'->'user'->'profile'->>'id' 很容易因某一级是 null 或类型不对而静默返回 NULL，且无法做条件过滤。
- 路径必须以
$开头，数组末尾加[*]才能展开：例如$.meta.user.profile.id返回单个值，$.meta.user.tags[*]返回每个 tag 行 - 字符串字面量用单引号：
$.user.profile.lang ? (@ == 'zh-CN')，双引号会报错 - 返回的是
jsonb类型，要文本值得再套->>或::text，否则WHERE匹配会失败 - 不走 GIN 索引，高频查询别直接放
WHERE里，先物化到普通列更稳
用 -> 和 ->> 取数组元素时索引从 0 开始且越界不报错
对 JSONB 数组取第 N 个元素，别绕路用 jsonb_extract_path；-> 和 ->> 更直接、更常用。
-
meta->'tags'->0返回"pg"（jsonb类型），还能继续链式解析 -
meta->'tags'->>0返回pg（text类型），适合拼接或LIKE匹配 - 负数索引取末尾：
meta->'tags'->>-1是最后一个元素 - 空数组、路径不存在、索引越界都返回 SQL
null，不是错误；但->>对null字段会返回字符串'null'，WHERE里容易误判 - 别写
meta->'tags'[0]或meta->'tags'.0，语法错误
用 jsonb_to_recordset 摊平同构数组时类型声明必须严格匹配
面对 {"orders": [ {"id": 1, "amt": 100}, {"id": 2, "amt": 200} ]} 这类结构，想转成关系行再 JOIN，jsonb_to_recordset 比手动 jsonb_array_elements + jsonb_populate_record 更简洁。
- 类型声明里写
id int, amt numeric，不能写id integer——PostgreSQL 对类型名大小写和别名敏感，错一个字段整行丢弃（静默） - 数组为空或为
null时函数返回空结果集 - 别用
jsonb_extract_path做动态或带条件的提取，它只认死路径，一碰变量、通配符、过滤表达式就报U0600008错误，尤其在 GaussDB 或 UGO 迁移环境里很常见
最常被忽略的一点：所有 JSONB 路径操作（包括 ->、->>、#>、jsonb_path_query）对中间任意一级是 null 或非对象的情况，都直接返回 null，没有任何提示。想排查哪层断了，得靠 jsonb_typeof() 逐级查，而不是靠猜。
