数据库连接池爆满的真实错误信号是context.deadlineexceeded或i/o timeout类错误，而非直接提示“pool exhausted”；需通过errors.is(err, context.deadlineexceeded)和字符串匹配双重判断，并统一转为db: connection pool exhausted错误返回503。
如何识别数据库连接池爆满的真实错误信号
数据库连接池爆满不会直接抛出“connection pool exhausted”这类明确提示，Go 的 database/sql 在获取连接超时后，统一返回 context.DeadlineExceeded 或 sql.ErrConnDone，而底层驱动（如 mysql）可能进一步包装为 *net.OpError。你看到的往往是 driver: bad connection、i/o timeout 或空指针 panic（因 db.QueryRow() 返回 nil 后直接调用 .Scan()）。这些都不是根本原因，只是表象。
在 Gin handler 中正确捕获并区分连接池问题
不能只靠 if err != nil 判断就返回 500——那会把参数校验失败、业务逻辑错误和连接池枯竭混为一谈。必须对 error 做类型和内容双重检查：
- 用
errors.Is(err, context.DeadlineExceeded)检测上下文超时（最常见于连接池满 +db.SetConnMaxLifetime设置不合理） - 用
strings.Contains(err.Error(), "timeout") || strings.Contains(err.Error(), "i/o timeout")辅助判断网络层阻塞 - 避免直接
panic(err)——这会触发全局 recovery，但掩盖了是 DB 层问题，不利于告警分级 - 推荐统一转为自定义 error：
errors.New("db: connection pool exhausted")，并在 recovery 中识别该前缀，返回 503 Service Unavailable 而非 500
为什么 Gin 的默认 Recovery 中间件抓不到连接池异常
它只捕获 panic，而连接池耗尽本身不 panic，它只是让 db.Query() 等方法返回 error。真正 panic 的，往往是开发者没检查这个 error 就继续用了结果集，比如：
row := db.QueryRow("SELECT name FROM users WHERE id = ?", id)
var name string
row.Scan(&name) // ← 若 row == nil 或内部 error 被忽略，此处 panic
所以关键不在 recovery，而在 DB 调用链每一步都做 if err != nil 分支处理，并主动 abort。别依赖 recover 救火。
连接池配置与监控必须同步落地，否则捕获无意义
光在代码里识别错误不够，得让问题可追溯。三项必须项：
- 调用
db.Stats()定期打点：关注WaitCount（等待连接的总次数）和WaitDuration（累计等待时间），突增即预警 - 设置合理的池参数：
db.SetMaxOpenConns(20)、db.SetMaxIdleConns(10)、db.SetConnMaxLifetime(60 * time.Second)—— 过长的 lifetime 会导致连接僵死，加剧排队 - 在 HTTP middleware 中记录 DB 调用耗时，当某接口平均 DB 耗时 > 300ms 且错误率上升，优先查连接池而非 SQL 本身
连接池问题从来不是单点故障，它是慢查询、未关闭事务、连接泄漏、并发突增共同作用的结果。捕获 error 只是第一道门，背后得有指标、有配置、有归因路径，否则每次都是救火。
