setconnmaxlifetime 是强制连接到期报废的关键参数，必须设置且应比数据库 wait_timeout 小至少 60 秒；空闲连接无自动探活，实际探活发生在驱动 resetsession（如 mysql 执行 select 1），仅限取连接时懒检测；pingcontext 不是健康检查手段，仅适合启动校验或低频巡检。
sql.DB 的空闲连接不会自动探活，得靠 SetConnMaxLifetime 驱动被动淘汰
Go 标准库的 *sql.DB 不会在连接空闲时主动发心跳或读检测。所谓“健康检查”其实是懒惰的：它不提前验证，而是在连接被取出、准备复用前，由驱动（如 go-sql-driver/mysql）在 ResetSession 里做一次轻量级探测。这个探测本身不保证 100% 可靠，且只发生在 Get 连接那一刻。
真正起作用的是 SetConnMaxLifetime —— 它强制连接“出生后最多活多久”，到期就从池中踢出，下次需要时新建。这不是探活，是“到期报废”。所以别指望空闲连接自己保活，得靠这个参数兜底。
-
SetConnMaxLifetime必须设，推荐值比数据库wait_timeout小至少 60 秒（例如 DB 设 300s，Go 端设 240s） - 设为 0 表示永不过期，等于放弃预防，等出错再重试，生产环境不建议
- 该设置对所有连接统一生效，不管是否 idle，也不区分读写状态
MySQL 驱动的 ResetSession 是实际探活发生的位置
当你调用 db.Query 或 db.Exec，连接池分配一个连接后，go-sql-driver/mysql 会先调 ResetSession 方法。这里才是真正的探活逻辑入口：它尝试执行一条轻量 SQL（如 SELECT 1）或做一次非阻塞读检测，失败就标记连接为 driver.ErrBadConn，触发重试流程。
这个机制依赖驱动实现，不是 *sql.DB 自带能力。PostgreSQL 驱动（lib/pq）行为不同，基本不主动探活，更依赖 SetConnMaxLifetime + TCP keepalive 协同。
- 探活失败后，
*sql.DB会自动重试一次（仅限driver.ErrBadConn场景），但最多 10 次硬编码重试，不可配置 - 若探活卡住（比如网络抖动但没断），会受
context超时控制；没传 context 就可能 hang 住 - 不要在业务代码里手动调
ResetSession，它是内部钩子，暴露出来反而破坏封装
手动探活容易踩坑：PingContext ≠ 健康检查
很多人用 db.PingContext 做定时健康检查，但它只验证“池里至少有一个连接能通”，不检查全部连接，也不影响后续复用逻辑。一次 Ping 成功，不能保证下一秒 Query 就不报 invalid connection。
更危险的是：在高并发场景下，频繁调 PingContext 会争抢连接，反而加剧池内连接耗尽风险，尤其当 MaxOpenConns 已接近上限时。
-
db.PingContext只适合启动时校验或低频巡检（如每分钟一次），不适合每秒调用 - 别把它当保活手段——它不刷新其他连接状态，也不清理失效连接
- 真要监控连接质量，应结合
db.Stats()看WaitCount、MaxOpenConnections和OpenConnections的趋势
异常恢复必须自己补足幂等重试
*sql.DB 内置的重试只覆盖极少数错误类型（主要是 driver.ErrBadConn），且不区分操作类型。遇到网络闪断、DNS 变更、主从切换，它大概率直接返回错误，不会重试。
生产环境必须自己封装重试逻辑，但要注意：不是所有操作都能重放。
- 只对
SELECT、GET类幂等操作重试；INSERT/UPDATE必须配合业务唯一键或 idempotency key - 重试需用指数退避（如 100ms → 200ms → 400ms），总超时建议 ≤ 2s
- 捕获明确错误：除了
driver.ErrBadConn，还要处理net.OpError、"timeout"、"connection refused"
SetConnMaxLifetime 必须设，且必须比数据库侧 timeout 小；还有，别把 PingContext 当万能健康检查。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
