提取嵌套字段应优先用#>>替代->>，避免null陷阱；等值匹配用#>>或->>，数值比较需显式类型转换；存在性检查用@>配合GIN索引；数组筛选慎用jsonb_array_elements，推荐NOT EXISTS子查询或预计算生成列。
用 -> 和 ->> 提取嵌套字段再过滤
直接用操作符访问嵌套路径是最常见也最容易出错的方式。比如要查 data->'user'->>'age' 等于 '30' 的记录，必须注意：路径中任意一级为 null 或不存在，整个表达式就返回 null，而 null = '30' 结果是 unknown，不匹配任何行。
常见错误是写成 data->'user'->'age' = '30' —— 这里用的是 ->，返回的是带双引号的 JSON 字符串 "30"，和纯字符串 '30' 比较永远为 false。
- 要用
->>获取去引号后的文本值，适合等值或 LIKE 匹配 - 数字或布尔值需显式转换：
(data->'profile'->>'age')::INT > 30 - 如果不确定某层是否存在，加
IS NOT NULL判断：data->'user'->>'age' IS NOT NULL AND (data->'user'->>'age')::INT > 25
用 #> 和 #>> 按完整路径定位
#> 和 #>> 是路径操作符，比连续嵌套的 -> 更安全、更高效。它们把路径当作数组传入，避免中间层级缺失导致整个表达式失效（虽然结果仍是 null，但语义更清晰）。
例如查 address.city 为 '北京' 的记录，写成 data #>> '{address, city}' = '北京' 比 data->'address'->>'city' 更推荐，尤其在路径深度 > 2 时。
-
#>返回 JSONB 对象，#>>返回文本，和->/->>的对应关系一致 - 路径数组里不能有变量，必须是字面量，如
'{items, 0, name}'可以，但不能拼接字符串 - 对深层嵌套结构，
#>>能减少解析开销，EXPLAIN 显示计划更倾向走索引扫描
用 @> 判断嵌套对象是否存在
当目标是“包含某个子结构”而非提取具体值时，@> 是最高效的判断方式。它不解析整个 JSONB，只做存在性检查，底层用 GIN 索引加速。
比如查 details 字段中包含 {"product": {"category": "electronics"}} 的订单，直接写 details @> '{"product": {"category": "electronics"}}' 即可。
-
@>右侧必须是合法 JSONB 字面量，不能是变量或表达式 - 它匹配的是“子集关系”，不要求完全相等，只要左侧包含右侧所有键值对即可
- 配合 GIN 索引（
CREATE INDEX idx_details ON orders USING GIN (details)）后，查询耗时可从 85ms 降到 8ms - 不能用于数组元素的“全部满足”逻辑——那是
jsonb_array_elements的场景
处理 JSONB 数组时避免全表扫描
对数组内每个元素做条件筛选，容易误用 jsonb_array_elements() 导致性能崩盘。这个函数会把一行炸成多行，如果没加限制，可能生成数万中间行。
真正需要“所有元素都满足某条件”时（比如 attributes 数组里每个 attribute_name 都等于 'Some_name'），得用 NOT EXISTS + 子查询，而不是简单 WHERE。
- 先用
jsonb_array_elements(data->'attributes')展开，再在外层排除存在不匹配项的记录 - 缺失键要用
COALESCE(elem->>'attribute_name', '')防止null干扰逻辑 - 更轻量的做法是预计算生成列：
ALTER TABLE t ADD COLUMN attr_names TEXT[] STORED AS (ARRAY(SELECT jsonb_array_elements_text(data->'attributes')->>'attribute_name'));，然后走普通 B-Tree 索引
null 陷阱、以及在没索引时根本看不出慢在哪——等数据量上到百万级，一个没加索引的 ->> 查询可能拖垮整张表。 
