jsonb_extract_path返回JSONB类型，需显式转text才能用于字符串比较；路径必须全为text字面量，动态路径需用VARIADIC ARRAY构造；不支持数组下标，无法走GIN索引，性能低于->操作符。
JSONB_EXTRACT_PATH 会返回 JSONB 类型，不是文本
直接用 jsonb_extract_path 拿到的值仍是 jsonb 类型，哪怕原始字段是字符串。比如 {"name": "Alice"} 中提取 name，结果是 "Alice"（带双引号的 JSON 字符串），不是 Alice（纯文本）。这容易导致 WHERE 条件匹配失败或排序异常。
实操建议：
- 需要做字符串比较或拼接时，必须显式转类型：
jsonb_extract_path(data, 'name')::text - 若路径不存在，函数返回
NULL（不是空 JSON），可配合COALESCE提供默认值 - 注意：
jsonb_extract_path不支持数组下标语法（如'users', '0', 'email'），要提取数组元素得用jsonb_array_elements配合->操作符
路径参数必须全为 text，不能传变量名或表达式直接拼接
这个函数签名是 jsonb_extract_path(jsonb, VARIADIC text[])，所有路径段都得是 text 字面量或能隐式转为 text 的值。常见错误是试图写成 jsonb_extract_path(data, col_name)——这里 col_name 是表中某列，PostgreSQL 会报错 “function cannot be called with a column reference”。
实操建议：
- 动态路径只能靠拼接数组实现，例如：
jsonb_extract_path(data, VARIADIC ARRAY['user', 'profile', 'age']::text[]) - 如果路径来自另一张表或 CTE，先用
ARRAY_AGG或STRING_TO_ARRAY构造成 text 数组再传入 - 避免在 WHERE 子句里高频调用该函数——它无法走 GIN 索引；想高效查某个 key，应建
jsonb_path_ops索引并用@>或?操作符
和 -> / ->> 操作符的区别：要不要自动展开
jsonb_extract_path 和 -> 行为一致（返回 jsonb），而 ->> 才等价于 jsonb_extract_path(...)::text。但关键差异在于：操作符只支持单层路径，函数支持多层嵌套且可变量传参。
实操建议：
- 静态路径优先用
data -> 'a' -> 'b' ->> 'c'，更简洁、可读性强，且查询计划器优化更好 - 需要根据参数动态决定深度（比如 API 接收字段路径字符串），才用
jsonb_extract_path+STRING_TO_ARRAY(path_str, '.')::text[] - 对性能敏感场景，
->比jsonb_extract_path快约 10–15%，因为少一次函数调用开销和数组构造
嵌套 null 和空对象处理容易误判
当路径中间某层是 null（如 {"user": null}）或空对象（{"user": {}}），jsonb_extract_path(data, 'user', 'name') 统一返回 NULL，无法区分“路径不存在”、“值为 null”、“对象为空”。这对业务逻辑可能造成歧义。
实操建议：
- 检查是否存在而非是否为空，用
jsonb_path_exists(data, '$.user.name')（需 PG 12+） - 要区分空对象和缺失字段，得拆成两步：
data ? 'user'判断 key 存在，再data -> 'user' ? 'name' - 生产环境建议统一约定：JSONB 字段中不存
null值，用缺失字段代替，减少歧义
::text 解决，后者得老老实实构造数组。别图省事用字符串拼接 SQL，PostgreSQL 对 JSONB 路径解析很严格。 
