GORM事务不自动重连也不重试，因*sql.Tx绑定固定连接句柄，网络抖动导致driver: bad connection等错误；需手动封装幂等、带context控制和新建事务的重试逻辑。
事务遇到网络抖动时，GORM 本身不自动重连也不自动重试事务 —— 这是默认行为，也是最常被误以为“它会自己处理”的地方。
为什么 GORM 的 Transaction 在网络抖动后直接 panic 或返回 driver: bad connection
GORM 的事务对象（*gorm.DB）底层绑定的是 database/sql 的 *sql.Tx，而后者在创建后就持有一个**固定连接句柄**。一旦该连接因网络中断、超时、服务端 kill 等原因失效，后续任何 Commit() 或 Rollback() 都会触发底层驱动报错，比如：
-
sql: Transaction has already been committed or rolled back（已提交/回滚后还调用） -
driver: bad connection（连接断开但事务对象未感知） -
context deadline exceeded（网络超时发生在 Commit 阶段）
关键点：GORM 不会在 Commit() 失败时自动重试，也不会尝试换新连接重放整个事务逻辑 —— 它只负责把当前事务对象的状态交出去。
手动实现可重试事务的三个必要条件
要让事务在抖动后“自愈”，必须跳出 GORM 单次 Begin() → ... → Commit() 的线性流程，改用带状态控制和重试逻辑的封装。核心要点：
- 事务逻辑必须是**幂等的**：比如用
INSERT ... ON CONFLICT DO UPDATE（PostgreSQL）或INSERT IGNORE（MySQL），避免重复执行导致数据错乱 - 重试需配合
context.Context控制总超时，不能无限循环；建议设置maxRetries=3、baseDelay=100ms并指数退避 - 每次重试都应调用全新的
db.Begin()，而不是复用旧事务对象 —— 否则仍会复用坏连接 - 所有数据库操作必须在重试闭包内完成，不能把
*gorm.DB提前传入或缓存
示例片段（简化版）：
func RetryableTx(db *gorm.DB, fn func(tx *gorm.DB) error, opts ...RetryOption) error {
cfg := applyRetryOptions(opts...)
var lastErr error
for i := 0; i // 使用
err := RetryableTx(db, func(tx *gorm.DB) error {
return tx.Create(&User{Name: "Alice"}).Error
})
连接池配置对事务恢复的实际影响
很多人以为调大 SetMaxOpenConns 就能扛抖动，其实作用有限 —— 事务用的是独占连接，抖动后坏连接不会自动从池中剔除，除非驱动支持连接健康检查（如 mysql 驱动的 timeout 参数或 pgx 的 healthCheckPeriod）。真正有效的配置组合是：
-
db.SetMaxIdleConns(10)：保持一定空闲连接，减少新建开销 -
db.SetConnMaxLifetime(30 * time.Minute)：强制老化连接，避免长期存活的僵死连接 -
db.SetConnMaxIdleTime(5 * time.Minute)：及时回收空闲太久的连接 - MySQL 驱动加
&parseTime=true&timeout=5s&readTimeout=10s&writeTimeout=10s，让底层更快感知断连
注意：SetConnMaxLifetime 对正在使用的事务连接无效，只影响空闲连接；事务中的连接生命周期由 Commit()/Rollback() 决定。
软删除 + 事务重试时容易漏掉的坑
如果模型启用了 GORM 软删除（DeletedAt 字段），且事务里混用了 Delete() 和 Unscoped().Delete()，重试时可能产生非预期行为：
- 第一次
Delete()成功但Commit()失败 → 数据已软删，但事务未确认 → 重试时再次Delete()会静默成功（因为软删只是更新DeletedAt），但业务上可能误判为“两次删除” - 若重试逻辑没做幂等校验（例如先查再删），可能因第一次已软删、第二次查不到而跳过删除，造成数据残留
对策：涉及软删除的操作，务必在重试闭包内显式判断记录当前状态（如用 FirstOrInit + Save 替代裸 Delete），或统一走 Unscoped() 配合唯一约束兜底。
真正的难点不在写重试逻辑，而在于判断哪些操作值得重试、哪些必须立即失败 —— 比如资金扣减类事务，重复执行可能引发资损，这时候宁可人工介入，也不能盲目自动重试。
