BeforeUpdate钩子本身不能防篡改，必须配合tx.Statement.SetColumn强制写入、上下文权限校验、数据库约束三重防护：直接改结构体字段无效，因GORM仍从原始反射值取值；仅SetColumn能绕过映射链直写SQL；需从Context提取权限并校验Changed字段，非法修改返回error中断事务；关键字段须加数据库ENUM/CHECK约束兜底。
BeforeUpdate 钩子本身不能防止字段被恶意篡改，它只是个执行时机——能否防住，全看你怎么写逻辑、怎么用 tx.Statement.SetColumn、以及是否配合数据库约束和业务层校验。
为什么直接改结构体字段在 BeforeUpdate 里无效
常见错觉是：在 BeforeUpdate 里写 u.Email = "safe@example.com" 就能“覆盖掉用户传来的脏数据”。实际不会生效，原因有两个：
- GORM 在生成 UPDATE SQL 时，仍从原始反射值（即传入的 struct 副本）取字段值，钩子里对
u.Email的赋值只是改了副本，不影响最终 SQL 参数 - 若调用的是
db.Model(&u).Update("email", ...)这类单字段更新，GORM 根本不读u.Email字段，只用你传的参数；而db.Updates(&u)又只取非零值，u.Email若为空字符串或 nil，照样不进 SQL
真正能强制写入的唯一方式是：tx.Statement.SetColumn("email", "safe@example.com")。它把值直接塞进 SQL 的 SET 子句，绕过结构体映射链。
如何用 BeforeUpdate 拦截非法字段修改
想阻止某字段被前端/调用方随意改，不能靠“覆盖”，而要主动校验+中断流程。比如禁止普通用户修改 role 字段：
- 先从
tx.Statement.Context提取当前操作人权限（需上层用db.WithContext(ctx)透传） - 检查
tx.Statement.Dest或tx.Statement.Changed("role")判断该字段是否在本次更新中被显式设置 - 若
role被修改且当前用户不是 admin，则返回 error 中断事务：return errors.New("role field is immutable for non-admin") - 注意：不要用
tx.Statement.Unscoped().First()查旧值来比对——这会破坏事务隔离，且在批量更新时逻辑错乱
字段级防护必须搭配数据库层面约束
仅靠钩子是脆弱的，绕过 GORM 直连数据库或误用 db.Exec 就会失效。关键字段应加双重保险：
- 数据库设为
GENERATED ALWAYS AS (…)（如 PostgreSQL）或触发器拦截非法 UPDATE - 敏感字段（如
created_by、status_updated_at）在 DDL 中设为NOT NULL DEFAULT …，并禁用应用层写入 - 对
role、is_deleted等状态字段，定义枚举类型（ENUM或CHECK约束），让数据库拒绝非法值，而非依赖 Go 层判断
钩子只负责“业务语义校验”，比如“只有审核员才能把 status 从 pending 改成 approved”；数据库约束负责“数据形态兜底”，比如“status 只能是 'pending'/'approved'/'rejected'”。
最容易被忽略的坑：Save() 和 Updates() 触发逻辑不同
很多人以为写了 BeforeUpdate 就万事大吉，结果发现某些更新没走钩子——因为：
-
db.Save(&u)不触发BeforeUpdate，只触发BeforeSave（它也不区分新增/更新） -
db.Updates(map[string]interface{}{"email": "x"})会触发BeforeUpdate，但db.Model(&u).Where("id = ?", u.ID).Updates(...)同样触发，而db.Model(&u).Update("email", "x")也触发——关键不在方法名，而在是否通过*gorm.DB实例调用且目标是 model struct - 若模型字段是
*string，且传入的 map 里该 key 不存在，u.Email保持 nil，Changed("email")返回 false；但若传了"email": nil，则会触发且值为 nil，需额外判空
真实防护逻辑必须覆盖所有可能的更新入口，不能只测一种写法。
