不能直接用 db.transaction() 做回调逻辑，因为它仅自动回滚但无提交/回滚后钩子，导致事务回滚时外部状态已变更而引发不一致；需改用显式 begin/commit/rollback 控制生命周期。
为什么不能直接用 db.Transaction() 做回调逻辑
因为 db.Transaction() 内部只保证“出错自动回滚”，但不提供事务真正提交或回滚后的钩子入口。你写在回调函数里的代码，无论事务成功与否都会执行——它只是个闭包，不是“提交后回调”。常见错误是：在回调里发消息、更新缓存、调用第三方 API，结果事务回滚了，外部状态却已变更，造成数据不一致。
WithTx() 封装必须手动控制 Commit() 和 Rollback()
想精确触发提交后/回滚后逻辑，就得放弃 db.Transaction() 的自动管理，改用显式生命周期控制。核心是三点：
- 用
db.Begin()启动事务，拿到*gorm.DB实例 - 所有业务操作都走这个
tx对象，不能混用db - 必须显式调用
tx.Commit().Error或tx.Rollback().Error，并根据结果决定是否执行后续逻辑
示例片段：
func WithTx(db *gorm.DB, fn func(*gorm.DB) error, onCommit, onRollback func()) error {
tx := db.Begin()
defer func() {
if r := recover(); r != nil {
tx.Rollback()
onRollback()
}
}()
if err := fn(tx); err != nil {
tx.Rollback()
onRollback()
return err
}
if err := tx.Commit().Error; err != nil {
tx.Rollback()
onRollback()
return err
}
onCommit()
return nil
}
回调函数里别碰原事务对象 tx
一旦 tx.Commit() 或 tx.Rollback() 执行完毕，这个 tx 就失效了。此时如果在 onCommit 里再调用 tx.Create() 或 tx.First()，会 panic 报错："transaction has been committed or rolled back"。
- 需要查库或写库的回调逻辑，得用新会话：
db.Session(&gorm.Session{NewDB: true}) - 发消息、打日志、更新本地缓存这类无副作用操作，可直接执行
- 若回调本身可能失败（如 HTTP 请求超时），不要让它影响主事务成败；建议异步化或记录失败重试
嵌套事务和并发场景下要小心 committed 标志位
上面封装的 WithTx() 是单层事务安全的。但如果业务里有嵌套调用（比如 A 函数调 WithTx，内部又调 B 函数也调 WithTx），标志位就容易被覆盖或误判。更麻烦的是并发 goroutine 共享同一个 committed 变量，会导致竞态。
- 每个事务作用域必须有独立的状态变量，不能靠外层闭包捕获
- 高并发下推荐用
context.WithValue()透传事务状态，或直接把回调注册为函数值传入，避免共享可变状态 - 真正复杂的流程（如分布式事务补偿），别硬塞进单机事务封装里，该上 Saga 或消息队列就上
最常被忽略的一点：事务封装函数看起来只是语法糖，但它实际改变了错误传播路径和资源释放时机。哪怕只加了一行日志，也可能让 panic 没被 recover，或者让连接没被归还到池子里。
