事务提交卡死主因是连接池耗尽而非事务逻辑错误，表现为db.Transaction阻塞在等待空闲连接，需检查waiting数、设置ConnMaxLifetime/IdleTime、避免事务中嵌套HTTP调用并规范手动事务恢复机制。
事务提交卡死，八成是连接池没拿到连接
不是事务逻辑写错了，而是 db.Transaction 一进去就卡住不动——这基本等于在等空闲连接。GORM 的事务函数（比如 db.Transaction）底层会从连接池里取一个连接，如果池子里没空闲的、又没超时，就会一直阻塞。你看到的“卡死”，其实是线程在 HikariPool - waiting for idle object 状态里挂起。
- 检查日志里有没有
Timeout waiting for idle object或类似提示，有就是连接池耗尽的明确信号 - 用
db.DB().Stats()打印实时状态：total（总连接数）、idle（空闲数）、waiting（排队等待数）——重点关注waiting是否持续增长 - 别只看 GORM 日志，要查数据库侧的
SHOW PROCESSLIST，确认是不是大量连接处于Sleep状态却没释放
connection-timeout 不设，事务就可能永远卡住
很多项目把 SetConnMaxLifetime 和 SetMaxOpenConns 都调了，唯独漏掉 connection-timeout。这个值不设，默认是无限等待，意味着只要池子空了，db.Transaction 就会一直 hang 在那里，直到有连接归还——而如果那个连接恰好因为 panic、未关闭的事务或网络中断卡住了，它就永远不会回来。
- MySQL + HikariCP 场景下，必须显式设置
sqlDB.SetConnMaxLifetime(time.Hour)和sqlDB.SetConnMaxIdleTime(30 * time.Minute) -
sqlDB.SetConnMaxLifetime要比数据库服务端的wait_timeout小至少 1~2 分钟，否则 DB 主动断连后，GORM 还拿着一条死连接 - 最关键的：一定要配
sqlDB.SetConnMaxIdleTime，否则空闲连接不会被主动清理，泄漏不易暴露
手动事务没 recover，连接就真的丢了
用 db.Begin() 开启手动事务时，如果中间 panic 了且没捕获，那这个连接大概率不会被归还到池子——它被 goroutine 带走了，再也不会回来。这不是 GORM 的 bug，是 database/sql 底层连接复用机制决定的：连接必须由同一个 goroutine 显式 Close() 或归还，panic 会直接中断流程。
- 所有
tx := db.Begin()后必须紧跟defer func() { if r := recover(); r != nil { tx.Rollback() } }() - 哪怕你确定不会 panic，也要加
defer tx.Rollback()，并在成功路径最后显式tx.Commit()，避免遗漏 - 优先用
db.Transaction(func(tx *gorm.DB) error {...})这种闭包式写法，它内部做了 recover 和自动归还，更安全
事务里嵌套 HTTP 调用，等于给连接池上刑
常见但极其危险的操作：在 db.Transaction 闭包里调用外部 HTTP 接口（比如发通知、调支付网关）。一旦那个 HTTP 请求超时或失败，整个事务就卡住，连接占着不放，池子迅速见底。
- 事务边界必须严格限定在数据库操作内，HTTP、Redis、消息队列等远程调用一律移出事务体
- 需要强一致的场景，改用本地消息表 + 定时任务补偿，而不是在事务里同步调外部服务
- 如果非得触发下游，至少加 context.WithTimeout 控制最大耗时，并确保 timeout 后能快速 rollback，不拖住连接
事务卡死最麻烦的地方，往往不是代码写错，而是连接池参数和业务逻辑耦合得太紧——比如 SetMaxOpenConns 设了 50，但某次批量导入开了 10 个 goroutine 各自启动事务，每个事务又嵌套了 3 次 HTTP 调用，结果瞬间吃光连接还无法释放。这种问题不会报错，只会让整个服务慢慢变冷。
