不会。GORM事务不悬挂，网络中断时*sql.Tx立即失效，后续Commit/Rollback返回驱动错误；所谓“挂住”实为业务代码未显式处理错误导致资源未释放或协程阻塞。
事务执行中网络中断会导致连接悬挂吗
不会。GORM 本身不持有“连接”概念，事务生命周期完全由底层 *sql.Tx 控制；网络中断时，*sql.Tx 会立即失效，后续调用（如 Commit() 或 Rollback()）直接返回驱动错误（如 pq: write tcp: use of closed network connection），不会卡住或悬挂。
为什么你感觉“事务挂住了”
常见错觉来源是未正确处理事务结束逻辑，导致资源未释放、日志无输出、或上层协程阻塞在等待一个永远不会返回的结果。本质不是连接悬挂，而是业务代码没兜住错误：
- 忘记在
defer之外加显式Rollback()—— 例如只写defer tx.Rollback()，但事务已因网络中断提前失败，tx.Commit()报错后程序继续执行，defer还没触发，而你误以为它卡在 Commit - 在事务函数里用
panic但 recover 位置不对，导致defer未执行，tx对象被丢弃却未显式Rollback() - HTTP handler 中启动事务后，网络中断导致客户端断连，但服务端 goroutine 仍在等 DB 响应（实际驱动已报错，只是你没检查
err）
如何确保事务一定结束（不悬挂、不泄露）
核心原则：所有事务必须有明确的退出路径，且每条路径都显式调用 Commit() 或 Rollback()。不要依赖 defer + panic 捕获来兜底，尤其在跨协程或中间件场景下不可靠。
推荐写法（以 PostgreSQL 为例）：
func createOrder(tx *gorm.DB, order *Order) error {
if err := tx.Create(order).Error; err != nil {
return err // 不在这里 Rollback —— 调用方负责
}
if err := tx.Model(&User{}).Where("id = ?", order.UserID).Update("balance", gorm.Expr("balance - ? ", order.Amount)).Error; err != nil {
return err
}
return nil
}
<p>// 调用方统一控制事务边界
func PlaceOrder(db <em>gorm.DB, order </em>Order) error {
tx := db.Begin()
defer func() {
if r := recover(); r != nil {
tx.Rollback()
}
}()
if err := createOrder(tx, order); err != nil {
tx.Rollback()
return err
}
return tx.Commit().Error
}
关键点：
-
createOrder不碰tx.Commit()或tx.Rollback()，只传播错误 -
PlaceOrder是唯一决定事务命运的地方，无论成功、失败、panic，都确保tx被终结 -
tx.Commit().Error必须检查 —— 网络中断时这里大概率报错，如pq.Error.Code == "08006"，此时连接已断，但事务早已在驱动层回滚，你只需记录并返回
连接池会不会因此堆积无效连接
不会。database/sql 连接池对失效连接有自动清理机制：tx.Commit() 或 tx.Rollback() 后，底层连接会被归还到池中；若归还时检测到 I/O 错误（如写入失败），该连接会被立即丢弃，不会复用。
但要注意：如果事务函数长期不返回（比如你忘了 return、或死循环），连接会一直被 *sql.Tx 占用，无法归还 —— 这才是真·悬挂，和网络无关。所以务必保证事务函数有确定退出点，避免无条件等待。
真正容易被忽略的是：事务超时需由上层控制。GORM 无内置事务超时，建议用 context.WithTimeout 包裹整个事务流程，并在 db.WithContext(ctx) 后执行操作，否则网络卡死时可能 hang 住数分钟。
