jsonb_extract_path仅适用于路径完全静态、层级固定且不含变量的场景；动态路径、数组展开或通配符均不支持，应改用jsonb_path_query等函数。
别用 jsonb_extract_path 提取“深层对象”——它压根不支持动态路径、通配符或嵌套数组展开，强行用只会报 U0600008 错误，尤其在 GaussDB 或 UGO 迁移环境里必炸。
什么时候 jsonb_extract_path 真能用
只适用于路径完全静态、层级固定、不含任何变量或逻辑判断的场景。比如从 {"user": {"profile": {"lang": "zh-CN"}}} 中取 lang，且你 100% 确定字段存在、类型正确、路径不会变。
- 必须写成
jsonb_extract_path(data, 'user', 'profile', 'lang')—— 每个参数都是独立的text字面量，不能拼接、不能变量替换 - 如果字段是
json类型（非jsonb），得先强转：data::jsonb，否则函数签名不匹配 - 中间任意一级是
null、不是对象、或 key 不存在，整条返回null，不报错也不提示哪层断了
为什么一碰“深层”就出问题
所谓“深层”，往往意味着路径不确定：可能藏在数组里、需要遍历、依赖运行时值、或要过滤条件。而 jsonb_extract_path 的设计就是“硬编码路径”，没有解析能力。
- 传
'tags[*]'？报U0600008: jsonb_extract_path 函数不支持 [*] 作为参数 - 传
'hobbies[?(@ == "reading") ]'？同上，直接报错 - 拼接路径如
jsonb_extract_path(data, 'user', lang_col)？语法错误，lang_col是列名，不是text常量 - 想查
{"orders": [{"id": 1}, {"id": 2}]}里所有id？它只能取到整个数组，没法展开
替代方案：该切就切，别硬扛
遇到真实业务里的“深层对象”，优先换函数，而不是调参或绕路。
- 要展开数组 + 取值 → 用
jsonb_path_query(data, '$.orders[*].id')，末尾加[*]自动摊平；结果是jsonb，要文本再套->> - 要判断某路径是否存在（比如监控字段是否被写入）→ 用
jsonb_path_exists(data, '$.metadata.user.id')，比反复#>> '{metadata,user,id}' IS NOT NULL更可靠 - 要穿透任意层级找某个 key（比如所有
status）→ 用$.**.status，但注意性能，前缀越具体越好（如$.tasks.[*].status） - 要把 JSON 数组转成关系行（如订单列表 JOIN 用户表）→ 用
jsonb_to_recordset，但类型声明必须和 JSON 字段名、类型严格一致，错一个就静默丢整行
容易被忽略的细节
很多人试过 jsonb_extract_path 失败后，转头去查文档发现有 #> 和 ->，就以为“差不多”，其实语义差异很大：
-
data#> '{user,profile,lang}'和jsonb_extract_path(data, 'user', 'profile', 'lang')行为接近，但前者路径是text[]，后者是可变参数，更易读但无本质优势 -
data->'user'->'profile'->>'lang'看似直观，但只要user是null或"abc"字符串，后面全链失效，返回null，毫无提示 -
jsonb_path_query返回的是集合（多行），不是单值；在SELECT里直接用会放大主表行数，LATERAL或子查询封装更稳
