Go中sql.Open不建立实际连接，首次db.Ping()或db.Query()才触发；需用context控制带间隔、次数限制的重试，避免雪崩，且仅重试建连而非重建*sql.DB。
连接失败时直接重试会立刻失败
Go 的 sql.Open 不真正建立连接，它只校验 DSN 格式；真正触发网络连接的是第一次执行 db.Ping() 或 db.Query()。如果数据库此时不可达，错误会立即返回，不会自动重试。盲目在 sql.Open 后加 for 循环调用 Ping() 而不控制间隔和次数，容易造成密集探测、拖慢启动，甚至被数据库端限流或拒绝。
- 必须显式调用
db.Ping()并捕获driver.ErrBadConn、context.DeadlineExceeded或具体网络错误（如"connection refused"） - 重试前至少 sleep 100ms，避免雪崩式重连
- 建议设置最大重试次数（如 5 次）和总超时（如 10s），用
context.WithTimeout包裹整个重试流程
用 context 控制重试生命周期
手动写 for + time.Sleep 容易出错，推荐用 context 统一管理超时与取消。重试逻辑应封装为一个独立函数，接收 *sql.DB 和 context.Context，在每次重试前检查 ctx 是否已取消或超时。
- 不要在重试循环里反复调用
sql.Open—— 连接池对象只需创建一次，重试的是“建连动作”，不是重建*sql.DB - 每次重试前调用
db.PingContext(ctx)，而非db.Ping()，确保能响应 cancel/timeout - 若重试中 ctx 被取消，应立即返回错误，不继续 sleep 或下一次循环
func waitForDB(db *sql.DB, ctx context.Context) error {
ticker := time.NewTicker(500 * time.Millisecond)
defer ticker.Stop()
for {
select {
case <-ctx.Done():
return ctx.Err()
case <-ticker.C:
if err := db.PingContext(ctx); err == nil {
return nil
}
}
}
}初始化阶段重试比运行时更关键
服务启动时数据库未就绪（如 Kubernetes 中 Pod 启动顺序不确定）是最常见场景。此时连接失败必须阻塞等待，否则后续所有请求都会 panic 或返回 500。而运行时连接断开（如网络抖动）可交由连接池自动处理 —— *sql.DB 默认启用 SetMaxOpenConns 和连接健康检测，多数临时故障无需手动干预。
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 应用启动入口（如
main()）应调用带重试的初始化函数，失败则 log.Fatal - 不要把重试逻辑放在 HTTP handler 里：每个请求都重试会放大压力，且无法解决启动依赖问题
- 生产环境建议配合 readiness probe 使用：K8s 在 probe 成功前不将流量导入该 Pod
注意 driver 自身的重试行为冲突
某些数据库驱动（如 pgx/v5）在配置了 connect_timeout 时，底层已有简单重试；若再在外层叠加重试，可能造成重复等待或时间叠加。MySQL 驱动（go-sql-driver/mysql）默认无重试，但支持 timeout、readTimeout 参数。
立即学习“go语言免费学习笔记（深入）”；
- 检查所用 driver 文档是否声明了自动重试机制，避免叠加
- 统一用
context.WithTimeout控制整体耗时，比依赖 driver 参数更可靠 - PostgreSQL 推荐用
pgxpool.ConnectConfig替代原生sql.Open，其Acquire()方法天然支持 context，且连接池自动处理坏连接驱逐
重试本身不难，难的是判断“该不该重”——启动期必须等，运行时大多不用管；重试参数（间隔、上限、超时）必须和你的部署环境匹配，而不是抄个通用值。
