GORM不提供事务自动重试机制，需业务代码显式判断、回滚并重试；仅对可恢复错误（如死锁、连接中断）重试，须调用tx.Rollback()并配合指数退避。
GORM 本身不提供事务自动重试机制，事务失败后必须由业务代码显式判断、回滚并重试；盲目重试会破坏原子性，甚至引发数据不一致。
事务失败后手动重试的典型场景
常见于数据库连接闪断、主从切换延迟、锁等待超时（ErrLockWaitTimeout）、或短暂的网络抖动导致 tx.Commit().Error 非 nil。这类错误可恢复，但 GORM 不会自动重试 —— 它只保证单次事务的 ACID，不负责跨事务的容错。
- 仅对明确可恢复的错误重试，例如：
driver.ErrBadConn、sql.ErrNoRows（注意：后者通常不该重试）、context.DeadlineExceeded、或特定 MySQL 错误码如1205（死锁） - 避免对约束冲突（如唯一键重复）、语法错误、权限不足等永久性错误重试
- 重试前必须调用
tx.Rollback()，否则后续Begin()可能因连接状态异常而卡住
带指数退避的事务重试函数范式
以下是一个生产可用的重试封装，结合 context.Context 控制生命周期，并对死锁等典型错误做白名单过滤：
func RetryTransaction(ctx context.Context, db *gorm.DB, maxRetries int, operation func(tx *gorm.DB) error) error {
var err error
for i := 0; i err = operation(tx)
if err == nil {
if commitErr := tx.Commit().Error; commitErr != nil {
err = commitErr
tx.Rollback() // 确保清理
goto retry
}
return nil
}
// 显式回滚，释放锁和连接
tx.Rollback()
retry:
if i == maxRetries-1 {
return err
}
// 死锁或连接类错误才值得重试
if !shouldRetry(err) {
return err
}
// 指数退避 + jitter
wait := time.Duration(1<p>}</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2662" title="GORM框架 1.30.3"><img
src="https://img.php.cn/upload/manual/001/589/237/6a7d710f658be447.png" alt="GORM框架 1.30.3" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/gongju/2662" title="GORM框架 1.30.3" class="overflowclass">GORM框架 1.30.3</a>
<p class="overflowclass">GORM框架 1.30.3版本源码包下载，版本号 1.30.3，适合在 1.30 主线早期节点做源码留档、依赖回放和升级前后行为对照。</p>
</div>
<a rel="nofollow" href="/xiazai/gongju/2662" title="GORM框架 1.30.3" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div><p>func shouldRetry(err error) bool {
if errors.Is(err, gorm.ErrRecordNotFound) {
return false // not found 不该重试
}
var mysqlErr *mysql.MySQLError
if errors.As(err, &mysqlErr) {
return mysqlErr.Number == 1205 // Deadlock
}
if errors.Is(err, sql.ErrConnDone) || errors.Is(err, driver.ErrBadConn) {
return true
}
return false
}
</p>
-
operation函数内必须使用传入的tx，不可直接调用db.Create()等全局方法 - 每次循环都调用
db.Begin()，确保获取新事务上下文；不能复用已失败的tx -
goto retry是为了统一错误处理路径，避免嵌套过深；实际项目中也可用 continue 替代 - MySQL 错误需导入
github.com/go-sql-driver/mysql并类型断言，否则mysqlErr.Number无法访问
HTTP 请求 + GORM 事务混合重试的坑
当一个操作既涉及外部 HTTP 调用又修改数据库（如先调支付网关，再更新订单状态），不能简单把整个流程包进事务重试 —— HTTP 调用非幂等，重试会导致重复扣款。
- 正确做法：HTTP 调用单独加重试（带幂等 key），GORM 事务只重试本地 DB 操作
- 若必须强一致性，改用 Saga 模式：记录中间状态，失败时触发补偿事务（如退款）
- 不要在
operation函数里启动 goroutine 或传递未受控的context，事务对象非并发安全
最易被忽略的一点：GORM 1.20+ 虽然捕获了事务回调里的 panic，但它不会帮你重试 —— panic 被转成 error 后，仍需你在外层逻辑判断是否重试。别指望框架替你做决策。
