GORM中JSON字段需用json.RawMessage等Go类型配合gorm:"type:json"标签映射，查询和局部更新须手写原生SQL，推荐结构固定时用自定义struct，避免滥用JSON导致维护困难。
PostgreSQL/MySQL 中 JSON 字段怎么映射到 GORM struct
GORM 本身不直接“识别”数据库的 JSON 类型，它靠 Go 类型 + Scanner/Valuer 接口来桥接。你得自己选一个 Go 类型承载 JSON 数据，并实现序列化逻辑。
最常用的是 json.RawMessage（零拷贝、保留原始格式）或 map[string]interface{}（方便读写但会丢失类型和顺序）。如果结构固定，直接用自定义 struct 更安全。
-
json.RawMessage：适合只存、不常查字段内部值的场景，比如日志、配置快照 -
map[string]interface{}：适合字段结构动态变化，但要注意嵌套 map 的类型断言容易 panic - 自定义 struct：字段名、类型明确，GORM 自动处理编解码，推荐用于已知 schema 的 JSON 字段
GORM v2 如何声明 JSON 字段并避免 scan error
声明时必须加 type:json 标签，否则 GORM 会当成普通字符串处理，写入时可能报 cannot convert string to jsonb（PostgreSQL）或 Incorrect string value（MySQL utf8mb4 缺失）。
示例（PostgreSQL）：
立即学习“go语言免费学习笔记（深入）”；
type User struct {
ID uint `gorm:"primaryKey"`
Name string `gorm:"not null"`
Metadata json.RawMessage `gorm:"type:json;not null"`
}
- 没加
type:json→ GORM 尝试用string插入 JSONB 列 → 报错 - MySQL 需确保表字符集是
utf8mb4，且 collation 是utf8mb4_unicode_ci，否则中文会截断 - 如果字段允许 NULL，
json.RawMessage可设为指针：*json.RawMessage，否则空值会被编码成null字符串
怎么在 WHERE 条件里查询 JSON 字段的某个 key
GORM 不提供跨方言的 JSON 查询语法封装，得手写原生 SQL 片段，用 clause.Expr 或 Where("metadata->>'name' = ?", "foo") 这类方式。
PostgreSQL 示例（查 metadata 里 status 为 "active" 的记录）：
var users []User
db.Where("metadata->>'status' = ?", "active").Find(&users)
-
->>返回 text，->返回 json，注意类型匹配 - MySQL 用
JSON_EXTRACT(metadata, '$.status')或简写metadata->"$.status"（5.7+） - 别在 JSON 字段上做
LIKE或全文搜索——性能差，应拆出关键字段建索引 - GORM 的
Find/First不支持对json.RawMessage做结构体比较，只能靠数据库函数
更新 JSON 字段局部值而不是整字段覆盖
GORM 默认是整字段替换（Save 或 Updates），没法像 PostgreSQL 的 jsonb_set 那样只改一个 key。要局部更新，必须用原生 SQL 或数据库函数。
PostgreSQL 局部更新示例（把 metadata.status 改成 "archived"）：
db.Exec(
"UPDATE users SET metadata = jsonb_set(metadata, '{status}', ?::jsonb) WHERE id = ?",
`"archived"`, 123,
)
- 不能用
Update("metadata", newJSON)，那会覆盖整个字段 - MySQL 用
JSON_SET(metadata, "$.status", "archived") - 如果业务中频繁局部更新 JSON，说明这个字段可能该拆成独立表或普通列了
JSON 字段看着灵活，实际在 GORM 里操作起来全是边界条件：类型映射、方言差异、查询能力受限、更新粒度粗。真要用，优先考虑是否真的需要 JSON，还是只是偷懒没拆表。
