Go 的 database/sql 自带连接池，无需第三方库；关键配置为 SetMaxOpenConns、SetMaxIdleConns（须≤前者，否则 panic）和 SetConnMaxLifetime（主动换新而非保活），且需调用 db.Ping() 触发初始化并验证连通性。
Go 的 database/sql 本身就有连接池，不用额外装库
很多人搜“Golang 连接池配置”，默认以为要引入第三方包或手动管理连接，其实 database/sql 在 Open 一个 *sql.DB 时就已内置连接池。它不是“有没有”的问题，而是“怎么调得合理”的问题。
关键参数只有三个，全在 *sql.DB 实例上设置：
-
SetMaxOpenConns(n)：最大打开连接数（含空闲 + 正在用的），设太小会排队等待，设太大可能压垮数据库 -
SetMaxIdleConns(n)：最大空闲连接数，建议 ≤MaxOpenConns，否则会被静默截断 -
SetConnMaxLifetime(d)：连接最长复用时间，防数据库侧连接超时或网络中间件（如 ProxySQL、RDS 代理）主动断连
示例：
db, _ := sql.Open("mysql", "user:pass@tcp(127.0.0.1:3306)/test")
db.SetMaxOpenConns(20)
db.SetMaxIdleConns(10)
db.SetConnMaxLifetime(60 * time.Second)为什么 SetMaxIdleConns 设太高没用，甚至触发 panic？
Go 1.12+ 对 SetMaxIdleConns 做了严格校验：如果设的值大于 MaxOpenConns，运行时会直接 panic —— 错误信息是 "max idle conns exceeds max open conns"。这不是警告，是 crash。
立即学习“go语言免费学习笔记（深入）”；
常见误配：
-
SetMaxOpenConns(5)却SetMaxIdleConns(10)→ 立即 panic - 只设
SetMaxIdleConns没设SetMaxOpenConns→ 默认MaxOpenConns = 0（无限制），但空闲连接池仍受底层驱动和系统资源制约，实际不可控
稳妥做法：先设 MaxOpenConns，再设 ≤ 它的 MaxIdleConns；生产环境建议 MaxIdleConns = MaxOpenConns × 0.5 左右，留出并发余量。
SetConnMaxLifetime 不是“保活”，而是“主动换新”
这个参数常被误解为“心跳保活”。实际上它只是告诉 Go：这个连接从创建起，最多活这么长时间，到期就关掉，下次需要时新建一个。它不发任何 SQL，也不检测连接是否还通。
典型场景：
- RDS 或数据库代理（如 ProxySQL、Cloud SQL）默认 30 分钟 kill 空闲连接 → 设
SetConnMaxLifetime(25 * time.Minute)避免取到已失效连接 - 某些云厂商对长连接做连接复用优化，但复用逻辑不稳定 → 缩短 lifetime 可降低偶发通信错误率
注意：设成 0 表示永不过期（不推荐）；设太短（如 1s）会导致频繁建连，增加 handshake 开销。
连接池没生效？先检查 sql.Open 后有没有调 db.Ping()
sql.Open 只是初始化配置，**不真正建连**。第一次执行 Query/Exec 才会拨号。如果服务启动后一直没触发 DB 操作，你会误以为“连接池没起来”。
验证方式很简单：
- 启动后立刻调一次
db.Ping()，失败会返回真实错误（比如密码错、地址不通） - 用
db.Stats()查当前连接状态：db.Stats().OpenConnections是当前打开数，Idle是空闲数
别跳过这步 —— 很多线上问题其实是 DNS 解析失败、防火墙拦截、或账号权限不足，但因为没 Ping，日志里根本看不到报错。
