Gin中间件可统一管理事务，但必须手动Begin、显式传递*gorm.DB并存入c.Set()，因全局db无事务状态，GORM无隐式绑定机制，需handler主动取用tx并确保panic时由中间件捕获回滚。
Gin 中用中间件统一管理事务是可行的，但必须手动控制生命周期、显式传递 *gorm.DB，不能依赖全局 db 实例自动绑定事务上下文。
为什么 Gin 中间件不能直接“开启事务”
GORM 的事务对象 *gorm.DB 是有状态的：调用 Begin() 后返回的新 *gorm.DB 实例才携带事务上下文，而原始 db（如从 gorm.Open 得到的）始终是无事务的普通连接池句柄。中间件里对全局 db 调用 Begin() 并不改变后续 handler 里使用的 db，除非你把它塞进 c.Set() 并在 handler 中主动取出来用。
- 常见错误现象：
db.Create(&order)在 handler 里照常执行，但没走事务，回滚无效 - 根本原因：Gin context 和 GORM transaction 完全无关，没有隐式绑定机制
- 误区澄清：不存在 “给中间件配个 GORM 插件就能自动事务” 这回事
正确做法：中间件 Begin + Context 透传 + defer Rollback
核心是把事务句柄作为值存入 Gin context，并在 handler 结束前统一判断是否需要回滚。注意 panic 捕获必须由中间件自己完成，GORM 1.20+ 虽然能捕获内部 panic，但不会帮你 rollback 外层事务。
- 中间件中调用
tx := db.Begin()，检查tx.Error是否为 nil，非 nil 直接c.AbortWithStatusJSON(500, ...) - 用
c.Set("tx", tx)把事务句柄传下去 - handler 内通过
c.MustGet("tx").(*gorm.DB)取出并使用，所有 DB 操作都基于该tx - 中间件结尾加
defer func() { if tx != nil && tx.Error == nil { tx.Commit() } else { tx.Rollback() } }()
嵌套事务和 SavePoint 怎么办
如果业务逻辑里需要局部回滚（比如主流程失败但日志要记），不能靠中间件一层包到底——得在 handler 内部手动调用 tx.SavePoint("sp1") 和 tx.RollbackTo("sp1")。中间件只管最外层 commit/rollback，SavePoint 必须由业务代码显式控制。
- 场景举例：下单时先扣库存（可回滚），再发消息（失败不回滚库存），此时需在扣库存前后设 SavePoint
- 参数差异：
tx.SavePoint("key")返回新事务句柄，它和原tx共享连接但独立回滚点 - 容易踩的坑：SavePoint 名字重复会导致覆盖，建议用
uuid.NewString()或固定业务标识
事务超时与锁等待怎么观察
MySQL 默认事务超时是 50 秒，但 Gin 请求可能更短。如果你的 handler 执行超过 30 秒还没 commit，用户早已收到超时响应，而事务还在数据库里挂着，直到超时被 kill —— 这就是悬挂事务的来源。
- 必须设置
context.WithTimeout(c.Request.Context(), 10*time.Second)传给tx.WithContext() - 行锁竞争时，
SELECT ... FOR UPDATE会阻塞，GORM 默认不设锁等待超时，需手动加db.Session(&gorm.Session{Context: ctx}).Model(&Order{}).Where(...).Update(...) - 可观测性建议：在中间件开头打日志记录
c.Request.URL.Path和time.Now()，结尾补耗时和tx.Error，方便排查长事务
真正难的不是写完中间件，而是想清楚哪些接口必须事务、哪些可以拆成最终一致性、以及事务里能不能调外部 HTTP 或 Redis —— 这些地方一卡，整个事务就拖住数据库连接，比代码写错还难定位。
