BeforeUpdate钩子不适合主校验，因触发晚、上下文缺失且易被绕过；真正字段合法性校验（如邮箱格式）必须放在HTTP层用validator库提前拦截。
BeforeUpdate 钩子本身不适合做字段合法性校验，它只适合做数据库约束级的兜底检查；真正的语义校验（如邮箱格式、手机号长度）必须放在 HTTP 请求层，用 validator 库提前拦截。
为什么 BeforeUpdate 不该承担主校验职责
BeforeUpdate 是模型层回调，触发时机晚、上下文受限、且容易被绕过：
- 它只在
db.Update()或db.Updates()时触发，db.Save()走的是BeforeSave，而直连数据库或 CLI 导入数据完全不经过钩子 - 钩子里拿不到原始请求参数（比如前端传了空字符串 + 空格，但结构体已自动 trim），无法还原校验上下文
- 若校验失败返回 error，GORM 会回滚事务并报
failed to update: xxx，但错误信息无法映射到具体字段，前端难提示 - 跟 GORM 的零值处理逻辑冲突：比如
u.Email = ""进入钩子后你判空报错，但db.Model(&u).Select("name").Update("name", "a")根本不会读取 Email 字段，此时钩子甚至不执行
BeforeUpdate 里能做的合理校验有哪些
仅限于那些“即使绕过 API 也必须守住”的数据库层面硬约束，且必须配合显式字段控制：
- 检查关键字段是否为零值却未被显式更新：
if tx.Statement.Changed("status") && u.Status == "" { return errors.New("status cannot be empty") } - 验证枚举字段范围：
if !slices.Contains([]string{"active", "inactive", "pending"}, u.Status) { return errors.New("invalid status") } - 防止时间倒流：
if !u.UpdatedAt.IsZero() && u.UpdatedAt.Before(u.CreatedAt) { return errors.New("updated_at cannot be before created_at") } - 注意：
tx.Statement.Changed("field")才能准确判断该字段是否在本次 Update 中被修改，直接判u.Field != ""会误伤
常见踩坑：校验写了但没生效
BeforeUpdate 方法签名和位置错一点，GORM 就彻底静默忽略：
- 接收者不是指针：
func (u User) BeforeUpdate(...)→ 不触发（改的是副本） - 参数类型不对：
func (u *User) BeforeUpdate(tx gorm.DB)缺少*→ 不触发 - 返回值不是
error：func (u *User) BeforeUpdate(...) bool→ 不触发 - 方法定义在其他包（比如
hooks/目录下）→ GORM 查不到，等同于没写 - 用了
db.Save(&u)却期待BeforeUpdate触发 → 实际走的是BeforeSave，得换用db.Updates(&u)或db.Model(&u).Updates(map[string]interface{}{"name": "x"})
真正该放哪做字段合法性校验
HTTP 层用 validator（如 go-playground/validator）校验传入的 DTO 结构体，早失败、字段级错误可透出：
type UserUpdateReq struct {
Name string `json:"name" validate:"required,min=2,max=50"`
Email string `json:"email" validate:"required,email"`
}
然后才转成 GORM 模型更新。BeforeUpdate 只负责最后一道防线：比如确保软删除标记 DeletedAt 一旦设值就不能清空，或防止 Role 被非法降级——这些是业务规则，不是输入格式问题。
最危险的组合是：HTTP 层没校验 + BeforeUpdate 里只写了 emailRegex.MatchString(u.Email) 却没判空 → 空字符串直接入库，后续所有逻辑都基于脏数据运行。
