连接池阻塞的典型现象是HTTP接口响应变慢、P99延迟骤升（如从50ms跳至800ms+），netstat显示MySQL连接数逼近max_connections，pprof发现大量goroutine卡在database/sql.(*DB).conn或io.wait状态，本质是连接无法获取而非数据库性能下降。
连接池阻塞的典型现象是什么
HTTP 接口响应变慢、P99 延迟突然拉高（比如从 50ms 跳到 800ms+），netstat -an | grep :3306 | wc -l 显示 MySQL 连接数持续逼近 max_connections，pprof 查看 /debug/pprof/goroutine?debug=2 发现大量 goroutine 卡在 database/sql.(*DB).conn 或 io.wait 状态——这不是数据库慢，是连接拿不到。
怎么确认是连接池满而不是数据库慢
直接查数据库当前活跃连接：
- MySQL：
SHOW PROCESSLIST，重点关注Command列为Sleep且Time> 30s 的连接，以及State为Waiting for table metadata lock等非查询态连接 - PostgreSQL：
SELECT * FROM pg_stat_activity WHERE state = 'idle in transaction'，这类连接常因事务未提交/回滚卡住 - 对比你的
db.DB().SetMaxOpenConns(100)和SHOW VARIABLES LIKE 'max_connections'返回值，如果前者 ≥ 后者 × 0.8，大概率配置越界
别只盯着 GORM 日志——connection refused 或 dial tcp: connect: cannot assign requested address 是连接池已彻底失效的信号，不是起点。
最常被忽略的三个泄漏点
连接池“满”不等于“用得多”，更可能是“没还回去”：
-
tx := db.Begin()后没调tx.Commit()或tx.Rollback()：哪怕只是if err != nil { return }就退出，这个事务连接就永远卡在池子里，状态为idle in transaction -
rows, err := db.Raw(...).Rows()后没defer rows.Close()：rows不关，底层连接不会释放，尤其在err != nil时容易漏写defer - 在 HTTP handler 里反复调
gorm.Open()：每个新实例都带独立连接池，默认SetMaxOpenConns(0)，等于每请求建一堆裸连，文件描述符几分钟内耗尽
验证是否复用同一实例：fmt.Printf("%p", db) 在不同 handler 打印，地址必须一致；否则你调再多 SetMaxIdleConns 都白搭。
请求队列堆积怎么快速定位源头
GORM 本身不暴露排队队列，得靠底层 *sql.DB 的指标和行为反推：
- 开启
db.DB().SetConnMaxLifetime(3 * time.Minute)和db.DB().SetConnMaxIdleTime(30 * time.Minute)后，观察SHOW PROCESSLIST中连接的Time是否稳定在 3 分钟左右轮换——不轮换说明连接卡死 - 临时加日志：在关键查询前打点
time.Now()，查出某次db.First()耗时 2s 以上，再看它之前有没有未关闭的tx或rows - 用
go tool trace抓取 30s trace，过滤关键词database/sql，看conn获取阶段是否集中阻塞在某几个 goroutine
真正难排查的不是“连接不够”，而是“连接被某个 goroutine 持有却不释放”。事务没结束、rows 没 close、handler 里 new DB 实例——这三类问题一旦混在一起，pprof 上看起来全是“等待连接”，但根源各不相同。
