事务提交失败多因连接中断、事务提前释放或隔离/嵌套问题，需优先检查底层连接错误、避免重复提交/回滚、正确使用savepoint及每步校验error。
事务提交失败，八成不是代码逻辑错，而是底层连接已断、事务被提前释放，或隔离级别/嵌套结构触发了隐式回滚。
检查 tx.Commit() 返回的 error 是否为 “transaction has already been committed or rolled back”
这个错误最常见于两种情况：事务对象被重复使用，或在 defer 中误调了 tx.Rollback()。GORM 的 *gorm.DB 实例是不可重入的——一旦 Commit() 或 Rollback() 执行过，该事务对象就失效了。
- 不要在
Commit()后再调用Rollback()，哪怕是在 defer 里 - 避免把
tx传给多个函数后，在不同地方都尝试Commit()或Rollback() - 手动事务中，
defer func() { if r := recover(); r != nil { tx.Rollback() } }()是安全的；但若你已在业务逻辑中显式tx.Rollback()，defer 会再次触发，导致 panic 后tx状态混乱
确认数据库连接是否在 Commit() 前已中断
GORM 不会在 Commit() 时主动检测连接状态，它只是向底层 *sql.Tx 发起提交指令。如果网络抖动、MySQL kill 了 idle 连接、或 PostgreSQL 因超时断开，tx.Commit().Error 可能返回类似 "pq: server closed the connection unexpectedly" 或 "invalid connection" 的底层驱动错误。
- 用类型断言提取原始错误：对 PostgreSQL，检查
err.(*pq.Error).Code[0:2] == "08"；对 MySQL，匹配mysql.ErrInvalidConn或字符串含"i/o timeout"、"broken pipe" - 别只看
tx.Commit().Error != nil就认为是业务问题——先判断是不是连接类错误，再决定是重试还是告警 - 连接池参数要设
SetMaxIdleConns(10)和SetConnMaxLifetime(30 * time.Minute)，避免复用老化连接
排查嵌套事务中内层 Rollback() 波及外层
GORM 1.20 虽支持 SavePoint 实现“伪嵌套”，但它的 tx.Begin() 并非真正独立事务——内层 Rollback() 会直接让整个外层事务失效，后续 outer.Commit() 必然报错 "transaction has already been rolled back"。
- 内层事务块必须用
tx.Transaction(func(tx2 *gorm.DB) error { ... })形式，而不是tx.Begin()+ 手动管理，否则无法隔离失败影响 - 若必须手动控制嵌套，内层失败时只能
return err（由外层统一回滚），绝不能调inner.Rollback() - 调试时可在每层开头打日志：
log.Printf("entering inner tx, parent id: %p", tx)，确认是否复用了同一事务实例
验证事务是否被自动提交或静默回滚
某些数据库行为会导致事务“看似成功执行却未持久化”：比如 MySQL 开启了 AUTOCOMMIT=1，或你在事务中执行了 DDL（如 CREATE TABLE）、锁表语句（LOCK TABLES），这些操作会强制提交当前事务。
- 检查 DSN 是否带
autocommit=false（MySQL 默认 true，GORM 不会自动关） - 避免在事务块中混用 DDL 或
SELECT FOR UPDATE后没跟任何写操作——部分驱动会因无变更而跳过提交 - 开启 GORM 日志：
db.Debug()，观察生成的 SQL 是否真包含BEGIN和COMMIT，而非只有单条 INSERT
最易被忽略的一点：事务失败未必发生在 Commit() 那一刻——可能早在第一条 Create() 时，因外键约束或唯一索引冲突触发了回滚，但你没检查那个 error，直到最后 Commit() 才暴露“事务已结束”。务必每步都校验 .Error，别只盯着结尾。
