JSON_SET强制新增或覆盖字段，JSON_REPLACE仅更新已有字段；误用JSON_REPLACE新增字段会导致静默失败，需据场景选函数。
MySQL 5.7+ 的 JSON_SET 和 JSON_REPLACE 区别在哪？
更新 JSON 字段里的指定节点，核心就看你要“插入不存在的路径”还是“只改已存在的键”。JSON_SET 会强制写入，路径不存在就自动创建；JSON_REPLACE 只改已有键，路径不存在直接忽略——不报错也不生效。
常见错误是用 JSON_REPLACE 去更新嵌套对象里新字段，结果发现没变化。比如：JSON_REPLACE(json_col, '$.user.profile.avatar', 'new.jpg')，如果 profile 对象本身不存在，这条语句就静默失败。
- 想安全兜底（确保字段存在）→ 用
JSON_SET - 只想改已有结构、避免意外新增 → 用
JSON_REPLACE - 要删键再加新键 → 得组合
JSON_REMOVE+JSON_SET，不能只靠一个函数
PostgreSQL 中用 jsonb_set 更新深层嵌套节点
PostgreSQL 的 jsonb_set 更灵活，但路径参数必须是 text 数组，不是 JSONPath 字符串。比如更新 {"a": {"b": {"c": 1}}} 里的 c，得写成：jsonb_set(data, ARRAY['a','b','c'], '2'::jsonb)。
容易踩的坑：路径数组里任何一级为 null 或 key 不存在，整个操作返回原值（不报错），且不会自动创建中间对象。想自动补全就得自己套多层 COALESCE 或提前用 jsonb_set 初始化父级。
- 路径必须是
text[]，不能传字符串如'$.a.b.c' - 第三个参数必须是
jsonb类型，'"str"'::jsonb或to_jsonb(value) - 第四个参数（默认
false）设为true才允许在路径不存在时创建中间层级
SQLite 3.38+ 的 json_set 不支持通配符和条件更新
SQLite 的 json_set 看似简单，但只接受字面路径，不支持数组索引计算或动态 key。比如想更新 JSON 数组中某个 id = 123 对象的 status，它做不到——你得先用 json_extract 拿出整个数组，用程序处理后再塞回去。
另一个限制：所有路径必须静态写出，不能拼接变量。所以 json_set(data, '$.items[' || idx || '].done', 'true') 这种写法在 SQLite 里语法错误，因为 json_set 第二个参数要求是常量字符串。
- 只支持固定路径，如
'$.user.name'、'$.list[0].id' - 数组索引必须是确定数字，不能是列值或表达式
- 批量更新多个不同路径节点 → 得用多个
json_set嵌套调用，性能较差
跨数据库统一更新思路：先提取再构造，比硬啃 JSON 函数更可靠
当业务逻辑涉及条件判断、循环更新或路径动态生成时，硬靠 SQL 内置 JSON 函数容易陷入边缘 case。比如“把所有 status 为 pending 的 item 的 retry_count 加 1”，MySQL/PG/SQLite 都没法单条 SQL 干完。
实际项目中更稳的做法是：用 SQL 提取整条 JSON 字段 → 在应用层（Python/Go/Java）解析、遍历、修改 → 序列化回字符串 → UPDATE 回库。虽然多一次往返，但逻辑清晰、可测、易调试。
尤其注意 MySQL 的 JSON_VALID 检查和 PG 的 jsonb_typeof 类型校验——别等 UPDATE 后才发现字段被写成了 null 或字符串。
