defer tx.rollback()看似合理实则隐患重重：事务成功后冗余执行、panic时可能静默失败、对非事务操作无效；应优先使用db.transaction()，它自动处理提交/回滚、panic捕获与错误透传。
defer tx.Rollback() 为什么看似合理却常出错
很多人一想到“事务失败要回滚”，就立刻在 tx := db.Begin() 后写 defer tx.Rollback()，逻辑上没错，但实际会埋下两个隐患：一是事务成功提交后，tx.Rollback() 仍会被执行（虽然 GORM 内部会忽略已提交事务的回滚请求）；二是更严重的是——如果事务中途 panic，而你没 recover，defer 确实会触发，但此时 tx.Rollback() 可能因连接已失效、会话已关闭而静默失败，甚至 panic 二次崩溃。
-
tx.Rollback()在已提交事务上调用不报错，但属于冗余操作，掩盖真实流程意图 - 未配对
recover()的defer tx.Rollback()无法保证 panic 场景下的回滚可靠性 - 若事务内调用了非
tx实例的 DB 方法（比如直接用db.Create()），那些操作根本不在事务中，tx.Rollback()对它们完全无效
db.Transaction 是默认首选，不是“高级选项”
db.Transaction() 不是为复杂场景准备的备选方案，而是 GORM 官方推荐的**默认事务入口**。它内部已封装了 panic 捕获、自动 Commit/Rollback 判定、连接复用和错误透传，你不需要自己操心 defer 怎么写。
- 函数签名是
func(tx *gorm.DB) error，返回nil即自动 Commit，返回非 nil 错误即自动 Rollback - 它创建的是新会话（session），与外层
db隔离，避免资源污染 - 所有数据库操作必须使用传入的
tx，不能混用原始db，否则事务形同虚设 - 不要在回调函数里手动调用
tx.Commit()或tx.Rollback()—— 这会干扰 GORM 自动流程，导致 “transaction has been committed or rolled back” 错误
真需要手动事务时，defer 必须配合 recover
仅当你需要 SavePoint、跨多个事务协调、或集成外部资源（如消息队列确认）时，才考虑 db.Begin()。此时 defer 不能单独存在，必须和 recover() 绑定，形成防御闭环。
- 写法模板：
tx := db.Begin(); defer func() { if r := recover(); r != nil { tx.Rollback() }; }() - 显式
tx.Commit().Error成功后，不能再调用tx.Rollback()—— 虽然不会报错，但语义混乱且易引发后续误判 - 每个
tx.Begin()必须有且仅有一次Commit()或Rollback()，多调或漏调都会导致连接泄漏或状态错乱 - 如果事务中启动了 goroutine，务必确保它使用的也是
tx实例，并注意 context 生命周期（避免 Gin 请求 context 被 cancel 后还在用tx）
想在 Commit 后触发回调？别靠 defer 猜状态
GORM 没有 OnCommit 钩子，所以有人试图用 defer + 标志位模拟。但要注意：defer 函数捕获的是闭包变量，不是事务最终状态。最简稳做法是在 db.Transaction() 回调末尾、return nil 前直接调用你的回调逻辑。
- ✅ 安全写法：
err := db.Transaction(func(tx *gorm.DB) error { if err := tx.Create(&u).Error; err != nil { return err } // ✅ 提交前最后一步：业务回调（发消息、清缓存等） notifyUserCreated(u.ID) return nil // 此时 GORM 才 Commit }) - ❌ 危险写法：
defer notifyUserCreated(u.ID)—— 它会在 return 前执行，但此时事务尚未 Commit，回调可能拿到未持久化的中间态 - 如果回调本身也要 DB 操作，必须新开一个独立
db实例（不能复用tx），否则遇到 “transaction has been committed or rolled back” 错误
defer 不是不行，但它的安全边界非常窄：只适合清理本地资源（如临时文件、内存 buffer），绝不该承担事务成败判定或 DB 状态依赖型逻辑。真正需要“事务后动作”的地方，优先靠流程控制，而不是靠 defer 猜时机。
