go的*sql.db本身就是连接池，需在sql.open后立即配置setmaxopenconns（≤数据库max_connections×0.8）、setmaxidleconns（为其1/2～2/3）和setconnmaxlifetime（30s～5分钟），并调用db.ping()验证连通性，全局复用且避免误调close。
Go 的 *sql.DB 本身就是连接池，不是“需要你手动封装或替代”的对象——微服务里只要配对、复用、不乱关，它就能扛住高并发。自己造池子、定时清理、重连逻辑，99% 是引入新 bug。
怎么初始化才不算埋雷
很多人在 sql.Open 后直接扔进 handler，结果首请求失败、错误堆栈没线索、运维查半天才发现是 DSN 端口写错。这不是连接池的问题，是初始化姿势错了。
-
sql.Open不建真实连接，只解析 DSN 并初始化结构体；真正拨号发生在第一次db.Query或db.Exec - 必须在服务启动时显式调用
db.Ping()，否则连通性问题会延迟暴露到业务路径中 - DSN 中密码含
@、/等特殊字符，得用url.QueryEscape编码，否则解析失败报invalid URL escape - PostgreSQL 要明确加
sslmode=disable或sslmode=require；MySQL 注意parseTime=true是否启用，否则时间字段扫描可能 panic
SetMaxOpenConns 和 SetMaxIdleConns 怎么设才不翻车
这两个参数不是越大越好，设错轻则吞吐上不去，重则数据库直接报 too many connections。它们控制的是不同维度的资源上限，且相互制约。
-
SetMaxOpenConns(n)控制“同时最多打开多少连接”（含正在执行 SQL 的 + 空闲的），设为 0 表示无上限 —— 生产环境绝对禁止 -
SetMaxIdleConns(n)只管“空闲连接池里最多留几个”，必须 ≤SetMaxOpenConns，否则 Go 1.12+ 会 panic 报max idle conns exceeds max open conns - MySQL 默认
max_connections常为 151，PostgreSQL 默认为 100；建议SetMaxOpenConns设为数据库该值的 70%～80% - 典型配比：
SetMaxOpenConns(100)→SetMaxIdleConns(50)；高并发短请求（如 API）可压到MaxOpen=30、MaxIdle=15；长事务服务（如批处理）需提高ConnMaxLifetime防 DB 主动断连
事务里混用 db 和 tx 为什么会让连接池饿死
事务绑定了专属连接，直到 Commit() 或 Rollback() 才释放。如果在 *sql.Tx 里穿插调用 db.Query，那个连接不会归还池子，其他 goroutine 就只能干等 —— 这是连接泄漏最隐蔽也最常踩的坑。
- 事务内所有 SQL 操作必须统一走
tx.Query/tx.Exec，禁止任何对db的直接调用 - 避免在事务中做 HTTP 请求、文件读写等耗时操作；建议用
context.WithTimeout(ctx, 5*time.Second)包裹db.BeginTx - 若发现
db.Stats().WaitCount持续上涨，大概率是事务没提交/回滚，或混用了db方法 - 用
defer tx.Rollback()开头、再tx.Commit()结尾，确保异常路径也能释放连接
为什么 db.Ping() 不能当健康检查 endpoint
db.Ping() 只检测能否拿到一个连接并执行一次 SELECT 1，它不验证空闲连接是否有效，也不反映池子整体水位。K8s readiness probe 里只放 Ping()，滚动更新时极易误判服务不可用。
- 真正可靠的健康检查应模拟业务路径，比如
db.QueryRow("SELECT 1").Scan(&i) - 连接失效更多发生在
Exec或Query过程中，Ping()发现不了 - 空闲连接老化靠
SetConnMaxIdleTime（Go 1.15+）主动剔除，而不是靠Ping()被动探测 - 云环境（如 RDS 故障切换、K8s Pod 重启）下，
SetConnMaxIdleTime和SetConnMaxLifetime都为 0 极易导致连接复用失败或泄漏
连接池参数不是写完就完事，db.Stats() 返回的 OpenConnections、WaitCount、MaxIdleClosed 才是真实水位线。不采这个，等于闭眼调参。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
