不会。sql.db仅在连接失效时移除坏连接并新建，不自动重试；需手动用pingcontext探测、结合context控制超时与重试，且仅对临时错误（如timeout、connection refused）幂等重试。
数据库连接断开后 sql.DB 会自动重试吗？
不会。Go 标准库的 sql.DB 本身不维护“长连接”概念，它只是一个连接池抽象；当底层 TCP 连接因网络抖动、DB 重启或超时被关闭时，后续调用 Query、Exec 等方法**首次遇到失效连接，会返回错误（如 "i/o timeout" 或 "connection refused"），但不会静默重试**——它只会把该坏连接从池中移除，下次需要时新建一个。
所以「平滑恢复」不是框架或 sql.DB 自带能力，而是靠你控制重试时机、重试条件和连接健康检查逻辑。
用 db.PingContext 主动探测连接是否可用
在关键业务路径（比如 HTTP 请求入口、定时任务启动前）手动触发一次轻量探活，比等 SQL 执行失败再处理更可控。注意必须用带 context 的版本，避免无限阻塞：
-
db.PingContext不执行 SQL，只验证连接池中至少有一个可用连接（会复用空闲连接，或新建一个测试） - 若返回
"driver: bad connection"或"dial tcp: i/o timeout"，说明当前池已不可用，需等待恢复或触发降级 - 不要在每次 SQL 前都调用 —— 它有轻微开销，且频繁探测可能掩盖真实问题
示例：
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()
if err := db.PingContext(ctx); err != nil {
log.Printf("DB health check failed: %v", err)
// 此处可记录指标、告警，或跳过本次业务逻辑
}
写 SQL 时如何避免 panic 并区分临时错误与永久错误
Go 的 database/sql 在连接异常时返回的 error 类型是 error 接口，不能直接用 == 判断。要识别是否值得重试，得结合错误内容、驱动实现和场景判断：
- MySQL 驱动常见临时错误：
"i/o timeout"、"connection refused"、"invalid connection"、"write: broken pipe" - PostgreSQL 驱动常见临时错误：
"dial tcp: connect: connection refused"、"pq: server closed the connection unexpectedly" - **永久错误示例**：
"pq: relation \"users\" does not exist"（SQL 写错）、"Error 1045: Access denied"（权限配置错误）——这类不该重试 - 建议用
strings.Contains(err.Error(), "timeout") || strings.Contains(err.Error(), "connection refused")做简单匹配，比反射类型断言更兼容不同驱动
重试策略别写死在业务代码里
把重试逻辑耦合进 handler 或 service 层，会导致测试难、行为不一致、超时难以统一管控。推荐封装一层带上下文感知的执行器：
- 用
retryablehttp思路类比：定义一个DBExecutor，接受context.Context和重试配置（最大次数、初始延迟、退避因子） - 每次执行前检查
ctx.Err()，失败后按策略 sleep 再重试，而非简单 for-loop - 对写操作（
Exec）要谨慎重试——幂等性必须由业务层保障（比如用唯一索引 + ignore duplicate 错误） - 读操作（
Query）相对安全，但也要设好context.WithTimeout，防止重试链路拖垮整个请求
真正容易被忽略的是：连接池参数（SetMaxOpenConns、SetConnMaxLifetime）没调优时，即使加了重试，也会因连接泄漏或僵死连接堆积导致雪崩。先确认 db.Stats() 中的 InUse 和 Idle 是否长期失衡，再谈恢复机制。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
