setmaxopenconns必须小于数据库max_connections，推荐设为60%～80%并留余量；setmaxidleconns必须≤setmaxopenconns，否则go 1.12+会panic；需配合setconnmaxlifetime和setconnmaxidletime防止陈旧连接错误，db.ping()仅验证首次连接，不反映池内空闲连接健康状态。
SetMaxOpenConns 必须小于数据库 max_connections
设高了不是“性能更好”，是直接触发 ERROR 1040 (HY000): Too many connections。MySQL 默认 max_connections=151，PostgreSQL 常见为 100 或 200，你设 db.SetMaxOpenConns(200)，单实例就可能让 DB 拒绝所有新连接。
实操必须走三步：
- 上线前查真实值：
SHOW VARIABLES LIKE 'max_connections';（MySQL）或SELECT setting FROM pg_settings WHERE name = 'max_connections';（PostgreSQL） - 生产推荐值 = 数据库上限 × 0.6～0.8，留余量给备份、监控、DBA 临时操作
- 上线后盯
db.Stats().OpenConnections：长期 ≥ 90%SetMaxOpenConns→ 不够用；长期 ≤ 30% → 极大概率设高了，浪费资源
SetMaxIdleConns 和 SetMaxOpenConns 的大小关系不能错
这不是建议，是 Go 运行时强制校验的硬约束。Go 1.12+ 会 panic，错误信息是 "max idle conns exceeds max open conns" —— 不是 warning，是 crash。
常见踩坑点：
-
db.SetMaxOpenConns(5)后跟db.SetMaxIdleConns(10)→ 立即 panic - 只设
SetMaxIdleConns(20)没设SetMaxOpenConns→SetMaxOpenConns默认为 0（无限制），实际受 DB 和系统限制，但行为不可控 - 稳妥顺序：先调
SetMaxOpenConns(n)，再调SetMaxIdleConns(m)，且确保m ≤ n - 生产常用比例：
SetMaxIdleConns = SetMaxOpenConns × 0.5（如开 50，空闲留 25）
SetConnMaxLifetime 和 SetConnMaxIdleTime 必须配对使用
SetConnMaxLifetime 不是保活，是“到期作废”：连接从创建起活满就关，下次借就是新连接；SetConnMaxIdleTime（Go 1.15+）才是管空闲连接的——空闲太久就主动释放，防 NAT、SLB、RDS Proxy 静默断连。
不配后者，是线上 read: connection reset by peer 的高频原因。
-
SetConnMaxLifetime推荐值：30 秒～5 分钟。API 类服务用 30 秒，批处理可放宽到 3～5 分钟；必须略小于 DB 实际wait_timeout（如 MySQL 设为 300 秒，则 Go 侧设 240 秒） -
SetConnMaxIdleTime推荐值：5～10 分钟。太短（如 1 秒）会导致空闲连接频繁重建；太长（如 30 分钟）等于没起作用 - 典型组合：
db.SetMaxOpenConns(50)→db.SetMaxIdleConns(25)→db.SetConnMaxLifetime(3 * time.Minute)→db.SetConnMaxIdleTime(5 * time.Minute)
db.Ping() 只验首次建连，不等于连接池健康
db.Ping() 只拿一个连接执行 SELECT 1，成功不代表池里其他空闲连接都还活着。线上常见 ping 成功，但后续 query 随机失败 —— 本质是空闲连接已被 DB 或中间件断开，而 Ping() 并不检查它们。
真正要做的：
-
sql.Open后**立刻**调db.Ping()，验证 DSN、网络、DB 状态，避免第一个业务请求才暴露问题 - 别把
db.Ping()当 k8s readiness probe —— 滚动更新时可能误判服务不可用 - 可靠的健康检查应模拟业务路径，例如
db.QueryRow("SELECT 1").Scan(&i) - 若用云数据库（如 RDS），确认安全组、VPC 路由、DNS 解析都通，
i/o timeout多半不是连接池问题，而是网络层卡住
连接池参数不是设完就完事，最易被忽略的是：所有 db.Query() 返回的 *sql.Rows 必须显式 rows.Close()，事务中必须明确 tx.Commit() 或 tx.Rollback() —— 漏掉任何一个，连接就永远卡在 InUse 状态，WaitCount 会持续上涨。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
