tx.Commit() 返回的是底层驱动透出的原始数据库错误，非 ORM 封装语义错误，常见类型包括连接中断、锁超时、唯一键冲突、磁盘满等；其返回值为 *gorm.DB，需通过 .Error 字段获取真实 error。
tx.Commit() 返回的 error 是什么类型？
tx.Commit() 返回的是 error，但不是 GORM 封装过的语义错误（比如 ErrRecordNotFound），而是底层驱动透出的原始数据库错误。常见包括连接中断、锁超时、违反约束（如唯一键冲突）、磁盘满、主从同步延迟导致的写失败等。
它和 tx.Create().Error 本质不同：后者是 ORM 层对单条语句执行结果的包装；而 tx.Commit() 是对整个事务提交动作的原子性确认——哪怕所有 SQL 都执行成功，Commit 仍可能失败。
为什么直接 defer tx.Commit() 不行？
因为 defer 无法区分“该提交”还是“不该提交”。如果前面逻辑已出错并调用了 tx.Rollback()，再 defer tx.Commit() 就会 panic："invalid transaction"。
更危险的是：若你忘了在某个 return 分支前调用 tx.Commit() 或 tx.Rollback()，事务对象不会自动释放，连接卡在池中，后续请求会卡在 acquire connection timeout。
所以必须显式控制流程：
- 所有分支都必须以
tx.Commit()或tx.Rollback()结尾 - 不能依赖
defer做最终提交，只能用于 panic 捕获兜底 -
tx.Commit()的返回值必须检查，不能只写tx.Commit()
如何安全捕获 Commit 错误并做处理？
最稳妥的方式是把 Commit 放在成功路径末尾，并检查其 error：
tx := db.Begin()
defer func() {
if r := recover(); r != nil {
tx.Rollback()
}
}()
if err := tx.Create(&order).Error; err != nil {
tx.Rollback()
return err
}
if err := tx.Create(&payment).Error; err != nil {
tx.Rollback()
return err
}
// ✅ 显式 commit 并检查
if err := tx.Commit().Error; err != nil {
// 这里能拿到具体错误，比如 MySQL 的 ErrDeadlock、ErrLockWaitTimeout
log.Error("commit failed", "err", err)
return err
}
return nil
注意：tx.Commit() 返回的是 *gorm.DB，要取其 .Error 字段才能拿到真实错误；直接 if err := tx.Commit(); err != nil 是错的（语法不通过）。
db.Transaction 里怎么拿到 Commit 失败的 error？
db.Transaction() 内部确实会调用 tx.Commit()，但它**不暴露这个 error**——它只在 panic 或闭包返回非 nil error 时回滚，而 Commit 失败时它会直接返回那个 error，但你无法区分它是业务逻辑 error 还是提交失败。
所以如果你需要精细控制（比如对 ErrDeadlock 做重试、对 ErrLockWaitTimeout 降级），就别用 db.Transaction()，改用手动 Begin + 显式 Commit + 错误分类处理。
容易被忽略的一点：MySQL 在某些配置下（如 autocommit=1），Commit 可能静默成功但实际没生效；PostgreSQL 则更严格，任何提交失败都会透出明确 error。别假设 Commit 一定成功。
