sql.DB不是连接池而是连接池管理者+执行门面，其行为隐式且需通过SetMaxOpenConns等方法调优参数，正确释放资源（如rows.Close）可避免泄漏，95%场景无需自定义池。
为什么 sql.DB 不能直接当连接池用？
sql.DB 本身不是连接池，而是一个连接池的**管理者 + 执行门面**。它内部维护空闲连接、控制最大打开数、自动重试、超时回收等，但它的行为是“隐式”的——你调用 db.Query 或 db.Exec 时，它才从池里取连接；用完后不显式归还，而是由 defer rows.Close() 或语句执行结束触发释放。所以「自定义连接池」通常不是替换 sql.DB，而是定制它的行为。
怎么调整 sql.DB 的连接池参数？
真正可控的「池行为」都在 sql.DB 实例上，通过四个关键方法设置：
-
db.SetMaxOpenConns(n)：限制同时打开的最大连接数（含正在使用 + 空闲）。设为 0 表示无限制（不推荐）；设太小会导致请求排队阻塞 -
db.SetMaxIdleConns(n)：限制空闲连接上限。默认是 2，若并发高但单次查询快，建议设为接近MaxOpenConns -
db.SetConnMaxLifetime(d)：强制连接在创建后d时间内被关闭并重建。防数据库端因 idle timeout 主动断连导致首次请求报driver: bad connection -
db.SetConnMaxIdleTime(d)：空闲连接最长保留时间（Go 1.15+）。比MaxLifetime更细粒度，适合应对连接中间件（如 ProxySQL）的空闲驱逐策略
注意：SetMaxIdleConns(0) 不等于「禁用空闲池」，而是让所有空闲连接立刻被 Close，下次请求全走新建流程——性能代价极大，仅用于调试或极端场景。
如何避免连接泄漏导致池耗尽？
最常见的池耗尽原因不是配置小，而是连接没释放。典型陷阱：
立即学习“go语言免费学习笔记（深入）”；
- 忘记
rows.Close()：用db.Query后必须显式defer rows.Close()；db.QueryRow则不用（它内部自动处理） - 用
db.Query处理 INSERT/UPDATE：应改用db.Exec，否则返回*sql.Rows，容易漏关 - panic 发生在
rows.Scan()后、rows.Close()前：用defer可防，但更稳妥的是把rows.Close()放在if err != nil分支之后，或统一用rows, err := db.Query(...); if err != nil { ... }; defer rows.Close() - 长事务未提交/回滚：事务内的连接不会归还池，直到
tx.Commit()或tx.Rollback()
可以用 db.Stats() 在 debug 时检查 OpenConnections 和 InUse 是否持续增长。
需要真自定义池？先确认是不是过度设计
95% 的场景下，调优 sql.DB 参数 + 正确释放资源就足够。只有当你需要：
- 多套隔离池（比如读写分离中，读流量单独一个池，写流量另一个池）
- 连接建立前做认证协商（如 TLS SNI、动态 token 注入）
- 按租户 ID 路由到不同数据库实例，且每个实例需独立池控
这时才考虑封装：用 sync.Pool 管理 *sql.DB 实例（注意 sync.Pool 不适合长期持有资源），或用 map[string]*sql.DB 按 key 分池。但务必自己实现健康检查和过期淘汰——Go 标准库的 sql.DB 已经非常健壮，自己造池容易引入连接泄漏、goroutine 泄漏、竞态等问题。
最常被忽略的一点：连接池参数不是写死在代码里的，应该从环境变量或配置中心加载，并支持运行时热更新（例如监听 SIGHUP 重载 db.SetMaxOpenConns），否则上线后发现池不够只能重启服务。
