sql.db 本身就是连接池，无需第三方库；它自动复用、创建、回收连接，调用 query/exec 时借还连接而非新建；需正确配置 setmaxopenconns、setmaxidleconns 和 setconnmaxlifetime，并在首次查询前设置，且必须调用 rows.close() 等归还连接。
Go 语言原生 database/sql 包自带连接池，不需要额外引入第三方连接池库——直接用 sql.DB 就是连接池本身，关键在于正确配置和使用。
为什么 sql.DB 本身就是连接池
sql.DB 不是单个数据库连接，而是一个**连接池管理器 + 查询执行器**的组合。它在后台自动复用、创建、回收、关闭底层连接。你调用 db.Query、db.Exec 等方法时，实际是从池中借一个空闲连接，用完立即归还（不是关闭），不是每次新建 TCP 连接。
- 错误认知：“我得自己写个连接池”或“要用 github.com/jmoiron/sqlx 配连接池”——
sqlx.DB只是sql.DB的增强封装，池逻辑仍在底层sql.DB - 真正要配的是
sql.DB的池参数，不是“接入”某个池 - 只要不调用
db.Close()，池就一直活着；进程退出前应显式关闭
SetMaxOpenConns、SetMaxIdleConns 和 SetConnMaxLifetime 怎么设
这三个方法控制池行为，设错会导致连接耗尽、泄漏或僵死连接。它们必须在首次执行查询前设置（建议在 sql.Open 后立刻设）。
-
db.SetMaxOpenConns(n)：最大**同时打开**的连接数（含正在用 + 空闲）。设为 0 表示无限制（危险！生产环境务必设，如50） -
db.SetMaxIdleConns(n)：池中最多保留多少个**空闲连接**。若设太小（如 2），高并发时频繁建/关连接；设太大（如 100）又浪费 DB 资源。通常设为SetMaxOpenConns的 1/2～1/3（如开 50，空闲留 20） -
db.SetConnMaxLifetime(d)：连接最长存活时间（如30 * time.Minute）。强制到期后关闭旧连接、新建连接，避免因网络闪断、DB 重启导致的 stale connection。MySQL 默认 wait_timeout 是 8 小时，但建议设为 1～30 分钟更稳妥
示例：
db, err := sql.Open("mysql", dsn)
if err != nil {
log.Fatal(err)
}
db.SetMaxOpenConns(50)
db.SetMaxIdleConns(20)
db.SetConnMaxLifetime(30 * time.Minute)
常见错误：忘记校验 sql.Open 返回的 err，或误以为它会连 DB
sql.Open **只做参数解析和驱动注册，不建立真实连接**。它几乎不会返回 error（除非 DSN 格式错或驱动未导入）。真正连接 DB 是第一次调用 db.Ping() 或 db.Query() 时发生的。
- 后果：如果 DSN 写错、DB 没启动，程序启动时不报错，等到第一个请求才 panic 或超时
- 正确做法：初始化后立刻
if err := db.Ping(); err != nil { /* 处理 */ } - 注意：
db.Ping()会从池里拿一个连接发一个轻量探测包，成功即返回，失败则返回 error 并自动清理该连接
连接泄漏的典型场景和排查方式
连接没被归还给池，导致 db.Stats().OpenConnections 持续上涨，最终卡在 waiting for connection。
- 最常见原因：用了
rows, err := db.Query(...)但忘了defer rows.Close()——rows.Close()才真正把连接还回池 - 另一个坑：在
for rows.Next()循环里return或 panic 前没 close，用defer可规避 - 验证方式：定期打印
db.Stats()，关注OpenConnections和InUse字段变化 - 调试技巧：开启 MySQL 的
show processlist，看是否有大量 Sleep 状态连接长期不释放
连接池不是“设了就万事大吉”的黑盒，它的健康高度依赖你是否规范地使用 rows.Close()、tx.Commit()/tx.Rollback()，以及是否理解 sql.DB 的生命周期语义。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
