最干净方式是用 jsonb_to_recordset 或 jsonb_path_query 拆嵌套 json 建视图；前者适用于结构固定数组，需显式声明字段名与类型且严格匹配；后者适合多层/动态路径，须注意单引号路径、[*] 展开及类型转换；建视图前须处理字段缺失、类型转换、索引缺失和路径硬编码等兼容性陷阱。
直接用 jsonb_to_recordset 或 jsonb_path_query 将嵌套 JSON 拆成行，再用 CREATE VIEW 包一层——这是最干净、可复用、不污染原表的方式。别在应用层拼 SQL，也别用子查询反复解析同一字段。
用 jsonb_to_recordset 展开同构数组并建视图
适合结构固定、字段名和类型已知的 JSON 数组，比如 {"orders": [{"id": 1, "total": 99.9}, {"id": 2, "total": 149.5}]} 这类数据。
- 必须显式声明返回字段名和类型，且大小写、拼写、顺序必须与 JSON 内完全一致，否则整行静默丢弃
- 类型声明里写
id int，不能写id integer（PostgreSQL 对类型别名敏感） - JSON 数组为空或为
null时，函数返回空结果集，主表记录会丢失；加LEFT JOIN LATERAL ... ON true可保主表行不丢 - 示例：
CREATE VIEW order_items AS SELECT t.id AS user_id, o.id, o.total FROM users t, LATERAL jsonb_to_recordset(t.profile->'orders') AS o(id int, total numeric);
用 jsonb_path_query 提取多层嵌套字段并建视图
当目标字段藏在任意深度（如 $.metadata.user.settings.theme），或路径不固定、含通配符时，jsonb_path_query 比链式 -> 更可靠。
- 路径中字符串字面量必须用单引号，比如
'$.user.settings.theme'，写成双引号会报错 - 末尾加
[*]才能展开数组，否则只返回整个数组对象；若要标量值，外层必须套->>或::text -
$.**能穿透任意层级，但性能差，高频查询务必限定前缀（如$.data.items[*]） - 示例：
CREATE VIEW user_themes AS SELECT id, jsonb_path_query(profile, '$.user.settings.theme') #>> '{}' AS theme FROM users WHERE jsonb_path_exists(profile, '$.user.settings.theme');
建视图前必须处理的三个兼容性陷阱
视图一旦创建，底层 JSON 结构变动会直接导致查询失败或返回空，这些坑常被忽略：
-
jsonb_to_recordset对字段缺失零容忍：哪怕只有一条记录缺total字段，整行就消失；可用COALESCE+to_jsonb()预填充默认值兜底 -
jsonb_path_query返回的是jsonb类型，不是文本或数字，直接ORDER BY会按 JSON 字典序排，不是数值大小；必须显式转类型，如::numeric - GIN 索引对视图无效——如果视图里用了
@>或?，记得在原表对应路径上单独建索引，例如：CREATE INDEX idx_profile_theme ON users USING GIN ((profile #> '{user,settings}'));
最易被忽略的一点：视图定义里所有 JSON 路径都是硬编码的，后续 JSON Schema 变更（比如把 theme 改成 ui_theme）不会触发任何告警，查询突然变空才暴露问题。建议把关键路径提取成注释常量，或用元数据表管理 schema 版本。
