根本原因是误用 db.Transaction() 或 tx.Begin() 在已有事务中反复创建新事务句柄，导致连接池耗尽；GORM 的静默降级使开发者误以为获得独立事务，实则每层都争抢新连接而旧连接未释放。
为什么嵌套事务调用会导致连接耗尽
根本原因不是“嵌套事务”本身，而是误用 db.Transaction() 或 tx.Begin() 在已有事务中反复创建新事务句柄。database/sql 标准要求：在已有 *sql.Tx 上调 Begin() 必 panic（如 pgx 报 pq: SAVEPOINT can only be used in transaction blocks），但 GORM 的 tx.Begin() 为兼容性做了静默降级——它不 panic，而是悄悄执行 SAVEPOINT。问题在于：开发者误以为返回的是独立事务，继续往里塞 db.Transaction() 回调，结果每层都试图从连接池取新连接，而底层实际没释放旧连接，最终池子被占满、新请求卡死在 acquireConn 阻塞。
如何识别和避免无效的“嵌套”调用
以下写法看似合理，实则危险：
db.Transaction(func(tx *gorm.DB) error {
// ✅ 正确：复用 tx
tx.Create(&user)
// ❌ 危险：又开一层 Transaction，会尝试拿新连接
return db.Transaction(func(inner *gorm.DB) error {
inner.Create(&profile) // 实际走默认 db 连接池，不参与外层事务！
return nil
})
})
- 永远不要在
db.Transaction()回调内再调db.Transaction()—— 它无法感知外层事务上下文，只会新建连接 -
tx.Begin()在已有事务中返回的仍是同一个*gorm.DB实例，不是新事务；inner.Commit()被 GORM 忽略，无意义 - 若全局配置了
DisableNestedTransaction: true，tx.SavePoint()会静默失效，且无 warning，调试时极难发现
真正该用 SavePoint 的地方和写法
需要局部回滚（比如用户创建成功，但地址校验失败只撤回地址操作），必须放弃 db.Transaction() 封装，改用手动事务 + 显式保存点：
tx := db.BeginTx(ctx, &sql.TxOptions{Isolation: sql.LevelReadCommitted})
defer func() {
if r := recover(); r != nil {
tx.Rollback()
}
}()
if err := tx.Create(&user).Error; err != nil {
tx.Rollback()
return err
}
tx.SavePoint("sp_address_upsert")
if err := tx.Create(&address).Error; err != nil {
tx.RollbackTo("sp_address_upsert") // 只撤回 address 操作
}
// 其余操作继续用 tx...
if err := tx.Commit(); err != nil {
return err
}
- 保存点名必须固定可读，如
"sp_address_upsert"，不能用随机字符串，否则并发下易覆盖 - 不要在循环里动态生成保存点名，
uuid.NewString()[:8]在高并发下仍有碰撞风险 -
tx.SavePoint()和tx.RollbackTo()必须成对出现在同一事务生命周期内；外层Commit()或Rollback()后，所有保存点自动失效
连接池耗尽后的紧急排查与修复点
一旦出现连接耗尽，别急着调大 SetMaxOpenConns，先确认是否是事务泄漏：
- 检查日志里是否有大量
failed to acquire database connection或context deadline exceeded，这往往是事务未关闭的信号 - 用
db.DB().Stats()输出当前连接状态：OpenConnections持续高于MaxOpenConnections，说明有连接没归还 - 重点 audit 所有手动
Begin()调用：是否每个都配了Commit()或Rollback()？是否漏了defer或 panic 处理？ - 禁用所有非必要外部调用（HTTP/Redis/MQ）在事务体内部，它们超时会直接拖住整个事务连接
最隐蔽的坑是：你以为用了 tx.AfterCommit() 就安全了，但如果钩子里 panic，虽然不影响数据库，但可能掩盖了上游事务已卡住的事实——得靠监控指标（事务 P99 耗时、连接池等待数）提前暴露。
