结论：-> 返回 jsonb 类型，支持链式操作；->> 返回 text 类型，适合拼接或匹配但不可再解析；数组索引从 0 开始，越界返回 NULL，负数取末尾，空数组或路径不存在也返回 NULL。
直接说结论：用 -> 取 JSONB 值（保持类型），用 ->> 取文本值（自动转字符串），数组索引从 0 开始，越界不报错但返回 NULL。
为什么 -> 和 ->> 返回结果类型不同
PostgreSQL 的 JSONB 操作符不是“取值”这么简单，本质是类型转换策略：-> 返回仍是 jsonb 类型，可继续链式操作；->> 强制转为 text，适合拼接、过滤或输出，但不能再用 JSONB 函数处理。
常见错误现象：想对 ->> 结果调用 jsonb_array_length()，报错 “function does not exist”，因为输入是 text 不是 jsonb。
- 要继续解析嵌套结构，必须用
->（比如data -> 'items' -> 0 -> 'name'） - 要跟其他字符串字段拼接或做
LIKE匹配，用->>更方便（比如data ->> 'status'） -
->>对null值返回字符串'null'，而->返回 SQLNULL—— 这点容易在 WHERE 条件里踩坑
提取 JSONB 数组第 N 个元素的正确写法
JSONB 数组用整数索引，但必须用 -> 或 ->> 显式访问，不能省略操作符。常见误区是写成 data -> 'tags'[0]（语法错误）或 data -> 'tags'.0（无效）。
示例：假设表 posts 有列 meta jsonb，其中 meta 包含 {"tags": ["pg", "jsonb", "index"]}：
SELECT meta -> 'tags' -> 0 AS first_tag_jsonb, -- 返回 "pg"（jsonb 类型） meta -> 'tags' ->> 0 AS first_tag_text, -- 返回 pg（text 类型，无引号） meta -> 'tags' ->> 99 AS out_of_bound -- 返回 NULL，不报错
- 索引支持负数：
meta -> 'tags' -> -1取最后一个元素 - 如果数组为空（
[]）或字段不存在，所有操作都返回 NULL - 若不确定路径是否存在，建议先用
jsonb_path_exists()或?操作符预检
WHERE 条件中安全提取并比较数组元素
直接在 WHERE 里用 ->> 做等值判断很常见，但要注意 NULL 和类型隐式转换问题。例如查 “tags 数组里包含 'jsonb'”：
-- ✅ 推荐：显式处理 NULL，且用 jsonb_path_query_first 避免歧义 SELECT * FROM posts WHERE jsonb_path_query_first(meta, '$.tags[*] ? (@ == "jsonb")') IS NOT NULL; <p>-- ⚠️ 谨慎：下面这句在 tags 为 NULL 或非数组时可能误判 SELECT * FROM posts WHERE meta -> 'tags' ->> 0 = 'jsonb';
-
->>在路径不存在时返回 NULL，导致= 'jsonb'整个条件为 UNKNOWN，该行被过滤掉 —— 行为看似合理，但掩盖了数据结构异常 - 若需检查“任意位置等于某值”，优先用
jsonb_path_exists(meta, '$.tags[*] == "jsonb"') - 若确定只查第一个元素，且业务允许忽略空/非法数组，可用
(meta -> 'tags' ->> 0) = 'jsonb'，括号防优先级问题
最易被忽略的是：JSONB 数组索引不支持变量（比如 -> $1），动态下标必须拼进路径表达式或改用 jsonb_array_elements() 配合 WITH ORDINALITY —— 那就不是单操作符能解决的事了。
