视图中JSONB过滤无法利用索引，因谓词不被下推；展开数组须用LATERAL避免报错；提取字段优先用->>而非#>>，并注意类型转换与空值处理。
为什么直接 SELECT * FROM 表 WHERE jsonb_col @> ... 不能直接放进视图里用？
因为视图本身不执行查询优化，它只是保存 SQL 定义。如果你在视图里写 WHERE data @> '{"status": "active"}'，那每次查这个视图都会强制走全表扫描——哪怕你已经在 data 上建了 GIN 索引。PostgreSQL 不会把视图里的谓词下推到基表索引层。所以视图里尽量别带 JSONB 过滤条件，该过滤留给外部查询做。
如何让视图安全地展开 JSONB 数组（比如 specs 或 tags）？
关键在 LATERAL。漏掉它，jsonb_array_elements() 会报错：ERROR: set-returning function called in context that cannot accept a set。这是因为函数需要“按行驱动”，而普通 JOIN 没法提供上下文绑定。
- 必须用
LATERAL jsonb_array_elements(specs) AS spec，不是jsonb_array_elements(specs) - 展开后原表一行可能变多行，
COUNT(*)会虚高，聚合前得先确认是否要DISTINCT ON (id)或加GROUP BY - 如果数组为空或为
NULL，LATERAL默认不生成行；需用LEFT JOIN LATERAL ... ON true保留原行
视图里提取 JSONB 字段时，->> 和 #>> 的选择依据是什么？
->> 是最常用、最直观的文本提取操作符，适合平级键；#>> 专为嵌套路径设计，但路径写错容易静默返回 NULL，调试困难。
- 用
data->>'name'提取顶层字符串，性能好、语义清晰 - 用
data#>>'{address,city}'提取{"address": {"city": "北京"}}中的值，注意路径是字符串数组，不是 JSONPath - 避免在视图里用
->返回 JSONB 对象——下游应用可能误当成字符串，且无法直接参与=或IN比较 - 若路径不确定（如
profile->'contact'->>'phone'可能为NULL），视图里应显式写COALESCE(data#>>'{contact,phone}', '')防止空值污染
视图性能差？先检查你有没有无意中触发隐式类型转换
常见陷阱：视图字段定义为 spec->>'stock'，但你在外部查询里写 WHERE stock = 100。这时 PostgreSQL 会把 stock 当作 text，再隐式转成 int，导致索引失效，甚至报错：operator does not exist: text = integer。
- 视图里明确强转：写成
(spec->>'stock')::int AS stock - 或者统一用文本比较：
WHERE stock = '100'，但要注意排序和范围查询会出问题 - 更稳妥的做法是：视图只做解构和类型归一，不在视图里建计算字段（如
price * qty），留到查询层处理
实际使用中，最容易被忽略的是视图定义里没声明 STABLE 或 VOLATILE 属性，导致 PostgreSQL 无法正确缓存计划；但更常踩的坑，是把本该由应用层承担的 JSON 结构校验（比如确保 tags 总是字符串数组）交给了视图——一旦数据不规范，视图要么报错，要么返回空，排查起来比改应用逻辑还费劲。
