GORM事务需谨慎处理panic、嵌套、上下文传递与SavePoint；推荐使用db.Transaction()封装，手动Begin需配recover；嵌套事务实为同一层，部分回滚须用SavePoint；事务须绑定请求生命周期，避免跨goroutine泄漏；日志与监控需覆盖Commit阶段及耗时指标。
生产环境里，GORM 的事务不是加个 db.Transaction() 就完事的；没处理好 panic、嵌套、上下文传递或 SavePoint，轻则数据不一致，重则连接池耗尽、事务悬挂。
事务中 panic 会直接导致事务悬挂
GORM 1.20 之前，事务回调里一旦 panic，defer tx.Rollback() 根本不会执行，连接卡在开启状态，后续请求可能被阻塞。1.20 起虽然默认捕获 panic 并转为 error，但前提是使用 db.Transaction() 这种封装方式；手动 Begin() + recover() 仍需自己兜底。
- 推荐始终用
db.Transaction(func(tx *gorm.DB) error { ... })，它内部已做 recover 和 Rollback 保障 - 若必须手动控制（比如要复用 tx 对象多次操作），一定要写完整 recover 模板：
tx := db.Begin() defer func() { if r := recover(); r != nil { tx.Rollback() } }() - 别在事务函数里启动 goroutine 并操作
tx——goroutine 拿不到父级 defer 的上下文，panic 无法被捕获
嵌套事务不等于“子事务”，SavePoint 才是可控切点
GORM 默认不支持真正的嵌套事务（即子事务提交不影响父事务），所谓“嵌套”只是对同一个 *gorm.DB 实例重复调用 Transaction()，实际仍是同一层事务。真要实现部分回滚，必须显式用 SavePoint。
- 正确用法：
err := db.Transaction(func(tx *gorm.DB) error { if err := tx.Create(&order).Error; err != nil { return err } // 设置保存点 sp := tx.SavePoint("sp_payment") defer func() { if r := recover(); r != nil { tx.RollbackTo("sp_payment") } }() if err := tx.Create(&payment).Error; err != nil { tx.RollbackTo("sp_payment") // 只回滚 payment 部分 return nil // 不中断整个事务 } return nil }) -
SavePoint名字必须唯一，否则第二次同名调用会覆盖前一个点 - 注意：MySQL 5.7+ 支持 SavePoint，但 TiDB 或某些云 MySQL 兼容层可能限制数量或行为，上线前务必验证
事务必须绑定 HTTP 请求生命周期，不能跨 goroutine 或中间件泄漏
常见错误是把 *gorm.DB 实例从 Gin 中间件塞进 c.Set("db", tx)，然后在 handler 里取出来用——这看似方便，实则危险：如果 handler 启动了异步任务、调用了其他 service、或没显式 Commit/Rollback，tx 就会滞留在内存里，连接不释放。
- 最佳做法：在中间件中开启事务，并只把
tx传给当前请求链路的 handler 函数参数，不要存到 context 或全局 map - 避免在事务内调用其他 service 方法，除非该方法明确声明接受
*gorm.DB参数并承诺不自行开新事务 - 用 Gin 的
c.Request.Context()透传事务对象时，必须配合context.WithValue()+ 显式类型断言，且确保所有下游调用都检查该值是否存在
事务日志与可观测性不能只靠 Error 判断
很多团队只在 err != nil 时打日志，但事务失败往往发生在 Commit 阶段，而前面的 Create、Update 都成功了——这时你看到的是“无错误执行”，但最终数据没落库。
- 必须在
Commit().Error处统一打日志，包含事务耗时、SQL 行数、影响行数（可用tx.Session(&gorm.Session{PrepareStmt: true})获取） - 开启 GORM 的慢 SQL 日志（
db.Config.Logger = logger.Default.LogMode(logger.Info)），但注意生产环境别开logger.Info级别，建议用自定义 logger 过滤出duration > 100ms的事务 - 关键业务事务（如支付、库存扣减）建议加 Prometheus 指标：
gorm_txn_duration_seconds{status="success",op="create_order"}
最常被忽略的一点：事务不是越长越好，也不是越短越安全。一个事务里混入 HTTP 调用、文件读写、或第三方 SDK 初始化，就等于把数据库锁的范围扩大到了不可控的外部依赖上——这种设计，比没加事务还危险。
