sql.db 是连接管理器而非连接池，它封装了空闲队列、连接数限制与超时控制，但不暴露底层连接生命周期；自建池仅适用于非sql协议或需精细控制的场景，且必须实现 acquire/release/close 接口并支持 context。
为什么 sql.DB 本身不是连接池，但能当池用？
很多人误以为 sql.DB 是个“连接池对象”，其实它是个连接管理器 + 池抽象层。它内部维护空闲连接队列、最大打开/空闲数、超时控制，但不暴露底层连接生命周期——你不能手动 Put 或 Get 单个连接。真正需要自定义池的场景，通常是：非 SQL 协议（如 Redis、gRPC client、HTTP transport）、需复用底层 socket 或 session、或要绕过标准库限制（比如带租约的连接）。
-
sql.DB的SetMaxOpenConns和SetMaxIdleConns控制的是它自己管的 pool 行为，不是你的模块该重做的部分 - 如果只是操作数据库，直接用
sql.DB并配置好参数即可，别另起池子 - 真正要自建池时，核心是：连接创建/销毁逻辑、空闲连接回收策略、并发安全、健康检查触发时机
用 sync.Pool 管理短命对象，但别用来池化 TCP 连接
sync.Pool 适合缓存临时分配的对象（如 []byte、结构体指针），它不保证对象存活时间，GC 会随时清理。绝对不要用它池化 net.Conn、redis.Client、http.Client 实例——这些对象有状态、有网络资源、需显式关闭。
-
sync.Pool.Get()可能返回 nil 或已失效连接，你得自己做IsClosed()或Ping()校验 -
sync.Pool.Put()不会调用Close()，资源泄漏风险极高 - 正确做法：用
container/list+sync.Mutex或sync.RWMutex手写带 TTL 的连接队列，或者直接基于net.Conn的SetDeadline做空闲超时驱逐
自定义池必须实现的三个接口方法
一个可用的连接池至少得暴露：Acquire()、Release(conn)、Close()。其中：
-
Acquire()应阻塞等待可用连接，或新建连接（受MaxOpen限制），失败时返回 error 而不是 panic -
Release(conn)必须校验连接是否还可用（例如调用conn.RemoteAddr()或发轻量 ping），不可用则丢弃并关闭，可用才放回空闲队列 -
Close()要遍历所有已打开连接并调用Close()，同时停止新连接创建，常用sync.Once防止重复关闭 - 别忘了在
Acquire()中加 context 支持，否则 timeout 和 cancel 无法传递
常见错误：把连接池和单例混为一谈
很多模块把池对象包在全局变量里（var pool = NewPool()），然后到处 import 使用。这看似方便，实则埋雷：
- 测试时无法隔离连接状态，多个 test case 共享同一池，容易出现 “connection refused” 或 “too many connections”
- 不同业务场景可能需要不同池参数（如读多写少 vs 写多读少），硬编码单例无法适配
- 一旦池出错（如全部连接被标记为 broken），全局不可恢复，只能重启进程
正确姿势：让使用者按需构造池实例，通过依赖注入传入（如传给 repository struct），并在 main 或 wire 初始化时统一配置。
连接池最难的不是代码量，是判断“什么时候该关掉一个连接”——超时、错误率、空闲时长、甚至远端服务主动断连信号，都得有响应路径。漏掉任意一种，积压的 stale conn 就会拖垮整个服务。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
