连接泄漏表现为请求延迟升高、db.Stats().InUse持续上涨、WaitCount累积增长，最终触发context deadline exceeded或sql: database is closed；根本原因是未正确调用rows.Close()或未defer tx.Rollback()，需从代码层面修复而非调高连接池参数。
连接泄漏的典型表现和定位方法
连接池泄漏最直接的表现是：请求延迟逐渐升高、db.Stats().InUse 持续上涨不回落、db.Stats().WaitCount 累积增长，最终触发 context deadline exceeded 或 sql: database is closed。这不是偶发错误，而是资源未释放的明确信号。
别急着改配置——先确认是不是代码里漏了 rows.Close() 或没用 defer tx.Rollback()。高频出问题的位置包括：
- 使用
db.Query()后忘记调用rows.Close() - 事务中发生 panic 但没用
defer保证tx.Rollback() - 在中间件或 handler 中提前
return，跳过了后续清理逻辑 - 嵌套函数返回
*sql.Rows，但调用方没处理关闭
db.SetMaxOpenConns 和 db.SetMaxIdleConns 的真实作用边界
SetMaxOpenConns 不是“防泄漏”的开关，它只是硬性限制最大并发连接数；一旦达到上限，新请求会阻塞在 db.Query 等待，直到有连接被归还。而 SetMaxIdleConns 控制的是空闲连接保有量，设太小会导致频繁建连，设太大又浪费资源——但它本身不解决泄漏。
关键点在于：这两个参数只影响连接池行为，不替代代码层面的资源管理。常见误操作是把 MaxOpenConns 调到 1000 以为能“扛住”，结果泄漏仍在，只是报错延迟了。
合理配置参考（以 MySQL 为例）：
-
db.SetMaxOpenConns(50)：匹配数据库侧max_connections的 20–30%，避免压垮 DB -
db.SetMaxIdleConns(20)：约等于平均并发请求数，减少连接重建开销 -
db.SetConnMaxLifetime(30 * time.Minute)：强制淘汰老化连接，防止僵死
必须写进每个 Query/Transaction 的防护模式
泄漏几乎都发生在“一次查询”或“一个事务”的生命周期内。Gin 本身不介入数据库操作，所以防护逻辑必须显式编码。
推荐写法（带 recover + close 保障）：
func getUser(c *gin.Context) {
rows, err := db.Query("SELECT id, name FROM users WHERE id = ?", c.Param("id"))
if err != nil {
c.JSON(500, gin.H{"error": err.Error()})
return
}
defer rows.Close() // 必须放这里，不是函数末尾
<pre class="brush:php;toolbar:false;">var users []User
for rows.Next() {
var u User
if err := rows.Scan(&u.ID, &u.Name); err != nil {
c.JSON(500, gin.H{"error": err.Error()})
return
}
users = append(users, u)
}
if err := rows.Err(); err != nil {
c.JSON(500, gin.H{"error": err.Error()})
return
}
c.JSON(200, users)}
事务场景更需谨慎：
- 用
defer func() { if r := recover(); r != nil { tx.Rollback() } }()捕获 panic - 成功后必须显式
tx.Commit()，否则连接不会释放 - 不要在事务内直接 return，确保 rollback/commit 路径全覆盖
监控和自动化检测不能只靠日志
光看错误日志发现不了缓慢泄漏。要定期采集 db.Stats() 并暴露为 Prometheus 指标：
func reportDBStats() {
stats := db.Stats()
promDBInUse.Set(float64(stats.InUse))
promDBIdle.Set(float64(stats.Idle))
promDBWaitCount.Add(float64(stats.WaitCount))
promDBWaitDuration.Add(stats.WaitDuration.Seconds())
}
真正容易被忽略的是：WaitDuration 持续上升说明连接归还不及时，哪怕 InUse 看似平稳——这往往意味着某条慢查询或某个 handler 卡在了非数据库操作上，导致连接迟迟没被 close。
复杂点在于：泄漏可能跨多个中间件或 goroutine 发生，比如在异步任务里开了 db.Query 却忘了关。这种场景下，rows.Close() 必须和 db.Query() 在同一 goroutine 内完成，跨 goroutine 传递 *sql.Rows 是高危操作。
