数据库连接泄漏最典型信号是sql.DB.Stats()中OpenConnections持续上升、InUse长期不归零且与实际并发严重不匹配；配合pprof goroutine堆栈搜索database/sql和conn.*阻塞点，可精准定位未释放连接的代码位置。
怎么确认是数据库连接没关，而不是别的泄漏？
数据库连接泄漏最典型的信号不是内存涨得快，而是 sql.DB.Stats() 里 OpenConnections 持续上升、InUse 长期不归零，且和实际并发请求数严重不匹配。比如你 QPS 只有 20，但 InUse 却卡在 150+ 并持续爬升——基本可以锁定是连接没释放。
别急着翻业务代码，先看底层行为：
- 用
curl -s http://localhost:6060/debug/pprof/goroutine?debug=2查看所有 goroutine 堆栈，搜database/sql和conn.*相关调用，尤其留意阻塞在conn.begin、rows.Next或tx.Commit后没走tx.Rollback的 goroutine - 检查日志里有没有反复出现
sql: database is closed或driver: bad connection——这往往说明连接已失效但还在被复用，根源常是连接提前被 close 了，或根本没被归还到连接池 - 如果用了
db.SetMaxOpenConns(n)且n设得很小（比如 5），而监控显示WaitCount持续增长，那大概率是连接没及时 Close，导致后续请求排队等连接
哪里最容易漏掉 db.Close() 或 rows.Close()？
Go 的 database/sql 不像 Java 有 try-with-resources，Close 必须显式调用，而且顺序和时机极易出错。
常见高危场景：
立即学习“go语言免费学习笔记（深入）”；
-
rows, err := db.Query(...)后只判err != nil就 return，忘了defer rows.Close()——哪怕 Query 失败，rows也可能非 nil，必须 close - 在 for 循环里反复
db.QueryRow()或db.Query()，但把defer rows.Close()写在循环外，结果只有最后一次的 rows 被关 - 用
tx, err := db.Begin()启动事务，成功后分支太多（比如 if/else 嵌套深），某些路径漏了tx.Commit()或tx.Rollback()——只要没显式调用这两个之一，连接就永远不会归还 - 把
*sql.Rows或*sql.Tx当成普通 struct 返回给上层，上层又没约定好谁负责 Close，最后谁都没关
pprof + Stats 怎么联动定位具体哪段代码？
单靠 pprof/goroutine 只能看到“有连接卡住”，但不知道是哪个 SQL、哪个 handler。得结合运行时统计和代码埋点。
实操建议：
- 启动时开启连接池统计：
db.SetConnMaxLifetime(30 * time.Minute)和db.SetMaxIdleConns(20)，再定期打日志：log.Printf("db stats: %+v", db.Stats())，重点关注OpenConnections、InUse、Idle三者变化趋势 - 在关键 DB 操作前后加 trace 标签：比如
log.Printf("[DB] query %s start, conn id: %p", sql, rows)（rows地址可粗略标识连接实例） - 用 pprof 抓两个间隔 5 分钟的 goroutine 快照：
curl -s "http://localhost:6060/debug/pprof/goroutine?debug=2" > before.txt，再抓一次存为after.txt，用diff before.txt after.txt | grep -A5 -B5 "database/sql"看新增了哪些阻塞点 - 如果用了 ORM（如 GORM），注意它默认不自动 Close
Rows，db.Raw().Rows()或db.Find(&v).Rows()后仍需手动rows.Close()
为什么 defer rows.Close() 还会泄漏？
因为 defer 只保证函数退出时执行，但如果函数本身 never return（比如 goroutine 里起个死循环监听 channel），或者 panic 后 recover 了但没重新 panic，defer 就不会触发。
更隐蔽的是作用域陷阱：
for i := 0; i —— 这里 <code>defer绑定的是每次循环的新rows，但 Go 规范规定：所有 defer 语句在函数进入时就注册，变量捕获的是最后一次迭代的值。结果只有最后一次的rows被 close，前 9 次全漏- 用
sql.Scanner扫描时，如果rows.Next()返回 false 后没 break，继续rows.Scan()会 panic，而 recover 里忘了 close - HTTP handler 中，
return前写了defer rows.Close()，但 handler 被中间件提前 hijack（比如 gin 的c.Abort()或 fasthttp 的ctx.Stop()），defer 根本不执行
真正安全的做法是：所有 rows、tx、stmt 的生命周期必须和明确的作用域绑定，优先用函数封装 + 显式 error return，而不是依赖 defer；对关键路径，加 if rows != nil { rows.Close() } 双保险。
