->返回json类型（保留结构），->>返回text类型（去引号）；需链式解析选->，需字符串操作或比较则用->>并显式类型转换。
用 -> 和 ->> 提取 JSON 字段的键值
PostgreSQL 的 JSON 操作符里，-> 返回 json 类型（保留引号和结构），->> 返回 text 类型（自动去掉引号、转义）。选哪个取决于后续是否还要继续解析嵌套字段。
比如表 orders 有个 data 列存着 {"user_id": 123, "status": "shipped", "items": [{"name": "book"}]}：
SELECT data->'user_id' AS user_id_json,
data->>'status' AS status_text
FROM orders;
结果中 user_id_json 是 123（但类型是 json，带括号显示），status_text 是纯字符串 shipped。
- 如果下一步要参与字符串拼接或
WHERE匹配，优先用->> - 如果还要对
items数组做json_array_elements()，就得用->保持类型 - 对不存在的键，两者都返回
NULL，不会报错
处理 JSON 中的数字、布尔、null 值要小心类型转换
->> 总是返回 text，哪怕原始值是 true、42 或 null。直接拿它跟数字或布尔比较会隐式转换失败，尤其在 WHERE 条件里容易漏数据。
常见错误写法：WHERE data->>'score' > 80 —— 这是在做字符串比较（"9" > "80" 成立，但语义错误）。
- 数字字段：显式转类型，如
(data->>'score')::numeric或(data->>'score')::int - 布尔字段：用
(data->>'active')::boolean，注意 JSON 里的true/false小写才可转 - null 值判断：JSON 的
null经->>后是字符串"null"，不是 SQL 的NULL；想区分原生 null 和字符串 "null"，得用->+IS NULL
从 JSON 数组中取第一个元素或遍历所有项
如果字段是数组，比如 data->'tags' 是 ["pg", "sql", "json"]，不能直接 ->'tags'->>0（语法错误）；必须先解包成行集。
取第一个标签的正确方式：
SELECT (data->'tags')::json->>0 AS first_tag FROM orders WHERE json_typeof(data->'tags') = 'array';
更通用的做法是用 json_array_elements() 配合 LATERAL：
SELECT t.tag
FROM orders o,
LATERAL json_array_elements_text(o.data->'tags') AS t(tag)
LIMIT 1;
-
json_array_elements()返回 json 类型，json_array_elements_text()直接返回 text，省去->> - 记得加
WHERE json_typeof(...) = 'array'，否则遇到非数组字段会报错 - 没有索引支持数组内搜索，大数据量时考虑把常用数组元素冗余为普通列
为什么 #>> 路径操作符比嵌套 -> 更可靠
当要取深层嵌套值，比如 data->'meta'->'geo'->>'city'，中间任意一层为 null 或缺失，整条链就返回 NULL —— 看似安全，但容易掩盖字段结构不一致的问题。
#>> 是路径寻址操作符，接受文本路径数组，容错更强：
SELECT data#>>'{meta, geo, city}' AS city,
data#>>'{meta, contact, email}' AS email
FROM orders;
- 路径写成
{a,b,c}格式，自动跳过null中间节点，只要最终路径存在就返回值 - 比连写多个
->更易读、少出错，尤其在动态字段名场景下可拼接路径数组 - 注意：
#>>对不存在路径也返回NULL，不报错，但无法区分“路径不存在”和“值就是 null”
深层嵌套提取真正难的不是语法，而是确认上游数据结构是否稳定；一旦 meta 有时是对象、有时是字符串，所有路径操作都会静默失效。上线前务必用 json_typeof() 抽样检查字段类型。
