go语言中sql.db本身就是连接池管理器，无需第三方库；必须在sql.open后立即配置setmaxopenconns、setmaxidleconns、setconnmaxlifetime，并调用db.pingcontext()验证连通性，查询多行时务必rows.close()归还连接。
Go 语言的数据库连接不是“建一个连接”，而是初始化一个 sql.DB 实例——它本身就是连接池管理器，不是单条连接。 你不需要引入第三方连接池库，也不该手动 new 连接；错配参数或跳过验证，会导致服务启动不报错、首请求才挂掉。
sql.Open 只解析 DSN，不连数据库
sql.Open 返回的 *sql.DB 不代表已连上 DB，它只做驱动注册和 DSN 格式校验。即使 DSN 写错、MySQL 没启动、端口被防火墙拦住，sql.Open 也几乎不会返回 error。
- 真正建连发生在第一次调用
db.Ping()、db.Query()或db.Exec()时 - 生产环境必须在
sql.Open后立刻调用db.PingContext(ctx)（带超时和重试），不能依赖“后面自然会连上” - 容器化部署时，DB 常比 Go 服务慢几秒就绪，建议加最多 3 次重试，每次间隔 1s
SetMaxOpenConns / SetMaxIdleConns / SetConnMaxLifetime 必须早设
这三个方法控制连接池行为，**必须在首次查询前设置**（推荐紧接在 sql.Open 之后、db.Ping() 之前）。设晚了无效，设错会引发连接耗尽或 stale connection。
-
db.SetMaxOpenConns(50)：最大同时打开连接数（含使用中 + 空闲），设为 0 是无限，生产禁用 -
db.SetMaxIdleConns(20)：空闲连接上限，通常设为MaxOpen的 1/2～1/3；太小导致频繁建连，太大浪费 DB 资源 -
db.SetConnMaxLifetime(30 * time.Minute)：连接强制淘汰时间，避免因 MySQLwait_timeout（默认 8 小时）导致的僵死连接；建议 1～30 分钟 - Go 1.15+ 还应加
db.SetConnMaxIdleTime(10 * time.Minute)，更精准回收长期空闲连接
用完连接必须显式归还，不是靠 defer db.Close()
db.Close() 是关闭整个池，通常只在进程退出前调用一次。日常操作中，连接借出后需主动归还：
- 查单行：
db.QueryRow(...).Scan()自动归还，无需额外操作 - 查多行：必须调用
rows.Close()，否则连接永远不还，池很快耗尽 —— 这是最常漏的点 - 事务内：用
tx.QueryRow()/tx.Query()，事务Commit()或Rollback()后自动归还所有关联连接 - 别写
defer rows.Close()在循环里，容易 panic；应在for rows.Next()外层 defer
GORM 场景下仍要管底层 sql.DB
用 GORM 并不意味着脱离连接池配置。GORM 的 *gorm.DB 是 wrapper，真正管连接的是它底下的 *sql.DB。
- 拿到 GORM 实例后，必须调
gormDB.DB()获取原生*sql.DB - 再对其调
SetMaxOpenConns等方法，GORM 自己不帮你设这些 - 常见错误：只配了 GORM 的 logger 或 config，却忘了调
sqlDB.SetConnMaxLifetime，结果上线几天后大量 query timeout
最易忽略的是：连接池参数设错不会当场报错，sql.Open 成功也不代表 DB 可用，rows 忘关也不会立刻崩——所有这些问题都延迟暴露，往往压测或上线后才集中爆发。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
