必须紧接sql.open()后执行db.ping()以验证连通性，因sql.open()仅初始化连接池不建真实连接，未ping就上线会导致首请求才暴露超时或认证失败，排查成本陡增。
db.Ping() 必须紧接 sql.Open() 后执行
服务启动时 sql.Open() 成功不代表数据库连得上，它只初始化池管理器，不建真实连接。没调 db.Ping() 就上线，首请求才暴露 dial tcp: i/o timeout 或 access denied，排查成本陡增。
实操建议：
- 在配置加载后、服务注册前，立即执行
db.Ping()，并用if err != nil显式处理错误 - 别把
"DB initialized"日志当健康信号——那只是池子搭好了，门还没敲开 - K8s readiness probe 里别只跑
db.Ping()，它无法反映空闲连接是否已失效；应模拟业务路径，比如db.QueryRow("SELECT 1").Scan(&dummy)
SetMaxOpenConns 和 SetMaxIdleConns 要按环境差异化设
开发/测试环境常忽略连接数限制，直接用默认值（MaxOpenConns=0），上线后压垮 DB；生产环境又容易一刀切配高值，导致大量 idle 连接堆积。
实操建议：
- 开发环境：设
db.SetMaxOpenConns(5)+db.SetMaxIdleConns(2)，避免本地 MySQL 被占满 - 测试环境（压测）：根据目标 QPS × 平均耗时 × 1.5 计算，例如 QPS=200、耗时 30ms → 建议值 ≈ 9，再向上取整到 15～20
- 生产环境：查 DB 实例的
max_connections（MySQL 用SHOW VARIABLES LIKE 'max_connections'），设为该值的 60%～80%，如 RDS 实例上限 200，则SetMaxOpenConns(160)，再配SetMaxIdleConns(80)
云环境必须配 SetConnMaxLifetime 和 SetConnMaxIdleTime
AWS RDS、阿里云 PolarDB 等默认 wait_timeout=300（5 分钟），若不设 SetConnMaxLifetime()，归还池中的老连接几小时后复用，必报 Lost connection to MySQL server during query。
实操建议：
-
SetConnMaxLifetime()设为略小于 DB 的wait_timeout，例如 DB 是 300s，Go 侧设240 * time.Second -
SetConnMaxIdleTime()（Go 1.15+ 支持）必须配，且要 小于SetConnMaxLifetime()，云环境建议5 * time.Minute，适应主备切换 - 两个参数必须一起设：只设前者，空闲连接仍长期滞留；只设后者，刚建好还没热身的连接可能被误杀
事务里混用 db.Query 和 tx.Query 会悄悄泄漏连接
事务中调 db.Query() 不走事务上下文，而是从池里另取连接，既不参与事务，又额外占坑。一旦事务卡住，这个连接就一直被绑死，db.Stats().InUse 持续不降，但 WaitCount 不涨——监控看不出排队，却实际阻塞后续请求。
实操建议：
- 所有 SQL 操作统一走
tx对象：tx.Query()、tx.Exec()、tx.Prepare() - 开启事务必须带 context 超时：
db.BeginTx(ctx, &sql.TxOptions{})，其中ctx设 5s 超时 - 务必显式
defer tx.Rollback()（或Commit()），漏写会导致连接永久占用；rows.Close()同理，漏写会让连接卡在InUse状态
连接池不是“配完就完事”的静态组件，多环境差异的核心在于：开发要够小、测试要够准、生产要够稳。最容易被忽略的是事务内连接归属和空闲连接回收时机——这两处出问题，监控指标往往不报警，但延迟毛刺和偶发失败会持续出现。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
