sync.pool不可用于http.client、grpc.clientconn、sql.db等带状态连接对象，因其自身已内置复用机制；应仅用于无状态小对象如[]byte缓冲区、重置后的http.request或临时解析结构体。
Go微服务里哪些连接该复用，哪些不该塞进sync.Pool
直接结论：sync.Pool不是连接池，别把它用在*http.Client、*grpc.ClientConn、*sql.DB这类对象上。这些组件自身已内置连接复用逻辑，强行丢进sync.Pool只会引发泄漏、double-close、context超时失效等线上事故。
真正该用sync.Pool的，是无状态、可丢弃的小对象，比如：
-
[]byte缓冲区（如HTTP body读取后重置再复用） - 重置后的
*http.Request（需调用req.Close()和req.Body = nil后再Put） - 短生命周期的解析结构体（如JSON反序列化用的临时
map[string]interface{}）
一旦把带状态的连接对象塞进去，Put()后它可能被GC回收，但底层TCP连接还在跑，文件描述符就悄悄泄漏了。
http.Client怎么配才不踩坑
HTTP客户端必须全局单例复用，不能每次请求都&http.Client{}。重点调的是Transport字段，而不是Client本身。
常见错误配置：
- 没设
MaxIdleConns→ 默认0，所有空闲连接立即关闭，失去复用意义 - 没设
IdleConnTimeout→ 连接永远“假活”，DNS变更后仍连旧IP - 把
http.DefaultClient直接拿来用 → 它的Transport默认值极保守，吞吐扛不住高并发
推荐初始化写法：
client := &http.Client{
Transport: &http.Transport{
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
IdleConnTimeout: 30 * time.Second,
// 别漏这个：防止DNS缓存过久
ForceAttemptHTTP2: true,
},
}
注意：MaxIdleConnsPerHost必须显式设，否则按MaxIdleConns的1/100算（即默认1），根本不够用。
*sql.DB连接池参数的实际影响
sql.Open返回的*sql.DB本身就是连接池，但它的行为和你直觉可能相反：它不保证立刻建连，也不限制当前活跃连接数，只管“最大打开数”和“空闲数”。
三个关键方法的作用常被误解：
-
SetMaxOpenConns(n)：控制**同时打开的最大连接数**，包括正在用的+空闲的。设太小会阻塞db.Query；设太大可能压垮DB。 -
SetMaxIdleConns(n)：控制**空闲连接池大小**。设为0意味着每次用完立刻关掉，等于放弃复用。 -
SetConnMaxLifetime(d)：强制连接在d时间后被关闭并重建。必须设，否则长连接可能因网络中间件（如NAT超时）静默断开却无人感知。
典型配置组合：
db.SetMaxOpenConns(25) db.SetMaxIdleConns(5) db.SetConnMaxLifetime(1 * time.Hour)
注意：SetMaxIdleConns不能大于SetMaxOpenConns，否则会被截断——这点文档没明说，但源码里有校验。
gRPC连接复用的关键约束
gRPC的连接复用靠*grpc.ClientConn实例本身维持，不是靠外部pool。每个endpoint（含host+port+TLS配置）必须只创建一个ClientConn，反复复用。
容易出错的地方：
- 对同一地址反复
grpc.Dial→ 创建多个ClientConn，每个都维护独立连接池，资源翻倍浪费 - 在RPC方法里临时
NewClientConn→ 每次调用都新建连接，完全失去复用价值 - 没调
Close()就让进程退出 → 连接未优雅关闭，服务端可能残留半开连接
正确姿势：
- 启动时
conn, _ := grpc.Dial("xxx:port", opts...)一次 - 整个服务生命周期内复用这一个
conn - 进程退出前
conn.Close()，配合context.WithTimeout防卡死
额外提醒：ClientConn内部已实现连接健康检查、失败重试、负载均衡，不需要、也不应该在外层加sync.Pool或自定义连接池封装。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
