jsonb_extract_path将缺失字段与显式null统一返回NULL，无法区分语义；路径参数全为text类型，数组索引需写'1'而非1；key名严格字符串匹配；深层嵌套性能差，建议物化或改用jsonb_path_exists。
JSONB_EXTRACT_PATH 会把 null 当成缺失字段处理
PostgreSQL 的 jsonb_extract_path 在路径中任一中间键不存在时，直接返回 NULL，而不是报错。这点和 JavaScript 的可选链不同——它不区分“值为 null”和“路径不存在”。比如 { "a": { "b": null } } 和 { "a": {} } 在用 jsonb_extract_path(data, 'a', 'b') 时都返回 NULL，无法区分语义。
实操建议：
- 如果需要区分缺失与显式 null，先用
jsonb_path_exists或jsonb_path_query_first配合$ ? (@.a.b != null)这类路径表达式判断存在性 - 对关键字段，建议组合使用
COALESCE+ 默认值，例如：COALESCE(jsonb_extract_path(data, 'user', 'profile', 'email')::text, 'unknown@example.com') - 注意：
jsonb_extract_path返回类型是jsonb，不是文本；若需字符串，必须显式转成::text，否则可能在拼接或比较时报错
数组索引要写成字符串，不能写数字
提取 JSONB 数组中第 2 个对象的 name 字段，路径参数必须写成 'items', '1', 'name'，而不是 'items', 1, 'name'。因为 jsonb_extract_path 所有参数都是 text 类型，传整数会触发隐式转换，但 PostgreSQL 8.4+ 后已禁用这种转换，直接报错：function jsonb_extract_path(jsonb, integer, text) does not exist。
常见错误场景：
- 从应用层动态拼路径时，误把
i（整数）直接塞进参数列表 - 用
generate_subscripts得到下标后，忘记::text转换 - 嵌套数组如
[{"tags": ["a","b"]}]，想取第一个元素的第二个 tag：路径是'0', 'tags', '1'，全部用单引号包裹
带空格或特殊字符的 key 必须原样传入
如果 JSONB 中有 key 是 "first name" 或 "@type"，调用 jsonb_extract_path 时必须字面量传 'first name' 或 '@type'，不能加引号转义、不能驼峰化、也不能去符号。PostgreSQL 不做 key 名标准化，完全按字符串精确匹配。
容易踩的坑：
- 前端传来的字段名含空格，后端解析后没保留原始字符串，导致路径匹配失败
- 用
jsonb_object_keys列出 key 后手动拼路径，结果因不可见字符（如全角空格、零宽空格）导致不等价 - PostgreSQL 14+ 支持
jsonb_path_query的$.key."first name"语法，但jsonb_extract_path始终只认纯字符串参数，别混用
深层嵌套性能差，超 5 层建议预计算
jsonb_extract_path 每次调用都要从根节点递归遍历，深度越大开销越明显。实测在 100 万行数据上提取 'a','b','c','d','e','f'（6 层）比提取 'a','b' 慢 3–4 倍，且无法走任何索引。
优化建议：
- 高频查询的深层字段，用
GENERATED ALWAYS AS列物化，例如：email TEXT GENERATED ALWAYS AS (data#>>'{user,contact,email}') STORED - 避免在 WHERE 条件里直接写多层
jsonb_extract_path，改用jsonb_path_exists(data, '$.user.contact.email == "x"')，后者能利用jsonb_path_ops索引 - 如果只是偶尔查、但结构固定，考虑用
jsonb_to_record一次性展开，比反复调用extract_path更快
深层嵌套字段提取最麻烦的从来不是语法，而是 null 处理逻辑和路径拼写的隐蔽不一致——尤其当数据来自多个外部系统时，同一个字段名大小写、空格、编码都可能不同。
