postgresql 15 中更新 jsonb 嵌套字段最稳妥方式是 jsonb_set()，它只修改指定路径、不丢失同级字段；需注意路径为 text[]、值为 jsonb 类型、缺失路径需显式设 create_missing=true。
直接用 jsonb_set() 更新嵌套路径，别用 || 拼接
PostgreSQL 15 中更新 JSONB 嵌套字段最稳妥的方式是 jsonb_set()，不是用 || 合并或 #> 提取后重赋值。后者容易丢失同级其他字段，尤其当路径不存在时会静默失败或返回 null。
比如想把 data->'user'->'profile'->'age' 改成 35：
UPDATE users
SET data = jsonb_set(data, '{user,profile,age}', '35')
WHERE id = 123;
关键点：
-
jsonb_set()第二个参数必须是text[]（如'{user,profile,age}'），不能写成字符串'user.profile.age' - 第三个参数必须是
jsonb类型，所以数字要加单引号转成字符串再由 PostgreSQL 自动转jsonb，或显式写to_jsonb(35) - 默认行为是路径不存在时创建（
create_missing = true），设为false可跳过更新
处理数组内对象的嵌套更新要先定位索引
JSONB 数组里改某个对象的字段，得先知道下标。PostgreSQL 不支持类似 $.items[?(@.id==123)].status 的 JSONPath 写法（15 版本原生不支持 JSONPath 更新，仅查询可用）。
常见做法是：用 jsonb_array_elements() 展开 + WITH ORDINALITY 记录位置，再拼回数组。但更轻量的是用 jsonb_set() 配合已知索引：
UPDATE orders SET items = jsonb_set( items, ARRAY['1', 'status'], -- 把第 2 个元素（索引从 0 开始）的 status 改掉 '"shipped"', true ) WHERE id = 456;
注意：
- 数组索引必须是字符串（
'1'），不是数字1 - 如果不确定索引，得先用子查询找位置，例如
SELECT idx FROM jsonb_array_elements(items) WITH ORDINALITY AS e(elem, idx) WHERE elem->>'id' = '123' - 对数组整体操作性能较差，频繁更新建议把数组项拆到关联表
更新时避免意外覆盖顶层结构
错误写法：SET data = data || '{"user": {"profile": {"age": 35}}}' —— 这会把整个 user 对象替换成新对象，丢掉原来 user->'settings' 或 user->'avatar' 等字段。
正确思路是只触达目标路径：
- 用
jsonb_set()是最安全的，它只改指定路径，不动其他 - 若需多层合并（比如更新
user.profile下多个字段），可嵌套调用：jsonb_set(jsonb_set(data, '{user,profile,age}', '35'), '{user,profile,city}', '"Beijing"') - 或者先提取父对象，合并后再写回：
jsonb_set(data, '{user,profile}', (data#>'{user,profile}') || '{"age": 35, "city": "Beijing"}')，但要注意#>返回jsonb，||才能生效
空值和缺失路径的边界情况要显式处理
jsonb_set() 在路径中间某段为 null 时，默认不创建（除非 create_missing = true）。比如 data 是 {"user": {}}，执行 jsonb_set(data, '{user,profile,age}', '35') 不会报错，但也不会写入——因为 profile 不存在，且 create_missing 默认是 false。
解决方法：
- 强制创建缺失层级：
jsonb_set(data, '{user,profile,age}', '35', true) - 先检查路径是否存在：
data ? 'user' AND data->'user' ? 'profile'，再决定是否更新 - 用
COALESCE提供默认空对象：jsonb_set(COALESCE(data->'user'->'profile', '{}'), '{age}', '35')，但这只是局部操作，需配合外层jsonb_set写回
真正难的不是语法，而是想清楚“这个字段在业务里是否允许为空”“上游数据会不会突然少一层”，这些逻辑得在 SQL 外围或应用层兜底。
