db.pingcontext不能当健康检查用，因只验证连接池中至少一个连接可用，不保证后续query所用连接仍有效；mysql服务端wait_timeout到期后会单方面关闭连接，而go客户端可能复用“僵尸连接”，导致ping成功后query仍报"invalid connection"。
db.PingContext 为什么不能当健康检查用
它只验证连接池中至少一个连接可用，不保证后续 Query 所用连接仍有效。MySQL 服务端 wait_timeout 到期后会单方面关闭连接，而 Go 客户端可能还在复用这条“僵尸连接”——db.PingContext 成功后，下一次 db.Query 仍可能报 "invalid connection" 或 driver.ErrBadConn。
常见错误现象：
- 高频调用
db.PingContext做“保活”，结果 QPS 上去后错误率反而飙升 - 在 for 循环里反复 ping，却没配
ctx超时，goroutine 卡死 - 误以为 ping 成功 = 连接池健康，跳过幂等重试逻辑
必须做到：
- 永远用
db.PingContext(ctx)，且ctx带超时（如2 * time.Second） - 不把它放进重试主循环；它不刷新其他连接状态，也不触发重建
- 仅用于启动探活或低频巡检，不能替代错误重试机制
SetConnMaxLifetime 设置不当引发雪崩
这个值控制连接“出生后最多活多久”，和是否空闲无关。若设为 0 或 ≥ 数据库 wait_timeout，旧连接会在服务端关闭后继续被复用，导致批量失效。
MySQL 生产环境 wait_timeout 通常设为 300 秒（5 分钟），但 Go 连接池若未同步调整，就会出问题：
- 设为
0：等于放弃预防，全靠出错重试兜底，风险极高 - 设为
300 * time.Second：刚好踩线，无缓冲余量，网络抖动或服务端延迟关闭就容易触发失败 - 推荐值：
240 * time.Second（4 分钟），留出 60 秒缓冲
PostgreSQL 用户还需同步配置 TCP keepalive 参数：tcp_keepalives_idle、tcp_keepalives_interval、tcp_keepalives_count，否则客户端无法感知服务端断连。
死锁 panic 日志是第一手线索，不是辅助信息
看到 fatal error: all goroutines are asleep - deadlock! 就该立刻停手——这不是卡顿，是程序彻底停摆。panic 输出的 goroutine 堆栈直接告诉你谁在等什么。
重点关注：
-
maingoroutine 停在哪一行：比如卡在ch 、<code>mu.Lock()或wg.Wait() - 其他 goroutine 是否全卡在同一类操作上：如都在
chan send，说明 sender 没人接收；都在(*RWMutex).RLock，说明读锁重入 - 有没有 goroutine 卡在
select {}或空for {}？那是忘了退出条件，不是资源争用，但也会触发死锁
日志被截断时，加 GODEBUG=schedtrace=1000 运行，看 G 数量是否长期为 0；更准的定位方式是用 go tool trace 查状态变迁，而非只看 pprof 栈帧。
事务中 Conn() 未 Close 导致连接泄漏
手动调用 q.DB.Conn(ctx) 获取底层连接后，若未显式 conn.Close()，该连接不会归还给池子，造成 SLEEP 线程堆积、连接数持续上涨。
典型漏点：
- 事务中 panic 导致
tx.Commit()或tx.Rollback()未执行，连接被 tx 持有且无法归还 - HTTP handler 中
defer rows.Close()写在 if 分支里，部分路径跳过关闭 - 用
rows, err := db.Query()后忘记调rows.Close()，连接一直卡在 idle 状态直到超时
安全写法：
- 除非明确需要独占连接（如长事务、特殊隔离级别），否则直接用
db.BeginTx，别碰Conn() - 若必须用
Conn()，务必确保defer conn.Close()在所有分支执行，包括 error 返回路径 - 统一用
if rows, err := db.Query(); err != nil { } else { defer rows.Close() }结构，避免遗漏
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
