GORM的Updates方法对结构体参数自动跳过零值（0、""、false等）是明确设计行为，旨在防止意外清空字段和减少无效SQL；map[string]interface{}可绕过该过滤，Select("field")则能精准强制更新指定零值字段。
Updates 用结构体时自动跳过 0、""、false 是设计行为，不是 bug
GORM 的 Updates 方法在接收结构体参数时，会通过反射遍历所有导出字段，并对每个字段值做零值判断：如果值等于 Go 类型的默认零值（int 是 0、string 是 ""、bool 是 false、指针是 nil），就直接从生成的 SQL 中剔除该字段。这不是漏判或异常，而是 GORM v1/v2 共有的明确设计策略。
它的出发点很实际：
- 防止部分更新时意外清空未赋值字段（比如你只改
Name，但结构体里Score没初始化，GORM 就不会把它变成 0） - 减少无意义的 SQL 执行（避免
UPDATE users SET score=0 WHERE id=123这种语句在业务上本就不需要时被发出） - 匹配多数 RESTful 更新场景——前端通常只传变更字段，后端模型未显式设值的字段理应保持原样
map[string]interface{} 能绕过零值过滤，因为 GORM 不对 map 做反射检查
当你把参数换成 map[string]interface{}，GORM 就不再走“反射 + 零值过滤”那套逻辑，而是直接拿 map 的键值对拼 SQL：SET name = ?, score = ?，不管 value 是 0 还是 ""，全数照搬。
这带来两个关键事实：
-
db.Model(&u).Updates(map[string]interface{}{"score": 0})—— 一定生效 - 但你必须确保 key 名和数据库列名一致（比如结构体字段是
Score、标签是gorm:"column:score"，那 map 里就得写"score"，不能写"Score"） - 如果 map 里漏了主键条件（如没带
"id": 123），又没配合Where，可能触发全表更新 —— 这比零值不更新更危险
Select("field") 是最轻量且可控的强制更新方式
比起整个结构体转 map 或手写 map，Select 更精准：它告诉 GORM “我就只动这几个字段，哪怕它们是零值”。
常见写法：
-
db.Model(&user).Select("score").Update("score", 0)—— 单字段，最简 -
db.Model(&user).Select("score", "status").Updates(User{Score: 0, Status: false})—— 多字段，结构体仍可用 -
db.Model(&user).Select("*").Updates(user)—— 强制更新所有字段（含零值），但注意：*包括所有映射字段，不含gorm:"-" or gorm:"omitempty"的字段
⚠️ 注意：Select 必须在 Updates 或 Update 之前调用，顺序反了无效；且它只影响紧邻的下一个更新操作，不改变全局行为。
别碰 UpdateAllFields 全局配置，副作用太难控
网上有些方案建议在 gorm.Config 里设某种开关来“全局启用零值更新”，但 GORM 官方并没有 UpdateAllFields: true 这样的配置项。v2 中唯一接近的是 AllowGlobalUpdate: true，但它控制的是是否允许无 Where 条件的更新，和零值无关。
强行模拟全局行为（比如封装一个 always-update wrapper）反而容易埋坑：
- 团队新人不知道这个 wrapper 的存在，写出
Updates(struct)后发现行为不一致 - 某次更新本应跳过
updated_at字段，但 wrapper 把它也塞进 SQL，导致时间戳被错误覆盖 - 嵌套结构体、匿名字段、自定义 Scanner/Valuer 类型在全字段模式下行为更难预测
真正需要零值更新的地方不多——积分清零、开关重置、状态回退。把这些场景单独拎出来，用 Select 或 map 显式处理，比追求“一劳永逸”的全局方案更可靠。
