jsonb_extract_path静默返回NULL而非报错，路径须为text[]数组（如'user','profile','name'），不可传字符串；无法区分字段缺失与值为null，建议先用jsonb_path_exists校验或COALESCE处理。
JSONB_EXTRACT_PATH 会返回 NULL 而不是报错，这是设计行为
PostgreSQL 的 jsonb_extract_path 在路径不存在时**静默返回 NULL**，而不是抛出错误。这点和 -> 或 ->> 类似，但容易让人误以为“没取到就是写错了路径”，其实可能只是数据里压根没那个字段。
实操建议：
- 先用
jsonb_path_exists检查路径是否存在，比如jsonb_path_exists(data, '$.user.profile.age') - 对关键字段做
COALESCE(..., 'default')或WHERE ... IS NOT NULL过滤，避免 NULL 透传影响后续计算 - 注意：空 JSON 对象
{}和缺失字段在jsonb_extract_path下表现一致，都导致 NULL —— 无法区分“有但为空”和“根本没这个 key”
路径参数必须是 text[] 数组，不能直接传字符串
jsonb_extract_path 第二个及之后的参数是可变个数的 text，但底层按 text[] 处理。如果你写成 jsonb_extract_path(data, 'user.profile.name')，PostgreSQL 会把它当作**单个字符串键名**，即试图找顶层 key 叫 user.profile.name 的字段（而不是逐层下钻），结果几乎总是 NULL。
正确写法必须拆成数组元素：
SELECT jsonb_extract_path(data, 'user', 'profile', 'name') FROM users;
常见错误场景：
- 从应用层拼接路径时，误把
"user.profile.name"当作一个参数传入 - 用变量传路径，却没展开成多个参数，例如
jsonb_extract_path(data, path_array)不合法；要用jsonb_extract_path(data, VARIADIC path_array) - 路径含数字索引（如数组第 0 项），必须用字符串：
'items', '0', 'id'，不能写'items', 0, 'id'（类型不匹配）
提取数组元素要小心索引越界和类型混用
JSONB 中数组访问用字符串数字（如 '0'），但越界不会报错，而是返回 NULL。比如 jsonb_extract_path('[{"a":1}]', '1', 'a') 返回 NULL，而非提示“索引 1 超出范围”。
更隐蔽的问题是：如果目标位置是数组，但路径末尾没指定索引，jsonb_extract_path 会返回整个子数组（JSONB 类型），而不是报错或自动展开：
SELECT jsonb_extract_path('{"list": [1,2,3]}', 'list'); -- 返回 [1,2,3]（jsonb）若你期望的是第一个元素，得显式加索引：
SELECT jsonb_extract_path('{"list": [1,2,3]}', 'list', '0'); -- 返回 1（jsonb）注意：jsonb_extract_path 返回仍是 jsonb 类型，如需文本值，得再套 ->> 或 jsonb_extract_path_text。
jsonb_extract_path_text 更适合取字符串值，但丢失类型信息
如果你明确只要字符串结果（比如日志字段、用户名），用 jsonb_extract_path_text 更省事，它自动把结果转成 text，不用再 ::text 或 ->>。
但它有代价：
- 数值
42、布尔true、null 都被转成对应字符串'42'、'true'、'null'，原始类型丢失 - 遇到非 UTF-8 字符或控制字符可能截断或报错（取决于客户端编码）
- 性能略低于
jsonb_extract_path，因为多了一次序列化
典型适用场景：生成报表字段、拼接 SQL WHERE 条件、写入 text 列。不适合做数值计算或类型敏感判断。
实际使用中最容易被忽略的是路径参数的“拆分”要求和 NULL 的双重含义——它既是缺失值的信号，也是合法 JSONB null 值的表示，而 jsonb_extract_path 本身不做区分。
