jsonb_set的create_missing参数必须显式设为true才能创建缺失路径，否则路径不存在时字段变null；路径用数组而非点号，字符串值需双引号包裹并转jsonb类型，更新数组用非负整数下标，设null需用'null'::jsonb，避免字符串拼接导致json非法。
PostgreSQL 中 jsonb_set 的 create_missing 参数必须显式设为 true
不设或设 false，jsonb_set 就不会创建缺失的中间层级，比如想更新 data.user.profile.theme，但 data 是 NULL 或 user 不存在，结果整个字段会变成 NULL，而不是补出空对象。这和 MySQL 的 JSON_REPLACE 行为一致，但多数人预期的是“自动建路径”。
正确写法必须带第四个参数：jsonb_set(data, '{user,profile,theme}', '"dark"', true)。注意路径用数组形式，不是点号；字符串值要加双引号包裹，且整体作为 jsonb 字面量（即 '"dark"'::jsonb 或直接 "dark" 加类型推导）。
- 如果原字段是
json类型（非jsonb），得先转：jsonb_set(data::jsonb, ...)，否则报错 - 更新数组元素要用下标整数，如
{items, 0, name}；负数下标（如-1）不支持，会直接报错 - 想把某个键设为
NULL值，得写'null'::jsonb，不是NULL关键字，也不是字符串'"null"'
更新值类型不匹配会导致静默存成字符串
比如你想把 count 字段设为整数 42，但写了 '42'（带单引号的字符串字面量），PostgreSQL 就真把它当字符串存进去。后续做数值比较或聚合就会出错——ext->>'count' 返回字符串，(ext->>'count')::int 可能失败，而 ext->'count' 返回的是 jsonb 字符串类型，不是数字。
安全做法是用 to_jsonb() 包一层计算值：to_jsonb((ext#>>'{stats,hits}')::int + 1)。原始值是字符串时，先转类型再包；如果是常量数字，直接写 42 即可（PostgreSQL 能自动推导为 jsonb 数字）。
-
'42'→ 存成字符串"42" -
42→ 存成数字42 -
to_jsonb(42)→ 明确存成数字42 -
'true'→ 存成字符串"true"；true或to_jsonb(true)→ 存成布尔true
别用字符串拼接替代 jsonb_set，尤其在生产环境
有人图快写 ext || '{"new_key": "val"}'，这看似能加字段，但有严重隐患：如果原 ext 里已有 new_key，会被覆盖；如果原值是 NULL，结果还是 NULL；更危险的是，若字段含特殊字符（换行、反斜杠、Unicode 控制符），拼接后 JSON 结构直接非法，后续所有 -> 操作都可能返回 NULL 或报错。
jsonb_set 是原子性局部更新，只动指定路径，其余结构完全保留。而拼接是“重建整个值”，等价于 to_jsonb(jsonb_each_text(ext)) 再合并，既慢又不可靠。
- 添加多个字段？用多次
jsonb_set链式调用，或先用jsonb_build_object构造子对象再jsonb_set - 想删一个键再加一个？用
ext - 'old_key' || '{"new_key": "v"}'可行，但仅限简单场景；深层嵌套仍得靠jsonb_set - 批量更新多行？确保 WHERE 条件能走索引，否则大表上
jsonb_set会触发全表重写，I/O 压力陡增
jsonb 类型本身比 json 更适合频繁更新
如果你还在用 json 类型存数据，每次 jsonb_set 都得先隐式转 jsonb，改完再转回 json，性能差一截。而 jsonb 是二进制格式，更新时数据库直接操作解析后的树结构，不用反复解析文本。
代价是存储略大、写入稍慢（因要预解析），但日常业务中查询和更新频率远高于写入，所以几乎总是该选 jsonb。另外，只有 jsonb 支持 GIN 索引，像 ext @> '{"status": "active"}' 这种查询才能真正加速。
- 已有
json字段要迁移？ALTER TABLE t ALTER COLUMN ext TYPE jsonb USING ext::jsonb - 新建表？直接定义为
ext jsonb，别犹豫 - 旧数据含重复 key（如
{"a":1,"a":2}）？jsonb会自动去重，只留最后一个值，这是设计行为，不是 bug
实际更新中最容易被忽略的，是路径不存在时的默认行为——它不报错也不提示，就默默什么都不做（或清空字段），直到下游应用读到 NULL 才暴露问题。务必确认 create_missing 参数、值类型、以及字段本身的类型是否匹配。
