GORM回调函数是绑定于模型操作前/后的钩子，于Create/Save/Delete等生命周期触发；必须用指针接收者、匹配预定义名称，返回error可终止操作。
什么是 GORM 回调函数，它在哪个生命周期触发
GORM 的回调（Hooks）是绑定到模型操作（如 Create、Save、Delete）前/后的函数，不是中间件，也不参与事务控制——它直接嵌入在 GORM 内部执行链中。回调只对注册了对应方法的结构体生效，且必须定义为指针接收者；否则 GORM 无法修改原始对象，比如设置默认值或校验失败时中断操作。
常见误用：把回调写成值接收者函数，结果 BeforeCreate 里改了 CreatedAt，但保存后数据库仍是零值。
- 必须使用指针接收者：
func (u *User) BeforeCreate(tx *gorm.DB) error - 回调名必须完全匹配 GORM 预定义名称（如
BeforeCreate、AfterUpdate），大小写敏感 - 返回
error会终止当前操作（GORM 会回滚事务，如果在事务内） - 不建议在回调里手动调用
tx.Create或其他 CRUD，可能引发无限递归
如何注册自定义回调并避免被全局覆盖
GORM v2 默认启用了一组内置回调（如自动时间戳、软删除）。你写的回调会插入到默认链中，但位置不可控——除非显式指定顺序。最稳妥的方式是用 Session 禁用默认回调，再手动注册自己的：
// 定义回调
func (u *User) BeforeCreate(tx *gorm.DB) error {
u.Status = "active"
return nil
}
// 注册（注意：必须在 AutoMigrate 之前）
db.Session(&gorm.Session{SkipDefaultTransaction: true}).Callback().Create().Before("gorm:before_create").Register("my_before_create", func(tx *gorm.DB) error {
if user, ok := tx.Statement.ReflectValue.Interface().(*User); ok {
return user.BeforeCreate(tx)
}
return nil
})
关键点：
-
Before("gorm:before_create")表示插在 GORM 原生时间戳逻辑之前；用After则在其后 - 不要用
db.Callback().Create().Remove("gorm:before_create")全局删掉默认逻辑，否则CreatedAt不会自动赋值 - 若只想对某次查询禁用回调，用
db.Unscoped().Create(...)不起作用；得用db.Session(&gorm.Session{AllowGlobalUpdate: true}).Create(...)配合回调开关字段
为什么 AfterFind 回调读不到关联数据
AfterFind 在单条记录从数据库取出后立即执行，此时 GORM 还没加载 Preload 或 Joins 的关联字段。所以你在 AfterFind 里访问 u.Profile，大概率是 nil 或零值。
正确做法分场景：
- 需要统一处理主表字段（如脱敏邮箱）：用
AfterFind没问题 - 依赖关联数据做计算（如拼接用户全名 = User.Name + Profile.Nickname）：改用
Select手动 JOIN 查询，或在业务层查完再处理 - 想让回调“感知”预加载：给模型加标记字段，例如
LoadedProfile bool，在查询时手动设为true，回调里判断
示例（安全脱敏）：
func (u *User) AfterFind(tx *gorm.DB) error {
u.Email = strings.ReplaceAll(u.Email, "@", "[at]")
return nil
}
回调里访问数据库容易引发死锁和循环依赖
在 BeforeCreate 中调用 tx.First(&other, ...) 看似合理，但若该查询又触发另一个模型的 AfterFind，而那个回调又反向查当前模型，就形成循环。更危险的是，在事务中嵌套事务（比如用 db.WithContext(ctx).Create）可能造成连接泄漏或死锁。
- 禁止在回调里用
db.Create或db.Transaction；要用也必须用传入的tx *gorm.DB - 跨模型依赖尽量前置到业务层，回调只做轻量级字段加工
- 调试时加日志注意不要打
tx.Statement.SQL.String()，它在 Prepare 模式下为空字符串 - 如果真要查关联配置（如根据 tenant_id 查租户配额），建议缓存到
tx.Statement.Context中，由上层注入
回调不是万能钩子，它适合做原子性字段修正，不适合做业务编排。越复杂的逻辑，越应该从回调移出到 service 层。
