别用jsonb_extract_path做动态路径或带条件提取——它只支持静态路径，遇*通配符、过滤表达式或变量路径即报U0600008错误；仅当路径完全固定（如jsonb_extract_path(data,'user','profile','lang')）且类型为jsonb时适用，性能略优但无错误提示。
别用 jsonb_extract_path 做动态路径或带条件的提取——它只认静态路径，一碰通配符、数组下标变量或过滤表达式就报 U0600008 错误。
什么时候该用 jsonb_extract_path 而不是 jsonb_path_query
当你确定路径完全固定，且每级 key 名和数组索引都是写死的字符串时，jsonb_extract_path 是轻量、安全、性能略优的选择。比如从 {"user": {"profile": {"lang": "zh-CN"}}} 中取 user.profile.lang。
- 路径必须拆成多个
text参数：jsonb_extract_path(data, 'user', 'profile', 'lang')，不能拼成一个字符串传进去 - 如果字段是
json类型（非jsonb），必须先强转：data::jsonb，否则函数找不到匹配签名 - 中间任意一级为
null或非对象，整条调用返回null，不会报错，但也不会提示哪一层断了 - 它和
#>行为一致，只是参数更易读；比链式->在深层嵌套时解析开销略小
jsonb_extract_path 报 U0600008 的典型场景
这个错误常见于迁移（如 UGO 工具）或 GaussDB 环境，本质是把不支持的 JSONPath 语法误当成了 jsonb_extract_path 的合法参数。
- 传入
'*.name'或'tags[*]'——*通配符不被接受 - 传入
'hobbies[?(@ == "reading") ]'—— 过滤表达式完全不识别 - 用变量拼路径，比如
jsonb_extract_path(data, 'user', lang_col)——lang_col是列名，不是字面量字符串 - 路径里混用了数字索引和字符串 key，但没统一类型（比如
'items', 0, 'id'是错的，必须全为text，数字得写成'0'）
提取数组元素时，-> 和 ->> 比 jsonb_extract_path 更直接
对 JSONB 数组取第 N 个元素，没必要绕路用 jsonb_extract_path，-> 和 ->> 更自然、更常用。
- 索引从 0 开始，越界返回
null，不报错：meta -> 'tags' -> 0返回"pg"（jsonb类型） -
->>返回纯文本，适合WHERE匹配或拼接：meta ->> 'status'，但注意：若字段为null，->>返回字符串'null'，而->返回 SQLnull - 负数索引有效：
meta -> 'tags' -> -1取最后一个 - 想查“数组里是否存在某值”，别用
->> 0 = 'x'，它只看第一个；改用jsonb_path_query_first(meta, '$.tags[*] ? (@ == "x")')并判非空
容易被忽略的类型陷阱和兼容性细节
最常踩的坑不在语法，而在类型隐式转换和 NULL 处理逻辑上。
-
->>强制转text，结果不能再进jsonb_array_length()这类函数，会报 “function does not exist” -
jsonb_extract_path和#>都要求路径参数是text[]或可变text，传integer会静默失败或报错，必须显式转：jsonb_extract_path(data, 'items', '0'::text) - GaussDB 不支持
jsonb_extract_path的多参变体（即VARIADIC text[]），只认两参数版本，所以 PostgreSQL 上能跑的语句在 GaussDB 可能直接不识别 - 如果业务已依赖动态路径，别硬改函数，优先换用
jsonb_path_query+ 绑定变量，它才是处理真实复杂查询的正解
