GORM 没有内置事务回调函数，因其设计选择显式控制事务生命周期以避免隐式执行和保持边界清晰；需手动用 defer + committed 标志在 db.Transaction 中模拟提交后回调，并注意会话隔离与一致性边界。
为什么 GORM 没有“事务回调函数”这个内置概念
gorm 本身不提供类似 oncommit 或 onrollback 这样的注册式事务钩子。它只暴露了事务生命周期的控制权（begin/commit/rollback），所有“回调”行为必须由你手动组织在事务块内 —— 这不是缺陷，而是设计取舍：避免隐式执行、保持事务边界清晰可控。
用 defer + 闭包模拟事务后置回调
最常用且可靠的方式，是在 db.Transaction() 的回调函数内部用 defer 注册清理或通知逻辑，但需注意：只有当事务成功提交后才应触发业务回调，而 defer 在函数退出时无条件执行。因此必须显式判断事务状态：
err := db.Transaction(func(tx *gorm.DB) error {
// 执行业务操作
if err := tx.Create(&user).Error; err != nil {
return err
}
// 注册“仅在提交后执行”的回调（通过闭包捕获 tx 和状态）
committed := false
defer func() {
if committed {
// ✅ 这里放你的自定义回调逻辑，比如发消息、更新缓存
notifyUserCreated(user.ID)
}
}()
// 手动控制提交，并标记状态
if err := tx.Commit().Error; err != nil {
return err
}
committed = true
return nil
})
关键点：
-
defer本身不区分成功/失败，必须靠committed标志位控制实际执行 - 不要在
defer中调用tx.Commit()或tx.Rollback()—— 它们已在事务函数外由 GORM 管理 - 若使用
db.Transaction()自动回滚（即不手动调用Commit），则需改用tx.Session(&gorm.Session{NewDB: true})获取新会话来执行回调，否则可能遇到 “transaction has been committed or rolled back” 错误
封装成可复用的 WithTransactionCallback 辅助函数
把上面模式抽成函数，能减少重复判断。注意它不能替代 GORM 原生事务，只是语法糖：
func WithTransactionCallback(db *gorm.DB, fn func(*gorm.DB) error, onCommit func(*gorm.DB) error) error {
return db.Transaction(func(tx *gorm.DB) error {
if err := fn(tx); err != nil {
return err
}
// 提交前先确保没有 pending error
if err := tx.Commit().Error; err != nil {
return err
}
// 提交成功后再执行回调（此时 tx 已不可用，需用新会话）
return onCommit(db.Session(&gorm.Session{NewDB: true}))
})
}
// 使用示例
err := WithTransactionCallback(db, func(tx *gorm.DB) error {
return tx.Create(&order).Error
}, func(db *gorm.DB) error {
return db.Model(&User{}).Where("id = ?", order.UserID).Update("last_order_at", time.Now()).Error
})
这里容易踩的坑：
-
onCommit回调里的db是全新会话，不能复用原tx—— 否则 panic 或静默失败 - 如果
onCommit也需事务保护（比如它自己也要做一致性更新），得再套一层db.Transaction() - 该封装不支持嵌套事务（SavePoint）场景，GORM 的 SavePoint 机制与手动 Commit 冲突
什么时候不该用“回调”，而该用领域事件或消息队列
如果你的“回调”逻辑涉及 HTTP 调用、发邮件、写 Kafka、或跨服务状态同步，就别塞进事务里。原因很实在：
- HTTP 调用超时或失败会导致整个事务回滚，但下游系统可能已收到部分通知（造成不一致）
- GORM 事务只保证本地 DB 原子性，不保证跨网络操作的原子性
- 高并发下阻塞型回调会拖慢事务吞吐，增加锁持有时间
更稳妥的做法是：事务内只写一条 outbox 记录（如 event_messages 表），再由独立消费者投递。这才是真正解耦且可追溯的“事务后回调”。
真正的难点不在怎么写回调，而在判断哪些逻辑必须强一致、哪些可以最终一致 —— 这个决策比代码多十倍。
