Gin 不处理事务，事务由 GORM 控制；必须用 db.Transaction 或 tx.Begin() 配合 defer tx.Rollback() 和显式 tx.Commit()，严禁在 handler 中裸调 tx.Commit() 且不处理 error，所有 DB 操作须使用 tx 而非全局 db，跨服务需 Saga 或最终一致性。
直接说结论：Gin 本身不处理事务，事务逻辑完全由 GORM（或你用的其他数据库层）控制；关键在于 db.Transaction 的正确使用时机、defer tx.Rollback() 的必要性，以及别在 HTTP handler 里裸写 tx.Commit() 而不 handle error。
为什么 Gin 的 handler 里不能裸调 tx.Commit()
因为 HTTP handler 是一次性的函数调用，一旦 panic 或提前 return，tx.Commit() 就永远不会执行，而 tx 也不会自动关闭——连接会一直挂着，直到超时或被 GC 回收（但这个过程不可控，高并发下极易耗尽连接池）。
常见错误现象：
- 接口偶尔返回 500，日志没报错，但 MySQL 连接数持续上涨
- 事务中途 panic 后，数据库没回滚，但程序已返回成功响应
- 多个 goroutine 共享同一个
tx实例，导致“invalid transaction”错误
正确做法是始终配合 defer tx.Rollback()，并在确认所有操作无误后再显式 tx.Commit()：
立即学习“go语言免费学习笔记（深入）”；
func transferHandler(c *gin.Context) {
tx := global.DB.Begin()
defer tx.Rollback() // 无论成功失败，先确保能回滚
<pre class="brush:php;toolbar:false;">if err := tx.Model(&Account{}).Where("id = ?", fromID).Update("balance", gorm.Expr("balance - ? ", amount)).Error; err != nil {
c.JSON(400, gin.H{"error": err.Error()})
return
}
if err := tx.Model(&Account{}).Where("id = ?", toID).Update("balance", gorm.Expr("balance + ? ", amount)).Error; err != nil {
c.JSON(400, gin.H{"error": err.Error()})
return
}
if err := tx.Commit().Error; err != nil {
c.JSON(500, gin.H{"error": "commit failed"})
return
}
c.JSON(200, gin.H{"msg": "ok"})}
db.Transaction 函数回调里为什么必须用 tx 而不是 db
因为 db.Transaction() 内部创建的是一个独立的、带事务上下文的 *gorm.DB 实例（即 tx），它和全局 db 不共享事务状态。如果在回调里继续用 global.DB.Create()，那操作就落在了默认连接上，根本不在当前事务里，自然不会一起提交或回滚。
典型误用：
db.Transaction(func(tx *gorm.DB) error {
global.DB.Create(&Order{}) // ❌ 错！这不是事务里的操作
tx.Create(&OrderItem{}) // ✅ 对
return nil
})
使用场景：
- 适合逻辑清晰、无提前退出、纯 DB 操作的小型原子流程（如扣库存+建订单）
- 不适合需要中间调用外部服务（如发短信、调支付网关）、或需复杂分支判断的流程
- 回调函数返回非 nil error 时，
Transaction自动调用Rollback()；返回 nil 才Commit()
禁用 SkipDefaultTransaction: true 后，单条 Create 还需要手动事务吗？
不需要。禁用后，每条 Create/Update/Delete 都是独立的、自动提交的语句，相当于 MySQL 的 autocommit=1 模式。这时候你再包一层 Transaction，只是把单条语句放进了一个事务壳里——语法合法，但没实际意义，还多了一次 begin/commit 开销。
性能与兼容性影响：
- 启用默认事务（默认行为）：每条写操作都带隐式事务，安全但慢约 30%
- 禁用后（
SkipDefaultTransaction: true）：写操作直连 DB，快，但单条失败不会影响其他语句，也不提供跨语句一致性保证 - 混合使用没问题：禁用默认事务后，你仍可按需对多条语句显式加
Transaction，这是推荐做法
所以初始化时建议直接禁用，默认交由业务代码决定何时开启事务：
DB, err = gorm.Open(mysql.Open(dsn), &gorm.Config{
SkipDefaultTransaction: true,
PrepareStmt: true, // 预编译提升重复 SQL 性能
})
事务中调用外部 API 失败，怎么保证数据不脏？
不能靠数据库事务解决。事务只管 DB 层，HTTP 请求、消息队列、文件写入等都属于“分布式操作”，GORM 无能为力。
真实项目中的应对方式只有两种：
- 改成最终一致性：先落库（事务内），再异步发消息或调用第三方；失败时靠定时任务或补偿 job 重试
- 引入 Saga 模式：把转账拆成“冻结资金 → 调支付 → 确认到账 → 解冻”，每步都有对应的补偿动作（如冻结失败就直接返回）
最容易被忽略的一点：很多人以为 defer tx.Rollback() 能兜住所有 panic，但如果你在事务里启动了 goroutine 并在里面操作 tx，那 defer 就失效了——goroutine 和主协程生命周期不同步，tx 可能已被回收。所有事务操作必须严格在同一个 goroutine 内完成。
