go 的 database/sql 自带线程安全连接池，应全局复用 *sql.db 实例并合理配置 setmaxopenconns、setmaxidleconns 和 setconnmaxlifetime，所有操作须用 context 方法控制超时。
Go 语言用 database/sql 就自带连接池，别自己造轮子
Go 标准库的 database/sql 包不是“数据库驱动”，而是带连接池的抽象层——只要用对了，sql.Open 返回的 *sql.DB 实例本身就是线程安全、带自动复用和超时管理的连接池。
常见错误是以为要手动维护连接列表、加锁、判断空闲连接数；结果反而绕过标准池，导致连接泄漏或并发崩溃。
-
sql.Open不真正建连，只是初始化配置；第一次Query/Exec才拨号，且会复用已有连接 - 连接池行为由
*sql.DB的几个方法控制：SetMaxOpenConns、SetMaxIdleConns、SetConnMaxLifetime - 别在函数里反复
sql.Open—— 它该是全局单例，生命周期和应用一致
SetMaxOpenConns 和 SetMaxIdleConns 怎么设才不拖慢服务
这两个参数直接决定池能否扛住突发流量，也影响数据库端压力。设太高，DB 可能被撑爆；设太低，请求排队，RT 暴涨。
典型误配：把 MaxOpenConns 设成 100，但 DB 只允许 30 个并发连接，结果大量 waiting for connection 错误；或者 MaxIdleConns 设为 0，每次请求都新建连接又立刻关，白白消耗握手开销。
-
MaxOpenConns建议 ≤ 数据库侧最大连接数 × 0.8（留 buffer 给后台任务） -
MaxIdleConns推荐设为MaxOpenConns的 1/2 到 2/3，避免空闲连接长期占着资源又没被复用 -
SetConnMaxLifetime必须设（比如 30m），否则长连接可能因中间网络设备超时断连，而池还不知道，下次复用就报i/o timeout或connection refused
用 context 控制查询超时，否则连接池会被卡死
连接池里的连接是“借出去”的——如果某次 QueryContext 或 ExecContext 卡死（比如 DB 慢查询、网络抖动），连接就一直被占用，直到超时或进程退出。不带 context 的调用（如 Query）等于无限等待，池很快耗尽。
现象：监控看到 db.Stats().WaitCount 持续上涨，日志出现大量 context deadline exceeded，但连接数没满，说明连接被“挂起”了。
- 所有数据库操作必须用
xxxContext方法，传入带 timeout 的context.Context - 别用
time.AfterFunc或 goroutine 包裹非 context 版本函数来“模拟超时”——这无法释放连接 - HTTP handler 中建议用
r.Context()向下传递，而不是创建新 context；否则 cancel 时机错乱，连接归还延迟
自定义连接池（比如 Redis、HTTP）真有必要吗
标准库没提供通用池抽象，所以有人抄 sync.Pool 或用第三方包（如 gofrs/pool）封装 TCP 连接。但绝大多数场景下，这是过早优化。
Redis 客户端如 redis-go 自带池；HTTP 客户端的 http.Transport 也有 MaxIdleConns 等字段；就连 gRPC conn 也内置复用逻辑。自己写池容易漏掉健康检查、驱逐策略、panic 恢复等细节。
- 只有当你明确需要复用某种昂贵的、无标准客户端的底层连接（比如私有协议 TCP 长连），且已压测验证瓶颈确实在连接建立上，才考虑手写
- 若真要写，优先复用
sync.Pool，但注意它不保证对象一定被复用，也不做超时清理；需配合init函数预热 + 单独 goroutine 定期清理 - 更稳妥的做法：用
net.Conn的SetDeadline+ 连接失败后主动Close，比强求“永远复用”更健壮
连接池最复杂的不是怎么建，是怎么让连接“干净地离开”——超时、中断、认证失败、协议错误，每种退出路径都要确保连接被正确标记为可复用或丢弃。这点标准库做了大半，自己补漏比从头造轮子重要得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
