Gin框架不感知数据库连接池满载，需通过sql.DB.Stats()监控WaitCount和WaitDuration并结合业务埋点主动发现；连接池满载表现为阻塞而非panic， Recovery中间件无法捕获，须用独立goroutine定期检测并接入健康检查。
直接结论：Gin 框架本身不感知、也不捕获数据库连接池满载，必须靠主动监控 sql.DB.Stats() + 业务层埋点来发现。
为什么 Gin 的中间件或 panic 恢复机制抓不到连接池满载
连接池满载（比如 WaitCount 持续上升、WaitDuration 累积变大）不是 Go 运行时 panic，也不是 HTTP 层错误，它发生在 db.Query 或 db.Exec 内部阻塞等待连接时——此时请求还在正常走 Gin 的 Context 生命周期，HTTP 状态码仍是 200，日志里也看不到异常。
常见误判是看到接口变慢就查 SQL 执行时间，但真实瓶颈可能早就在连接获取阶段卡住。
-
database/sql的连接获取逻辑在connPool.conn()里，超时前会一直阻塞，不抛 error - Gin 的
recovery()中间件只捕获 panic，对阻塞无能为力 - 哪怕你用
context.WithTimeout包裹 DB 调用，错误也是context.DeadlineExceeded，而非明确的 “连接池已满”
如何在 Gin 服务中低成本暴露连接池满载信号
核心思路：不等它爆，而是在 Wait 行为刚出现苗头时就告警。关键指标是 WaitCount 的环比增幅和 WaitDuration 的绝对值。
- 起一个独立 goroutine，用
time.Ticker每 5 秒调一次db.Stats()，保存上一周期值用于做差 - 当
stats.WaitCount - lastStats.WaitCount > 10且stats.WaitDuration > 500*time.Millisecond，触发日志告警（不要发 alert，先记下来） - 把该判断逻辑封装成
func(db *sql.DB) bool，在 Gin 启动时注册进健康检查路由：router.GET("/health/db", dbWaitDetector(db)) - 避免在每个 handler 里实时调
db.Stats()—— 它带读锁，高频调用会拖慢所有查询
连接池满载时 Gin 日志里最该盯住的两行
不是看 SQL 耗时，而是看连接生命周期是否断裂。以下日志模式一旦高频出现，基本可判定泄漏+满载正在发生：
-
rows.Close() called after rows.Next() returned false——rows.Close()被漏掉或 defer 写错位置 -
sql: database is closed—— 常见于事务中 panic 后未执行tx.Rollback()，导致连接未归还
这两类问题不会立刻报错，但会让 InUse 缓慢爬升、Idle 持续趋近于 0，最终把 WaitCount 推高。
别依赖 MaxOpenConns 上限硬控，要配好 SetConnMaxLifetime
很多人以为设了 db.SetMaxOpenConns(20) 就万事大吉，其实不然。连接池满载的深层原因常是“连接僵死”：MySQL 连接被防火墙中断、数据库重启、网络抖动，但 Go 客户端没感知，还把它当可用连接放池里，后续请求拿到就卡住。
- 必须配
db.SetConnMaxLifetime(30 * time.Minute)，强制老化连接重建 - 搭配
db.SetMaxIdleConns(5)，避免空闲连接长期占位却不健康 - 验证是否生效：观察
stats.TotalConnections是否随时间缓慢上涨 —— 如果涨得快，说明连接在不断新建却没被复用或回收
真正难排查的，永远是那些没显式报错、但让 Idle 慢慢归零、WaitCount 在凌晨三点悄悄破百的连接泄漏。它不炸，只是让你的服务越来越沉。
