sql.DB 初始化后必须调用 Ping() 或 PingContext() 验证连通性，否则首次 Query 可能因连接未建立而超时卡顿、报错模糊；SetConnMaxLifetime 应设为数据库 wait_timeout 的 80%，避免连接“假活”；事务必须显式 Commit/Rollback，防止连接泄漏。
sql.DB 初始化后不 Ping 就用，连接池可能“假活”
刚调用 sql.Open 返回的 *sql.DB 是个空壳，它不建立任何物理连接，只做配置解析。如果你跳过 Ping 或 PingContext 直接执行 Query，第一次失败会卡住几秒（取决于驱动默认超时），且错误信息模糊（比如 driver: bad connection），容易误判为网络问题。
必须在初始化完成后立即验证连通性：
-
PingContext比Ping更安全，可传入带超时的context.Context，避免启动卡死 - 失败时应立刻
db.Close()并返回错误，不能忽略或静默重试 - 别在
init()里做Ping—— 单元测试无法注入 mock DB，也不利于配置热加载
SetConnMaxLifetime 设为 0 或太大，连接会在半夜悄悄断开
PostgreSQL/MySQL 服务端会主动关闭空闲太久的连接（wait_timeout、tcp_keepalive 等）。如果 Go 的 SetConnMaxLifetime 没设，或设得比数据库侧 timeout 还长，连接池里那些“看起来还活着”的连接，下次复用时就会报 i/o timeout 或 invalid connection。
正确做法是留出缓冲：
立即学习“go语言免费学习笔记（深入）”；
- 查数据库当前
wait_timeout值（MySQL：执行SHOW VARIABLES LIKE 'wait_timeout'） - Go 侧设为该值的 80% 左右，例如服务端是 300 秒，Go 设
240 * time.Second - 绝对不要设为 0 —— 这等于放弃预防，把所有失效都甩给运行时报错兜底
- 注意：这个参数控制的是“出生后最多活多久”，和是否 idle 无关
事务没 Commit/Rollback，连接就永远卡在占用态
连接池耗尽最常见原因不是 QPS 高，而是事务泄漏。一个未闭环的 sql.Tx 会独占一条连接，直到 GC 或进程退出才释放 —— 而 GC 不会回收正在使用的连接。
典型泄漏场景：
-
defer tx.Rollback()写在if err != nil外层，但忘记用if tx != nil判断 - 函数中途 panic，
defer没触发（没 recover） - 在
for循环里反复tx.QueryRow却没 Close 结果集，某些驱动会阻塞连接归还 - 用
db.BeginTx(ctx, &sql.TxOptions{})但没检查返回 error，后续直接操作 nil*sql.Tx
排查方法：定期调用 db.Stats()，重点关注 OpenConnections 是否持续接近 MaxOpenConns，且 IdleConnections 长期为 0。
并发突增时 MaxOpenConns 配得太紧，会放大连接失效雪崩
当流量突然上涨，MaxOpenConns 被打满，所有连接都在高频使用中，SetConnMaxLifetime 的老化机制来不及清理旧连接。此时若数据库短暂抖动，大量连接会在恢复后集中失效，新请求又抢不到空闲连接，形成排队 → 超时 → 重试 → 更多排队的恶性循环。
缓解策略不是盲目调大 MaxOpenConns，而是组合控制：
- 压测确定真实峰值连接数，设
MaxOpenConns为该值的 1.2–1.5 倍 -
SetMaxIdleConns设为Min(MaxOpenConns, 20)，保证有常驻空闲连接应对突发 - 写操作加幂等 key + context 超时，避免重试放大写压力
- 健康检查接口（如
/healthz）里直接返回db.Stats()，而不是只看Ping成功与否
连接池不是黑盒，它的每个参数都在和数据库、网络、业务逻辑实时博弈——漏掉任意一环，都可能在凌晨三点让你收到告警。
