应重试而非直接panic：先sql.open获取*sql.db，再用db.pingcontext配合context.withtimeout和指数退避重试，认证失败等不可重试错误需立即退出，并配置连接池参数防stale连接。
连接失败时直接 panic 还是重试？
Go 的 sql.Open 本身不真正建连，只校验 DSN 格式；真正失败通常在第一次 db.Ping() 或执行查询时暴露。如果启动阶段数据库还没就绪（比如 Docker Compose 里依赖服务启动慢），不重试就直接 panic，服务会反复崩溃重启——这不是优雅，是放弃治疗。
应该主动等，但别无脑死循环：time.Sleep 太粗暴，context.WithTimeout 必须配 db.PingContext 才生效，否则超时了还在等。
- 用
context.WithTimeout(context.Background(), 30*time.Second)控制总等待时间 - 每次重试前加指数退避（如 1s → 2s → 4s），避免打爆数据库健康检查端点
- 必须用
db.PingContext(ctx)，不是db.Ping()；后者忽略 context 超时
重试逻辑该放在 main() 里还是封装成函数？
放在 main() 里容易写成面条代码，下次加 Redis 重试又要复制一遍。封装成独立函数更可控，还能复用错误判断逻辑（比如区分是网络不通还是密码错）。
关键点是：不要在重试函数里反复调用 sql.Open。它返回的 *sql.DB 是连接池句柄，应只初始化一次；重试的是「建连验证」，不是「重建句柄」。
- 先调
sql.Open得到*sql.DB，再传给重试函数 - 重试函数只做
PingContext+ sleep + 错误分类（timeout/dial tcp/password authentication failed） - 遇到认证失败类错误（如
password authentication failed）应立即退出，重试没意义
为什么 db.Ping() 成功后还会在 Query 时报 connection refused？
db.Ping() 只从连接池取一个空闲连接做探活，不代表后续所有连接都可用。连接池里的连接可能被数据库主动断开（如 PostgreSQL 的 tcp_keepalives_idle 设置短），或网络中间件回收了 idle 连接。
所以光靠启动时 Ping 一次远远不够。得靠 *sql.DB 自身的配置来维持健康：
- 设
db.SetMaxOpenConns(20)避免连接数爆炸 - 设
db.SetConnMaxLifetime(10*time.Minute)强制定期换连接，防 stale - 设
db.SetConnMaxIdleTime(5*time.Minute)清理长期空闲连接 - 业务层所有
Query/Exec必须检查 error，对driver.ErrBadConn做重试（但仅限幂等操作）
用第三方库（如 backoff）有必要吗？
简单场景不用。标准库的 time.AfterFunc + time.Sleep 足够实现带退避的重试。引入 backoff 或 retry 库反而增加心智负担，尤其当团队不熟悉其重试策略（比如是否默认重试 5xx、是否自动 jitter）。
真要上库，注意两个坑：
-
backoff.Retry默认不传 context，无法响应服务关闭信号 - 很多库对
*sql.DB的错误类型识别太宽泛，把password authentication failed也当成可重试错误 - 不如手写 20 行带
ctx.Done()检查的 for-select 循环清晰
复杂点在于：重试不是越勤快越好，而是得区分错误类型、控制退避节奏、配合连接池生命周期管理。漏掉任意一环，都可能让“重试”变成“雪崩”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
