db.PingContext不能保活连接，仅验证池中至少一个连接可用，无法防止后续Query失败；真正有效的是SetConnMaxLifetime（应比数据库wait_timeout小60秒），配合合理MaxOpenConns、幂等重试及Conn()显式关闭。
Go 连接池在高负载下出现连接断开或死锁，不是配置没调好，而是资源生命周期、错误处理和 goroutine 协调三者没对齐。
db.PingContext 为什么不能保活连接
很多人在重试逻辑里反复调用 db.PingContext，以为能“探测并清理坏连接”，但实际它只检查连接池中「至少一个」连接是否可用，且这个连接可能刚被 MySQL 服务端因 wait_timeout 关闭，而客户端尚未感知。下次 db.Query 仍会报 invalid connection 或 driver: bad connection。
-
db.PingContext不刷新其他连接状态，也不触发连接重建 - 它不带超时控制的原始
db.Ping()更危险：超时后仍阻塞，卡住整个重试流程 - 真正起作用的是
db.SetConnMaxLifetime—— 它强制连接“出生后最多活多久”，而非“空闲多久”
SetConnMaxLifetime 设置不当引发雪崩
MySQL 默认 wait_timeout = 28800（8 小时），但生产环境常设为 300 秒（5 分钟）。若 Go 连接池未同步调整，旧连接会在服务端关闭后继续被复用，导致批量失效。
- 安全值应比
wait_timeout少至少 60 秒，例如设为240 * time.Second - 设为 0 表示永不过期 → 放弃预防，全靠出错重试兜底，风险极高
- 该设置对所有连接统一生效，与 idle 状态无关；PostgreSQL 用户还需配
tcp_keepalives_idle等参数协同
并发突增时 MaxOpenConns 加剧连接失效
当 QPS 突增，db.SetMaxOpenConns(20) 打满后，所有连接高频使用，老化机制来不及清理旧连接。更危险的是：数据库短暂不可达后恢复，连接池里大量连接集中失效，引发雪崩式重连请求。
立即学习“go语言免费学习笔记（深入）”；
-
MaxOpenConns必须按压测结果设定，不能照搬文档推荐值（如 100） - 配合
SetMaxIdleConns和SetMaxIdleConnsClosed控制空闲连接数，避免冷启动时连接堆积 - 重试必须带 context 超时（如
context.WithTimeout(ctx, 2*time.Second)），且用指数退避（100ms → 200ms → 400ms…）
事务中 Conn() 未 Close 导致连接泄漏
手动调用 q.DB.Conn(ctx) 获取底层连接后，若未显式 conn.Close()，该连接不会归还给池子，造成 SLEEP 线程堆积、连接数持续上涨。
- 除非明确需要独占连接（如长事务、特殊隔离级别），否则直接用
db.BeginTx，别碰Conn() - 若必须用
Conn()，务必确保defer conn.Close()在所有分支执行，包括 error 返回路径 - 注意：
conn.Close()不等于断开网络，只是归还给连接池；它不能在事务提交/回滚后重复调用
最易被忽略的一点：死锁往往不是单个 goroutine 卡住，而是 dispatcher-worker 模式中 channel 关闭时机错位 + 无缓冲 channel 写入无人接收 + WaitGroup 和 channel 信号混用——这三者叠加，会让程序在高负载下才暴露问题，本地压测都难复现。
