sql.Open()仅初始化连接池不建真实连接，必须紧随其后调用db.Ping()验证连通性，否则首次Query/Exec才暴露超时或认证错误；连接池参数需依数据库上限合理配置。
sql.Open() 后不报错，但第一次 Query 就失败？
因为 sql.Open() 只初始化连接池管理器，根本不建真实连接。错误被延迟到首次 Query()、Exec() 或 Ping() 才暴露——比如 dial tcp: i/o timeout 或 access denied。
上线前漏掉 db.Ping()，等于把门虚掩着就宣布营业。服务日志显示 “DB initialized”，其实连数据库的墙都没摸到。
- 必须在
sql.Open()之后立刻调用db.Ping()，并检查返回的error - 云环境（如 AWS RDS）常设
wait_timeout = 300，若没配SetConnMaxLifetime()，几小时后复用老连接就会触发Lost connection to MySQL server during query - 别在初始化逻辑里只打日志完事，
db.Ping()是唯一能验证通路是否真实的动作
SetMaxOpenConns 设多少才不翻车？
它不是并发数的简单乘积，而是数据库承载力和应用吞吐之间的平衡点：设高了压垮 DB，设低了请求排队卡顿。
先查数据库上限：SHOW VARIABLES LIKE 'max_connections';（MySQL）或 SELECT setting FROM pg_settings WHERE name = 'max_connections';（PostgreSQL），再取 60%～80% 作为起点。
立即学习“go语言免费学习笔记（深入）”；
- MySQL 生产常见值是 100～200；盲目设成 500+ 容易触发
Too many connections - PostgreSQL 按每 CPU 核 ≈20 连接估算
- 线上观察
db.Stats().OpenConnections：长期 > 90% 上限 → 加；长期 -
SetMaxOpenConns默认为 0（无上限），绝不能留空
SetMaxIdleConns 和 SetConnMaxIdleTime 必须配对调
单设一个几乎必然出问题。空闲连接太多，DB 端维持一堆“睡着的连接”，可能被 NAT/防火墙静默踢掉，下次复用直接 read: connection reset by peer；太少则每次请求都重走 TCP 握手 + 认证，短时高峰毛刺明显。
-
SetMaxIdleConns建议设为SetMaxOpenConns的 1/2～1/3 -
SetConnMaxIdleTime推荐5 * time.Minute，让冷连接主动释放，避免被中间设备断连 - 这两个参数不配对设，等于给连接池装了个半截刹车——踩下去没反应，松开又刹不住
为什么全局复用 *sql.DB 是铁律？
在 handler 或循环里反复 sql.Open() + db.Close()，等于彻底绕过连接池。每请求新建连接，端口耗尽、TLS 握手堆积、goroutine 泄漏全来，还容易触发 too many open files。
- 只在
main()或初始化函数中调用一次sql.Open()，声明为包级变量 -
db.Close()只应在服务退出前调用一次，不是每次查询后 - 用
db.Stats()监控WaitCount：持续上涨说明连接池被绕过或配置不足 - 事务忘记
tx.Commit()或tx.Rollback()，连接会被长期占用，最终卡死整个池
连接池状态看不见，就等于闭眼开车。光靠启动时设几个参数撑不过一周，必须定期采 db.Stats()，尤其盯住 WaitCount、MaxIdleClosed 和 OpenConnections 这三个数字。
