事务安全依赖错误传播、闭包边界和tx实例隔离；中间件仅对齐HTTP生命周期，无法自动管理DB操作，因无法识别db实例混用、不能劫持变量引用、无法延续tx生命周期，且goroutine中复用会panic。
直接在 Gin 路由里裸调 db.Transaction 不等于事务安全，真正起作用的是「错误传播 + 闭包边界 + tx 实例隔离」三者配合；中间件本身不管理事务，它只是帮你把事务逻辑和 HTTP 生命周期对齐的胶水层。
为什么不能用中间件自动包裹所有 DB 操作
Gin 中间件无法可靠感知业务函数里用了哪个 DB 实例 —— 你可能在 handler 里混用 db.Create()（全局实例）和 tx.Create()（事务实例），中间件拦不住这种写法。事务必须显式从 db.Transaction 闭包里获得 tx，且所有操作都得基于它。
- 中间件没有能力重写或劫持你代码里的
db变量引用 -
db.Transaction返回后，tx就失效了，中间件没法延续它的生命周期 - 如果 handler 里启动 goroutine 并在其中用
tx，会触发并发 panic（tx不支持复用）
事务中间件只做两件事：绑定上下文 + 统一错误处理
所谓“事务中间件”，本质是把 db.Transaction 的调用时机、错误分支、HTTP 状态码映射收口到一个可复用的位置。它不替代业务逻辑封装，而是确保事务闭包执行完后，该提交的提交、该回滚的回滚、该返回 500 的不静默吞错。
- 中间件内调用
db.Transaction，把业务 handler 包进闭包参数中，例如：db.Transaction(func(tx *gorm.DB) error { return handler(c, tx) }) - 必须检查
db.Transaction的返回值：非nil错误要调c.AbortWithStatusJSON(500, ...)，避免后续 handler 再执行 - 不要在中间件里
defer tx.Rollback()——tx是闭包参数，出作用域就不可访问 - 若 handler 需要提前 abort（如权限校验失败），应在调用
db.Transaction前完成，否则事务已开启却没机会回滚
嵌套事务和 SavePoint 不是“子事务”，中间件里别滥用
在已有事务中再调 tx.Begin()，GORM 实际只建 SavePoint，不是新开隔离事务。中间件若层层套 Transaction，会导致回滚只退到最近的保存点，外层已改数据仍会提交 —— 这和直觉严重不符，极易引发资金/库存类 bug。
- 一个 HTTP 请求只应有**一层**
db.Transaction调用，放在最外层中间件或路由 handler 开头 - 需要局部回滚时，明确用
tx.SavePoint("sp1")+tx.RollbackTo("sp1")，别依赖嵌套Transaction - 中间件里检测当前是否已在事务中（
c.Get("tx") != nil），重复开启要报错或跳过，而非静默嵌套
事务的边界永远由业务语义决定，不是由中间件数量决定；最容易被忽略的是 panic 后的连接泄漏 —— 即使开了 gin.Recovery()，也得确保 db.Transaction 闭包内的 panic 能被它捕获，否则 tx 对象不会释放。
