根本原因是连接被数据库服务端主动断开（如MySQL wait_timeout、PostgreSQL tcp_keepalives_idle），而Go默认不探测池中连接实时状态；必须设SetConnMaxLifetime（5–30分钟）强制重建，配合SetConnMaxIdleTime（≤前者）防空闲连接“睡死”。
为什么 db.Ping() 成功后，后续查询仍报 connection refused 或 broken pipe
根本原因不是连接池“失效”，而是连接在池中存活过久，被数据库服务端主动断开（如 PostgreSQL 的 tcp_keepalives_idle、MySQL 的 wait_timeout），而 Go 的 *sql.DB 默认不会主动探测连接是否还活着。
仅靠初始化时一次 Ping() 无法保证后续所有连接都可用；Ping() 只验证当时能连上，不校验池中每个连接的实时状态。
-
SetConnMaxLifetime()必须设置（推荐5–30m），强制连接在超时后被关闭并重建，避免复用已断开的 TCP 连接 -
SetConnMaxIdleTime()同样关键（建议 ≤MaxLifetime），防止空闲连接在池里“睡死”太久，醒来即失效 - 不要依赖
db.Ping()做运行时健康检查——它每次都会从池中取一个连接去试，可能取到刚被 DB kill 的连接，反而引发错误
SetMaxOpenConns 和 SetMaxIdleConns 数值怎么设才不翻车
这两个参数不是越大越好，错配会直接导致数据库连接耗尽或应用阻塞。
-
SetMaxOpenConns(25)是安全起点，但需结合数据库最大连接数（如 PostgreSQL 默认100，MySQL 常为151）留出余量；超过会导致新请求在db.Query时无限等待 -
SetMaxIdleConns(10)建议设为MaxOpenConns的 30%–50%，过高会浪费 DB 连接资源，过低则频繁建连（尤其在突发流量下） - 若应用部署在多实例容器中（如 Kubernetes），必须按单实例配置，不能按总 QPS 算全局连接数——每个 Pod 都有自己的
*sql.DB实例
连接池里“空闲连接”到底什么时候会被回收
Go 的连接池不靠定时器轮询清理，而是靠“懒回收”：只有当连接被归还到池中、且满足以下任一条件时，才会被真正关闭：
立即学习“go语言免费学习笔记（深入）”；
- 该连接已存在时间 ≥
SetConnMaxLifetime()设置值 - 该连接在池中空闲时间 ≥
SetConnMaxIdleTime()设置值 - 连接池收到
Close()调用，所有连接被立即标记为“不可再用”，后续归还操作会被忽略
这意味着：即使你设置了 ConnMaxIdleTime = 2m，如果某连接刚被归还就立刻被下一个 goroutine 拿走，它就不会被回收——这是设计使然，不是 bug。
如何确认当前连接池真实状态，而不是靠猜
别只看日志或监控图表，直接查 *sql.DB.Stats() 是最准的：
stats := DB.Stats()
fmt.Printf("open: %d, inuse: %d, idle: %d, wait: %d, wait_dur: %v\n",
stats.OpenConnections, stats.InUse, stats.Idle, stats.WaitCount, stats.WaitDuration)
-
WaitCount > 0且WaitDuration持续增长 → 连接不够用，优先调高MaxOpenConns -
InUse == MaxOpenConns且Idle == 0→ 池已满负荷，但未必是瓶颈，需结合 SQL 执行耗时判断 -
OpenConnections远大于InUse + Idle→ 可能有连接泄漏（比如rows未Close()、tx未Commit()/Rollback()）
真正难排查的不是参数设错，而是连接没被正确归还——这不会报错，只会悄悄拖垮整个池。
