事务回滚失败主因是重复调用Commit/Rollback或在已结束事务上操作；根本在于连接状态失控、错误流未收敛及数据库隐式提交等语义陷阱。
事务回滚失败不是 GORM 的 bug，而是你没管住连接状态、错误流或数据库语义 —— 最常见原因是 tx.Commit() 或 tx.Rollback() 被重复调用，或在已结束的事务上再操作。
为什么调 tx.Rollback() 报 “事务已提交或回滚”
这个错误（"transaction has already been committed or rolled back"）本质是底层 *sql.Tx 状态机拒绝二次操作。GORM 不做状态缓存，它直接透传给 driver。
-
tx.Commit()和tx.Rollback()都是“一次性开关”，执行后tx内部标记为 done，后续任何操作（包括再次Rollback()）都会 panic 或返回该错误 - 常见诱因：defer 里无条件写
tx.Rollback()，但前面已成功Commit()；或 error 分支里Rollback()后又进 defer 再次调用 - 别依赖
defer tx.Rollback()做兜底 —— 它只适合 panic 场景，且必须配合recover()，否则必然误回滚
用 db.Transaction() 替代手写 Begin() 大多数时候更安全
db.Transaction() 是 GORM 封装好的“自动事务块”，内部做了三件事：开启事务、捕获 panic、按 error 返回值决定 Commit/Rollback。它不暴露 tx 句柄，天然规避了重复调用问题。
- 适用于绝大多数业务场景：订单创建、用户注册、支付扣款等单层原子操作
- 不支持保存点（SavePoint），所以不能用于需要局部回滚的嵌套逻辑
- 闭包内所有 DB 操作必须用传入的
tx *gorm.DB，绝不能混用原始db，否则脱离事务上下文 - 示例：
err := db.Transaction(func(tx *gorm.DB) error { if err := tx.Create(&order).Error; err != nil { return err // 自动触发 Rollback } if err := tx.Create(&log).Error; err != nil { return err } return nil // 自动触发 Commit })
手动 Begin() 时，必须显式配对 + recover
当你真需要保存点（比如子退款单失败但主日志要保留），就得用 tx.Begin() 链式调用。这时 GORM 不帮你兜底，你得自己守好三道关。
- 每层
Begin()必须对应一次Commit()或Rollback()，不能漏、不能多 - 必须用
defer func() { if r := recover(); r != nil { tx.Rollback() } }()捕获 panic，否则连接卡死，后续请求可能 hang 在 acquire timeout - 子事务失败时，调
tx2.Rollback()（回滚到tx2.Begin()位置），不是tx1.Rollback()—— 后者会干掉整个外层 - 外层
tx1.Commit()前，必须确认所有子事务 error 为nil，否则直接tx1.Rollback()
DDL、死锁、隐式提交这些坑比代码逻辑还致命
回滚失败常被归咎于 Go 代码，但真正拦路的是数据库行为本身。
- 在事务中执行
CREATE TABLE、ALTER COLUMN等 DDL，MySQL/PostgreSQL 会**隐式提交当前事务**，后续Rollback()对已提交部分完全无效 - 并发更新同一行且加锁顺序不一致，触发死锁时数据库主动 kill 事务，GORM 收到的是
ErrDeadlock，此时再Rollback()已无意义，必须重试 - 连接池配置遗漏
autocommit=false（尤其 SQL Server），会导致Begin()形同虚设，所有操作都在自动提交模式下运行 - 跨 goroutine 共享同一个
tx实例，或把tx传进异步回调，极易出现状态竞争 ——tx不是线程安全的
最易被忽略的一点：GORM 的 Begin() 链式调用不是语法糖，它是 SavePoint 的唯一合法入口；而 Transaction() 闭包里的嵌套调用，只会新开独立事务，彻底破坏原子性 —— 这个区别不看清，调试三天也找不到根因。
