->返回jsonb类型，->>转text；#>安全访问嵌套路径，@>是布尔包含判断而非路径提取；GIN索引仅加速存在性检查和键值匹配，不加速->/->>等值查询。
PostgreSQL JSONB 路径操作符怎么选：-> vs ->> vs #> vs @>
直接说结论：-> 返回 jsonb 类型，->> 强制转成 text；#> 是嵌套路径（数组/对象混合）安全访问，@> 是“是否包含”语义的布尔判断——不是路径查询，别误用。
常见错误是把 @> 当成路径提取工具，结果写 WHERE data @> '{"user":{"id":123}}' 却想取值，实际它只返回 true/false，没法 SELECT 出字段。
-
->适合后续还要继续链式取子字段，比如data->'user'->'profile'->'age' -
->>适合直接拿字符串做比较或拼接，比如WHERE data->>'status' = 'active' -
#>必须传数组路径，如data #> '{user, addresses, 0, city}'，越界不报错，返回NULL -
@>只能用于WHERE或JOIN ON，不能出现在SELECT列表里取值
GIN 索引对 JSONB 路径查询到底加速哪些操作？
GIN 索引不会加速任意路径表达式——它只加速「存在性检查」和「键值匹配」，且必须用特定操作符。最常被误解的是：加了 jsonb_path_ops 索引后，data->>'name' = 'Alice' 依然走不了索引。
真正能走 GIN 索引的写法只有这几种：
-
data ? 'name'（存在 key） -
data @> '{"name":"Alice"}'（顶层对象包含） -
data @> '{"tags":["vip"]}'（数组元素匹配） -
data #> '{user,id}' IS NOT NULL（路径存在性，需jsonb_path_ops+jsonb_path_exists函数配合索引）
注意：jsonb_path_ops 不支持 -> 和 ->> 的等值查询索引；要加速这类场景，得建函数索引，比如 CREATE INDEX idx_user_name ON tbl ((data->>'name'))。
为什么 data->'user'->'id' 加了 GIN 索引还是慢？
因为 GIN 索引不解析嵌套路径——它把整个 jsonb 值当做一个黑盒，只索引键名和顶层结构。你写 data->'user'->'id'，PostgreSQL 无法把这串路径映射到 GIN 索引的任何条目上。
可行解只有两个：
- 建表达式索引：
CREATE INDEX idx_user_id ON tbl ((data->'user'->>'id'))（注意用->>得到 text，适合等值查询） - 或者提前物化字段：
ALTER TABLE tbl ADD COLUMN user_id INT GENERATED ALWAYS AS ((data->'user'->>'id')::INT) STORED，再对user_id建普通 B-tree 索引
后者在频繁按该字段查询、且 JSON 结构稳定时更可靠；前者维护成本低，但类型转换失败会出错（比如 'id' 是字符串但你强转 ::INT）。
JSONB 路径查询 + GIN 索引的兼容性陷阱
PostgreSQL 12+ 才支持 jsonb_path_ops 索引对 #> 路径的存在性判断加速（需配合 jsonb_path_exists() 函数）；11 及以前版本，#> 完全无法利用 GIN 索引。
另一个坑是数据迁移：如果旧表用 json 类型，改成 jsonb 后虽然语法兼容，但 GIN 索引必须重建——json 类型不支持 GIN 索引，强行创建会静默失败或报错。
还有字符集问题：->> 提取的 text 默认继承数据库编码，但若 JSON 内含 \uXXXX 转义，PostgreSQL 会自动解码；而某些客户端（如老版本 JDBC）可能没正确处理 UTF-8 解码，导致查出来乱码——这不是索引问题，是链路编码没对齐。
