sql.Open() 仅初始化连接池不建连，首次 Query/Exec/Ping 才真实建连；必须紧随其后调用 db.Ping() 验证连通性，否则首请求才暴露超时或认证失败。
为什么 sql.Open() 后不立刻报错，但第一次查询却连不上？
因为 sql.Open() 只是初始化连接池管理器，不建真实连接；真正建连发生在第一次 Query()、Exec() 或 Ping() 时。没做 Ping() 就上线，服务看似启动成功，首请求才爆出 dial tcp: i/o timeout 或 access denied，排查成本陡增。
- 务必在
sql.Open()后立即调用db.Ping()，并处理返回的 error - 别依赖日志里 “DB initialized” 就认为连通——那只是池子搭好了，门还没敲开
- 云数据库（如 AWS RDS）常配了连接空闲超时（
wait_timeout=300），若没设SetConnMaxLifetime()，老连接归还后仍被复用，几小时后就触发Lost connection to MySQL server during query
SetMaxOpenConns 设成多少才算合理？
不是越高越好，也不是按 QPS × 耗时硬算。它本质是在「数据库扛得住」和「应用并发够用」之间找平衡点，超了会压垮 DB，低了会排队卡顿。
- 先查数据库上限：
SHOW VARIABLES LIKE 'max_connections';（MySQL）或SELECT setting FROM pg_settings WHERE name = 'max_connections';（PostgreSQL） -
SetMaxOpenConns建议设为该值的 60%～80%，留余量给备份、监控或其他服务 - 线上看
db.Stats().OpenConnections：长期接近上限 → 加；长期低于 30% → 减 - PostgreSQL 按每核 ≈20 连接估算；MySQL 生产环境通常控在 100～200，别盲目拉到 500+
空闲连接太多或太少，分别会出什么问题？
SetMaxIdleConns 和 SetConnMaxIdleTime 必须一起调，单调一个容易翻车。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 空闲连接太多（比如
SetMaxIdleConns=100但实际并发只有 10）：DB 端维持一堆“睡着的连接”，浪费资源，还可能被 NAT 网关/防火墙悄悄踢掉，下次复用直接read: connection reset by peer - 空闲连接太少（比如设成 2）：每次请求都得新建连接，TCP 握手 + 认证开销叠加，延迟毛刺明显，尤其在短时高峰（如定时任务批量执行）时更糟
- 实操建议：
SetMaxIdleConns设为SetMaxOpenConns的 1/2～1/3；再配SetConnMaxIdleTime(5 * time.Minute)，让空闲太久的连接主动释放
监控不到连接池状态，等于闭眼开车
光靠静态配置撑不过一周。生产环境必须定期采 db.Stats()，否则等用户投诉才发觉连接耗尽，已经晚了。
立即学习“go语言免费学习笔记（深入）”；
- 重点关注三个字段：
WaitCount（排队次数）、WaitDuration（总排队时长）、MaxIdleClosed（因空闲被关掉的连接数） -
WaitCount持续上涨 → 连接不够，优先调高SetMaxOpenConns -
MaxIdleClosed高 →SetMaxIdleConns设太高，或SetConnMaxIdleTime没生效（注意 Go 1.15+ 才支持该方法） - 把
db.Stats()接入 Prometheus，设告警：当OpenConnections / MaxOpenConns > 0.9且持续 1 分钟，立刻通知
最常被忽略的是：事务忘记 tx.Commit() 或 tx.Rollback()，连接会被死锁占用，db.Stats() 里 InUse 持续不降，但 WaitCount 不涨——这种泄漏最难定位，得靠代码审计加 pprof 抓 goroutine。
