db.pingcontext仅验证连接池中至少一个连接可用，无法保证后续query所用连接仍有效；它不是保活机制，不刷新其他连接状态，成功不等于query成功。
db.PingContext 为什么不能保连接不失效
它只检查连接池里「至少一个」连接能通，不保证后续 Query 用的那条连接还活着。MySQL 服务端 wait_timeout 到期后会单方面关闭连接，而 Go 客户端可能还在复用这条“僵尸连接”——db.PingContext 成功后，下一次 db.Query 仍可能报 invalid connection 或 driver: bad connection。
更危险的是：db.Ping() 没有 context 控制，超时后还会卡住 goroutine；而 db.PingContext(ctx) 虽可设超时，但它不是健康检查手段，也不是保活机制，无法刷新池中其他连接状态。
- 永远用
db.PingContext(ctx)替代db.Ping()，尤其在重试循环中 - 别把 Ping 当连接保活：它不触发连接重建，也不清理失效连接
- Ping 成功 ≠ Query 成功，只是降低首次失败概率，不能替代错误重试逻辑
SetConnMaxLifetime 设置不当引发雪崩
MySQL 默认 wait_timeout = 28800（8 小时），但生产环境常调为 300 秒（5 分钟）。如果 Go 连接池没配 db.SetConnMaxLifetime，或设得比 wait_timeout 大，连接就会在服务端关闭后继续被复用，导致批量失效。
关键点是：这个值控制连接「出生后最多活多久」，和是否 idle 无关；设为 0 表示永不过期，等于放弃预防，全靠出错重试兜底，风险极高。
- 推荐设为
240 * time.Second（4 分钟），留出 60 秒缓冲 - 该设置对池中所有连接统一生效，与空闲/活跃状态无关
- PostgreSQL 用户需同步调
tcp_keepalives_idle等参数，否则客户端无法感知服务端断连
死锁 panic 日志里藏着唯一真相
看到 fatal error: all goroutines are asleep - deadlock! 就该停手——这不是卡顿，是程序已彻底停摆，所有 goroutine 都在等没人能给的信号。panic 日志里列出的 goroutine 堆栈，不是辅助信息，是唯一可依赖的线索。
重点盯三类行为：maingoroutine 卡在哪一行（比如 ch 或 <code>mu.Lock()）、其他 goroutine 是否全卡在同一 channel 操作（如都在 chan receive）、有没有 goroutine 卡在 select {} 或空 for 循环里。
- 日志被截断？加
GODEBUG=schedtrace=1000运行，观察 goroutines 数量是否长期为 0 - 无缓冲
chan int发送前必须有接收方就位，否则立即死锁；for v := range ch前必须有人close(ch)，否则无限等待 -
len(ch) == cap(ch)和len(ch) == 0只对有缓冲 channel 有效；无缓冲 channel 的长度永远是 0，不能用来判断可读/可写
高并发下 MaxOpenConns 放大连接失效影响
当 QPS 突增，db.SetMaxOpenConns(20) 打满后，所有连接高频使用，老化机制（ConnMaxLifetime）来不及清理旧连接。更糟的是：若此时数据库短暂不可达，恢复后大量连接集中失效，会触发雪崩式重连请求，进一步压垮 DB。
这和死锁看似无关，但实际常共现——连接失效引发重试，重试逻辑若没加超时或幂等控制，又可能卡在 channel 或锁上，最终一起触发 all goroutines are asleep。
-
MaxOpenConns必须按压测结果设，别照搬文档推荐值（比如 100） - 写操作（
INSERT/UPDATE/DELETE）不能无脑重试，必须结合业务 idempotency key 或事务状态校验 - 用
context.WithTimeout包裹整个重试流程，总时间建议不超过 2 秒，退避推荐 100ms → 200ms → 400ms
复杂点在于：连接池失效、channel 死锁、锁重入三者可能交织发生，panic 日志里混着 driver.ErrBadConn 和 chan send 堆栈，得先分清哪一层先塌——通常从 maingoroutine 停顿位置入手，它卡在哪，问题根子就在哪。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
