sync.Pool 不能直接用作连接池，因其对象生命周期不可控、缺乏健康检查与超时控制；适合复用短命、无外部依赖的内存对象，如 bytes.Buffer；连接池应使用 database/sql.DB 或 http.Transport 等专用实现。
sync.Pool 不能直接当连接池用
很多人看到 sync.Pool 就想拿它管理数据库连接、HTTP 连接或 socket，这是典型误用。sync.Pool 的对象生命周期不可控：GC 时会清空、线程本地缓存可能长期不复用、Put 之后 Get 不一定拿到刚放进去的那个实例。连接类资源必须显式 Close、需要健康检查、超时控制和最大数量限制——这些 sync.Pool 一概不提供。
真正该复用的，是短命中间对象
sync.Pool 合适的场景很窄：高频分配+快速丢弃+无外部依赖的纯内存对象。比如 JSON 解析时的 bytes.Buffer、HTTP 中间层的 http.Header map、Protobuf 反序列化用的临时 struct 实例。
- 每次 HTTP handler 中 new 一个
bytes.Buffer，用完就丢 → 改成从sync.Pool获取，用完Reset()后Put() - 避免在 Pool 里放含指针字段且指向长生命周期对象的结构体，否则 GC 无法回收那些被意外“钉住”的内存
- Pool 的
New函数只在 Get 无可用对象时调用，别在里面做初始化连接、打开文件等副作用操作
连接池必须用专用库或标准库原生实现
Go 标准库的 database/sql.DB 和 http.Transport 内部都实现了带超时、最大空闲数、健康探测的连接池，直接配置 SetMaxIdleConns、SetConnMaxLifetime 就行。自己造轮子容易漏掉关键逻辑：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
net/http的http.DefaultTransport默认只保持 2 个空闲连接 → 高并发下大量新建/关闭 TCP，加&http.Transport{MaxIdleConns: 100, MaxIdleConnsPerHost: 100}才有效 - 手写连接池若没做连接失效重试，遇到网络抖动就会把坏连接塞回池子，后续请求直接 panic
-
database/sql的连接池默认不限制最大打开数（SetMaxOpenConns(0)），MySQL 服务端可能因 too many connections 拒绝新连接
sync.Pool 的 Put/Get 时机稍有偏差，GC 压力就白减
不是“用了 Pool 就一定省 GC”，关键在对象生命周期是否真的匹配。常见翻车点：
立即学习“go语言免费学习笔记（深入）”；
- 在 goroutine 中 Get 对象，但 goroutine 执行完才 Put → 对象卡在线程本地池里，直到该 P 下次调度或 GC 触发清理
- Put 前忘了清空对象内可变字段（比如 slice 的
cap没 reset），下次 Get 到的可能是残留脏数据 - 对小对象（如几个字节的 struct）用 Pool，反而增加指针追踪开销，实测可能更慢
压测时看 runtime.ReadMemStats 的 PauseNs 和 NumGC 才算数，别光看代码写了 Pool 就以为优化到位。
