GORM 故意不提供 OnCommit 等内置事务回调，因其坚持显式、边界清晰的事务控制；所有回调需手动组织在 Transaction 闭包内，常用 defer + committed 标志实现提交后逻辑。
为什么 GORM 没有 OnCommit 这类内置事务回调
GORM 故意不提供 OnCommit、OnRollback 等注册式事务钩子，因为事务控制必须显式、边界清晰。它的 Transaction 函数只负责执行闭包并自动回滚错误，所有“回调”逻辑都得你手动组织在闭包内部——这不是遗漏，是设计约束。
用 defer + committed 标志模拟提交后回调
这是最常用也最可靠的做法，关键在于：不能依赖 defer 自动触发，而要靠状态位控制实际执行时机。
-
defer块里只做判断，不直接放业务逻辑；真正的回调（比如发消息、更新缓存）必须包裹在if committed { ... }中 - 必须手动调用
tx.Commit()并在成功后才设committed = true；若依赖db.Transaction()自动提交，则无法准确感知成功时刻 - 不要在
defer里调用tx.Commit()或tx.Rollback()——GORM 已管理好这些，重复调用会 panic - 如果事务内需执行回调操作（如查新数据），要用
tx.Session(&gorm.Session{NewDB: true})获取独立会话，否则遇到"transaction has been committed or rolled back"错误
err := db.Transaction(func(tx *gorm.DB) error {
if err := tx.Create(&user).Error; err != nil {
return err
}
<pre class='brush:php;toolbar:false;'>committed := false
defer func() {
if committed {
notifyUserCreated(user.ID) // ✅ 仅在此处执行
}
}()
if err := tx.Commit().Error; err != nil {
return err
}
committed = true
return nil})
想统一处理事务生命周期？自己封装入口函数
别试图给 db.Begin() 打补丁，而是定义自己的事务入口，比如 WithTx(fn func(*gorm.DB) error, hooks ...TxHook)，把 onBegin、onCommit、onRollback 作为参数传入。
-
onBegin在db.Begin()后立即执行，适合初始化上下文、打日志、开 trace -
onCommit放在tx.Commit()成功之后，和上面committed模式一致 -
onRollback必须在recover()或显式tx.Rollback()后调用，注意 panic 场景下需捕获 - 避免在钩子里再开事务或操作同一
*gorm.DB实例，容易引发锁或会话失效
用 Session.WithContext 透传事务上下文做轻量钩子
如果你只需要“知道当前操作是否在事务中”，不用侵入事务控制流，就用 context.WithValue 注入标记，再在模型级钩子（如 BeforeCreate）里读取。
- 开启事务时：
tx := db.WithContext(context.WithValue(ctx, txKey, true)).Begin() - 在全局钩子中检查：
if _, ok := db.Statement.Context.Value(txKey).(bool); ok && ok { /* 是事务内 */ } - 这个方式无法替代真正的提交后回调，但适合审计、埋点、权限校验等读场景
- 注意
txKey必须是私有 unexported 类型（如type txKey struct{}），避免 key 冲突
事务回调不是语法糖，它直连数据一致性命门。最容易被忽略的是：回调逻辑本身可能失败，而 GORM 不会重试或补偿——你要决定它是尽力而为，还是必须成功（那就得进消息表或本地事务表）。
