db.PingContext仅支持一次性探测，不提供周期调度能力；它只验证连接池中至少一个连接可用，不能保活或触发重连，防连接失效应靠SetConnMaxLifetime（推荐240秒）并确保小于数据库wait_timeout。
db.PingContext 不能设“间隔”，它只是一次性探测
很多人想用 db.PingContext 实现定时心跳检测，但这是误解。它本身不支持周期调度，只是同步发起一次连接验证——调用即执行，返回即结束。GORM 和 *sql.DB 都没提供内置的 Ping 间隔配置项。
如果你看到日志里反复出现 Ping 调用，那一定是你自己在 goroutine 里手动循环调用的，不是框架行为。
常见错误现象：
- 把
db.PingContext塞进time.Ticker定时器，误以为能“保活”连接池 - 期望设置某个参数（比如
SetPingInterval）让 GORM 自动定期 Ping —— 这个方法根本不存在 - 用 Ping 成功就认为后续 Query 一定不会报
invalid connection—— 实际上完全不保证
真正该配的是连接生命周期：SetConnMaxLifetime
防连接老化失效，靠的不是 Ping，而是 SetConnMaxLifetime。它控制连接从创建起最多复用多久，到期自动关闭并新建。这才是生产环境防 invalid connection 的核心手段。
必须满足两个条件才有效：
-
SetConnMaxLifetime值要小于数据库服务端的wait_timeout（MySQL 默认 300 秒），推荐设为240 * time.Second - 该设置必须在
db.DB()获取底层*sql.DB后立即调用，且不能设为 0
示例：
sqlDB, _ := db.DB() sqlDB.SetConnMaxLifetime(240 * time.Second) // 留 60 秒缓冲 sqlDB.SetMaxOpenConns(100) sqlDB.SetMaxIdleConns(50)
启动阶段必须做一次阻塞 Ping，运行时别依赖它
服务启动时，用带超时的 db.PingContext 验证数据库可达性，失败直接 panic 或退出，避免带病上线。
运行时不要把它当健康检查用，原因很实在：
- 它只检查连接池中「至少一个」连接是否通，不刷新其他连接状态
- 高并发下刚 Ping 成功，下一秒 Query 仍可能因服务端主动断连而失败
- 它不触发重连逻辑，也不影响连接复用行为
正确姿势：
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()
if err := db.PingContext(ctx); err != nil {
log.Fatal("DB unreachable at startup:", err)
}
连接故障得自己捕获重试，不能等 Ping 发现
查询失败时，db.PingContext 不会自动被调用。你得在业务层显式判断错误类型，对连接类异常做幂等重试。
关键点：
- 只对
SELECT、GET类操作重试；写操作必须结合业务幂等 key 或状态校验 - 捕获明确的连接错误：如
driver.ErrBadConn、"connection refused"、"timeout" - 用
context.WithTimeout控制总重试耗时（建议 ≤ 2 秒），退避用指数增长（100ms → 200ms → 400ms）
复杂点在于：错误类型需按驱动解析，MySQL 和 PostgreSQL 的错误码前缀不同，不能只看 error string。
