应优先使用 UpdateColumn 或 UpdateColumns 绕过 Hook 直接更新字段，二者不触发钩子、不更新 UpdatedAt、不处理关联；若需保留 Updates 语义但跳过钩子，可用 Session(&gorm.Session{SkipHooks: true})。
用 UpdateColumn 或 UpdateColumns 绕过 Hook 直接更新字段
GORM 默认的 Updates 和 Save 会触发 BeforeUpdate、AfterUpdate 等钩子，还会自动更新 UpdatedAt 时间戳、处理关联（Associations）等。如果你只想改几个字段、不希望任何 Hook 干预，也不能接受时间戳被覆盖，就该跳过这些机制。
UpdateColumn 是最直接的选择：它完全绕过 GORM 的安全层和生命周期钩子，只生成纯 UPDATE SQL；UpdateColumns 则支持一次更新多个字段，行为一致。
-
UpdateColumn只能更新单个字段，适合简单场景：db.Model(&u).Where("id = ?", u.ID).UpdateColumn("status", "done") -
UpdateColumns接收map[string]interface{}，零值也会写入：db.Model(&u).Where("id = ?", u.ID).UpdateColumns(map[string]interface{}{"name": "", "age": 0}) - 二者都不触发任何 Hook，也不更新
UpdatedAt，也不会调用SaveAssociations - 注意：它们不校验字段是否在模型中定义，拼错字段名只会静默忽略（SQL 层报错需开启日志排查）
用 Session(&gorm.Session{SkipHooks: true}) 控制全局跳过
如果你仍想用 Updates 或 Save 的语义（比如传 struct 更新多个字段），但临时禁用钩子，可以用会话模式控制。这种方式保留了 GORM 的字段映射逻辑，只是关掉了钩子链。
关键点是：必须显式启用 SkipHooks: true，且该设置仅对当前会话生效，不影响其他操作。
- 跳过钩子后，
Updates依然会跳过 struct 中的零值（除非你用Select显式指定） - 示例：
db.Session(&gorm.Session{SkipHooks: true}).Model(&user).Where("id = ?", id).Updates(User{Name: "", Age: 0})—— 这里Name: ""仍是零值，不会被更新；要强制更新得加Select("name") - 若同时想跳过钩子 + 强制更新零值，组合更稳妥：
db.Session(&gorm.Session{SkipHooks: true}).Model(&user).Select("name", "age").Where(...).Updates(...)
Updates 传 map 时零值不跳过，但不触发 Hook 的边界情况
很多人误以为 Updates 传 map[string]interface{} 就能自然跳过钩子 —— 实际上，只有传 struct 才触发钩子；传 map 时默认不触发（文档明确说明“⚠️ 仅当传 struct 时触发 ❌ 传 map 不触发”）。这是个隐含行为，容易踩坑。
- 传 map 是最轻量的批量更新方式：
db.Model(&User{}).Where("id IN ?", ids).Updates(map[string]interface{}{"status": "archived", "updated_at": time.Now()}) - 但它仍会更新
UpdatedAt（如果模型启用了UpdatedAt字段且未手动关闭），因为这个时间戳是 GORM 内置逻辑，不是钩子控制的 - 若你连
UpdatedAt都不想动，就必须用UpdateColumn或UpdateColumns，或者在模型中禁用：UpdatedAt: falsetag - 传 map 无法利用结构体标签（如
gorm:"column:real_name"），字段名必须和数据库列名完全一致
批量更新相同字段时，Where 条件写法与性能影响
真正影响性能的不是方法选型，而是 WHERE 条件是否命中索引。尤其在用 IN 批量更新时，ID 列必须有索引，否则全表扫描风险极高。
- 安全写法：
db.Model(&User{}).Where("id IN ?", ids).UpdateColumns(cols)，其中ids是[]int64或类似切片 - 避免把
ids拼成字符串传入（如"1,2,3"），GORM 会当作单个字符串参数，导致 SQL 错误或注入风险 - 当
ids超过几千条，MySQL 可能报Packet too large，此时应分批（例如每 500 条一批） - 如果条件复杂（如多字段联合更新不同值），
Updates无法满足，得用原生 SQL 或Exec配合 CASE WHEN
最常被忽略的是：UpdateColumn 不校验字段是否存在，也不做类型转换；传错字段名或类型不匹配，错误只在执行时由数据库抛出，且 GORM 不会帮你包装成明确的 error message。上线前务必用 Debug() 看生成的 SQL。
