因为sql.open仅初始化连接池而不建连，首次查询才真正拨号；高并发时若setmaxopenconns过小或连接泄漏，goroutine会阻塞在acquireconn上，表现为waitcount飙升、idle为0、无错误响应。
为什么 sql.Open 后不立即报错，但高并发时突然卡住或超时？
因为 sql.Open 只是初始化连接池对象，并不验证数据库连通性；真正建连发生在第一次 db.Query、db.Exec 等调用时。高并发下若连接池配置过小，大量 goroutine 会阻塞在获取连接上，表现为「无错误、无响应、CPU低、WaitCount 持续上涨」。
-
db.Stats().WaitCount每次增长，说明有 goroutine 在排队等连接 -
db.Stats().Idle == 0且OpenConnections ，大概率是连接被长期占用（比如事务未提交、rows 未 Close） - MySQL 默认最大连接数通常为 151，若
MaxOpenConns设为 200，服务启动就可能被拒绝，但错误出现在首次查询时而非sql.Open
SetMaxOpenConns 和 SetMaxIdleConns 怎么设才不翻车？
这两个值不是越大越好，也不该拍脑袋定。它们必须和你的实际负载、数据库容量、以及 Go 应用的并发模型匹配。
-
SetMaxOpenConns建议设为min(数据库 max_connections × 0.7, CPU 核心数 × 4)；例如 MySQL max_connections=200 → 推荐 140；8 核机器 → 推荐 32；取较小值更安全 -
SetMaxIdleConns不应超过SetMaxOpenConns，一般设为后者的 20%~50%；设太高会导致空闲连接长期占着 DB 资源却不干活 - 若应用有明显波峰（如定时任务拉取全量数据），需按峰值设
MaxOpenConns，否则波峰一来就排队
连接没释放？先查 rows.Close() 和 tx.Commit() 是否漏了
Go 的 database/sql 不会自动关闭 *sql.Rows 或提交事务——这是最常见的连接泄漏根源。一旦漏掉，连接就永远留在 InUse 状态，直到 ConnMaxLifetime 到期或进程重启。
- 所有
db.Query/db.QueryRow后必须显式调用rows.Close()，哪怕只读一行也要 defer -
db.Begin()后，无论成功失败，都必须调用tx.Commit()或tx.Rollback()；建议用defer func() { if r := recover(); r != nil { tx.Rollback() } }()+ 显式 error 判断兜底 - 用
db.Stats().InUse监控：稳定业务下它应该接近 0；持续 > 0 就说明有连接卡在未释放状态
要不要给连接加 ConnMaxLifetime 和 ConnMaxIdleTime？
要，而且必须设。不设等于默认永不过期，容易撞上数据库侧的连接超时（如 MySQL 的 wait_timeout=28800 秒），导致后续请求拿到已断开的连接，报错 invalid connection 或 i/o timeout。
-
SetConnMaxLifetime(1 * time.Hour)：强制连接在池中存活不超过 1 小时，避免被 DB 主动 kill -
SetConnMaxIdleTime(30 * time.Minute)：空闲超 30 分钟的连接直接回收，防止长尾空闲连接堆积 - 注意：这两个值必须小于数据库自身的超时设置，否则没意义；例如 MySQL
wait_timeout=600（10 分钟），你就不能设ConnMaxLifetime为 2 小时
连接池瓶颈往往不在参数本身，而在于「连接生命周期是否可控」——从打开、使用、到归还，每一步都得可追踪、可验证。线上跑着的应用，至少每天扫一次 db.Stats()，比任何压测都管用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
