Go连接池不主动探活空闲连接，仅靠SetConnMaxLifetime到期报废和ResetSession取连接时懒检测；db.PingContext仅适合启动校验或低频巡检，不能替代连接生命周期管理。
Go 的 database/sql 连接池本身不自动检测连接存活
很多人误以为 db.Ping() 或设置 SetConnMaxLifetime 就能“保活”，其实不是。连接池只在归还连接时按需关闭超时连接，**从不主动探测空闲连接是否仍可达数据库**。如果网络中断、DB 重启或防火墙 kill 了长连接，db.Query() 可能直接返回 "i/o timeout" 或 "connection refused"，而不是自动重试或换新连接。
关键点：
-
SetConnMaxLifetime控制连接最大复用时长（比如 30m），到期后连接被关闭——但它不解决“中途断连”问题 -
SetMaxIdleConns和SetMaxOpenConns影响并发吞吐，和存活检测无关 -
db.Ping()是同步全链路探测（建连 + 认证 + 简单响应），适合启动时校验，但**不能高频调用**（会阻塞、耗资源）
用 sql.Open + 自定义健康检查实现轻量级保活
推荐在应用层加一个定时任务，对连接池中部分空闲连接做低频探测（非全量、非每次请求）。核心思路是：不干扰业务逻辑，只在连接“疑似失效”前主动清理。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 用
db.Stats().Idle获取当前空闲连接数，只对其中 1–2 个连接执行ping（避免压垮 DB） - 使用带超时的
context.WithTimeout(ctx, 2*time.Second)调用db.PingContext，防止探测卡死 - 若
PingContext失败，不用手动 Close —— 连接池会在下次归还时自动丢弃该连接；你只需记录日志，触发后续补偿逻辑（如重试或告警） - 建议每 30–60 秒执行一次，频率太高反而增加 DB 压力
示例片段：
go func() {
ticker := time.NewTicker(45 * time.Second)
defer ticker.Stop()
for range ticker.C {
if stats := db.Stats(); stats.Idle > 0 {
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
if err := db.PingContext(ctx); err != nil {
log.Printf("DB ping failed: %v", err) // 触发告警或降级策略
}
cancel()
}
}
}()遇到 "connection reset by peer" 或 "broken pipe" 时该不该重试
这类错误表明连接已断开，但 Go 的 database/sql 默认行为是：**立即返回错误，不重试，也不自动换连接**。是否重试，取决于 SQL 类型和业务语义。
判断依据：
- 对
SELECT类只读操作，可安全重试（前提是没修改本地状态） - 对
INSERT/UPDATE/DELETE，必须确认是否已执行成功——不能盲目重试，否则可能重复写入 - 更稳妥的做法是：捕获这些错误，在事务外包装一层幂等逻辑（例如用唯一索引 +
ON CONFLICT DO NOTHING） - 不要依赖
db.Exec返回的rowsAffected判断成败：连接断开时它根本不会返回有效值
真正需要“自动重连”的场景，应交由连接池之外的组件处理
比如服务启动失败、DNS 变更、主从切换等——这些不是连接池能解决的问题。这时候要跳出 database/sql 层，用更高阶方案：
- 用
pgxpool（PostgreSQL）或mysql驱动的interceptor接口，在Connect失败时自动 fallback 到备用地址 - 在 Kubernetes 中配合 readiness probe：用
exec调用mysql -h $DB_HOST -e "SELECT 1"，失败则重启 Pod - 对于跨机房部署，用服务发现（Consul / Nacos）+ 自定义 dialer，动态更新 DB 地址列表
单纯靠“重连”掩盖网络不稳定，容易掩盖真实故障点。真正难的从来不是重连动作本身，而是判断“此刻该不该连、连谁、连完怎么验证语义正确性”。
