Golang怎么数据库连接泄漏排查_Golang如何发现和修复未关闭的数据库连接【避坑】-Golang-PHP中文网

数据库连接泄漏最典型信号是sql.db.stats()中openconnections持续上升、inuse长期不归零且与实际并发严重不匹配；配合pprof goroutine堆栈搜索database/sql和conn.*阻塞点，可精准定位未释放连接的代码位置。

golang怎么数据库连接泄漏排查_golang如何发现和修复未关闭的数据库连接【避坑】

数据库连接泄漏最典型的信号不是内存涨得快，而是 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，导致后续请求排队等连接

Go 的 database/sql 不像 Java 有 try-with-resources，Close 必须显式调用，而且顺序和时机极易出错。

常见高危场景：

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/goroutine 只能看到“有连接卡住”，但不知道是哪个 SQL、哪个 handler。得结合运行时统计和代码埋点。

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

实操建议：

启动时开启连接池统计：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 只保证函数退出时执行，但如果函数本身 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 根本不执行