Go语言中无需也不该自建通用连接池，因database/sql和http.Client等标准组件已内置成熟连接复用机制；硬套sync.Pool易致fd泄漏、double-close、context失效等问题。
Go 里不需要、也不该自己实现通用连接池——标准库和主流组件已内置成熟复用机制，硬套 sync.Pool 或手写池子反而引发泄漏、双关、context 失效等严重问题。
为什么 sync.Pool 不是连接池
sync.Pool 只管理无状态、可丢弃的小对象（如 []byte、*http.Request），它不跟踪对象生命周期，也不保证对象可用性。连接对象（*sql.DB、*grpc.ClientConn、*http.Client）本身已是线程安全的资源管理器，内部已有空闲复用、超时驱逐、错误恢复逻辑。
- Put 进
sync.Pool的连接可能被 GC 清理，但底层 TCP 连接仍在后台活跃 → fd 泄漏 - 多个 goroutine 从 pool 拿到同一
*grpc.ClientConn实例，各自调用Close()→ double-close panic - pool 中的连接无法响应
context.WithTimeout取消 → 请求卡住，连接永远不归还 -
http.Transport.IdleConnTimeout或sql.DB.SetConnMaxLifetime在 pool 外部失效 → 连接“假活”远超预期
HTTP 客户端该用什么复用方式
标准 http.Client 默认启用连接池，关键在配置和使用习惯，而非替换或封装。
- 全局复用单例
http.Client，别在 handler 或函数里反复 new - 显式配置
http.Transport：设MaxIdleConns（如 300）、MaxIdleConnsPerHost（如 300）、IdleConnTimeout（推荐 60s） - 必须调用
resp.Body.Close()—— 即使只读resp.StatusCode，漏掉这句连接就永不归还 - HTTP/2 自动复用，但仅限
https://；http://强制走 HTTP/1.1，且服务端返回Connection: close会中断复用
数据库连接怎么才算真正复用
database/sql 的 *sql.DB 就是连接池本身，不是“需要池化的对象”。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 应用启动时调用一次
sql.Open，全局复用返回的*sql.DB实例 - 必须设置三参数：
db.SetMaxOpenConns(100)、db.SetMaxIdleConns(50)、db.SetConnMaxLifetime(30 * time.Second) - 事务必须用
*sql.Tx对象执行，直接对*sql.DB调用Query会另取连接 → 事务连接卡死不释放 - 所有查询/执行必须用
Context版本方法（QueryRowContext、ExecContext），否则超时后连接一直被占
真需要通用池时，该选什么
如果确实要池化自定义资源（如 Kafka producer、libp2p stream、私有协议 socket），优先选语义明确、带生命周期控制的第三方库，而非裸写 sync.Pool。
-
Copool提供Conn接口抽象、最大空闲/存活时间、阻塞/非阻塞获取策略，适合协议无关场景 -
gofrs/pool支持预热、EvictionPolicy、borrow/return 回调，比手写更健壮 - 避免用
sync.Pool管理任何含 fd、mutex、context 或状态的对象 —— 它的设计目标从来就不是连接复用
最易被忽略的一点：连接池失效往往不是因为没池，而是因为某处忘了 Close()、某次用了非 Context 方法、或某次配置把 MaxIdleConns 设成了 0 —— 这些细节比选什么池更重要。
