sql.Open仅初始化连接池而不建连，需配合db.PingContext()主动探测并重试；应设指数退避、双层超时（DSN级+context级）、连接池参数及ConnMaxLifetime防老化。
为什么直接用 sql.Open 不够用
因为 sql.Open 只是初始化连接池，并不真正建连；首次执行查询时才触发真实连接，此时若数据库不可达，会直接报错，比如 dial tcp 127.0.0.1:5432: connect: connection refused。这导致启动阶段无法感知 DB 是否就绪，也缺乏自动恢复能力。
常见错误现象：服务刚启动就 panic 或日志里反复刷出连接失败，但程序没做任何等待或重试，直接放弃。
- 必须配合
db.Ping()主动探测连接有效性 - 重试不能靠无限循环 —— 需要退避策略（如指数退避）避免雪崩
- 超时控制要分两层：单次拨号超时（
net.DialTimeout）、整体重试超时（外层 context）
用 context.WithTimeout 控制总重试时间
不要用 for + time.Sleep 硬等。Go 的 context 是标准解法，能统一取消所有 goroutine 和底层 dial 操作。
示例逻辑：给整个重试过程设 30 秒上限，每次失败后 sleep 1s、2s、4s… 最多试 5 次：
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
<p>var db *sql.DB
var err error
for i := 0; i </p><pre class="brush:php;toolbar:false;">// 主动 Ping，带 ctx 超时
if err = db.PingContext(ctx); err == nil {
return db, nil
}
// 指数退避：1s, 2s, 4s...
select {
case <p>}
return nil, fmt.Errorf("failed to connect to database after retries: %w", err)
</p>注意：db.PingContext 会受外层 ctx 约束，一旦超时，它会中断正在 dial 的连接尝试 —— 这比手动 sleep + 忽略错误更可靠。
DSN 里加 connect_timeout 防止单次卡死
PostgreSQL 和 MySQL 都支持在 DSN 中指定连接级超时，避免某次 dial 卡住几十秒拖垮重试节奏。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- PostgreSQL：
postgres://user:pass@localhost:5432/db?connect_timeout=5 - MySQL：
user:pass@tcp(localhost:3306)/db?timeout=5s
这个值建议设为 3–5 秒：太短容易误判（网络抖动），太长会让重试间隔失真。它和外层 context.WithTimeout 是互补关系 —— 前者管单次，后者管全局。
别忘了设置 db.SetConnMaxLifetime 和 db.SetConnMaxIdleTime
重试只解决「启动时连不上」，但生产环境还面临连接老化、网络中断、DB 重启等问题。如果连接池里的旧连接一直不释放，后续查询仍可能失败。
推荐组合（以 PostgreSQL 为例）：
-
db.SetConnMaxLifetime(30 * time.Minute)：强制连接最多活 30 分钟，避免被 DB 侧 kill -
db.SetConnMaxIdleTime(5 * time.Minute)：空闲连接 5 分钟后自动关闭，减少 stale 连接堆积 -
db.SetMaxOpenConns(20)和db.SetMaxIdleConns(5)必须显式设，否则 Go 1.19+ 默认MaxOpenConns=0（无限制），极易耗尽 DB 连接数
这些不是重试的替代品，而是让重试生效后，连接池本身具备长期健壮性的必要配置。漏掉任何一个，都可能在上线几天后突然出现大量 connection reset by peer 或 too many connections 错误。
