net.Conn不能直接放入sync.Pool，因其关闭后不可复用，且TLS/HTTP等有状态连接复用会导致“use of closed network connection”或读写错乱；应自建连接池管理生命周期并做健康检查。
为什么 net.Conn 不能直接丢进 sync.Pool
因为 sync.Pool 不保证对象生命周期，而 net.Conn 关闭后不可复用，且多数底层连接（如 TLS、keep-alive HTTP）有状态依赖。直接放进去会导致 use of closed network connection 或读写错乱。
实操建议：
- 连接池必须自己管理生命周期：获取时校验是否已关闭（
conn.RemoteAddr() != nil可粗略判断，但更可靠的是conn.SetReadDeadline+ 尝试conn.Read一个字节） - 不要复用
net.Conn实例本身，而是复用底层 socket fd（Go 运行时已做优化），靠net.Dialer的KeepAlive和连接复用逻辑来实现 - 真正该池化的，是「可重用的连接工厂 + 空闲连接队列」，不是裸
net.Conn
net.Dialer 的 KeepAlive 和 IdleTimeout 怎么配才不踩坑
这两个参数看似简单，但组合不当会直接导致连接池失效或资源泄漏。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 服务端主动断连后，客户端仍往已关闭连接写数据 → 报
write: broken pipe - 大量
TIME_WAIT堆积，连接数打不满 - 连接池里全是“假空闲”连接（没被检测出已断）
实操建议：
-
Dialer.KeepAlive = 30 * time.Second：让 TCP 层定期发 probe，及时发现对端异常断连 -
IdleTimeout = 90 * time.Second：必须 >KeepAlive，否则空闲连接在 probe 触发前就被回收了 -
KeepAlive仅对已建立连接生效；新建连接不触发 keepalive，所以首次使用前不做健康检查仍可能失败
怎么封装一个带健康检查的 tcp.ConnPool
通用组件的核心不是“能存连接”，而是“敢把连接交出去”。重点在获取连接时的预检和归还时的状态清理。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
- 用
container/list+sync.Mutex管理空闲连接队列（比sync.Pool更可控） - 获取连接时：
conn.SetReadDeadline(time.Now().Add(100 * time.Millisecond))，然后conn.Read([]byte{0})检查是否可读（非阻塞探活） - 归还连接前：
conn.SetReadDeadline(time.Time{})清除 deadline，避免下次误用 - 连接最大空闲时间、最大总连接数、获取超时都得作为结构体字段暴露，不能硬编码
简短示例（关键逻辑）：
func (p *ConnPool) Get() (net.Conn, error) {
p.mu.Lock()
if e := p.idleList.Front(); e != nil {
conn := e.Value.(net.Conn)
p.idleList.Remove(e)
p.mu.Unlock()
if err := p.healthCheck(conn); err != nil {
conn.Close()
return p.dial()
}
return conn, nil
}
p.mu.Unlock()
return p.dial()
}为什么不用 http.Transport 而要自己写 TCP 池
因为 http.Transport 是为 HTTP 协议设计的，它假设连接上跑的是标准 request/response 流，会自动处理 Connection: keep-alive、header 解析、response body drain 等。如果你跑的是自定义二进制协议、长连接推送、或需要精确控制读写边界，它反而会干扰甚至破坏语义。
典型场景：
- 对接 IoT 设备的私有 TCP 协议（无请求/响应模型）
- 实现 Redis 客户端，需要 pipeline 多条命令共用连接
- 做代理网关，需透传原始字节流，不能被
http.Transport缓冲或截断
这时候自己控池更安全：连接生命周期、读写缓冲、粘包处理、超时粒度，全由你决定。
容易被忽略的一点：TCP 连接池的“健康”不是指“能连上”，而是“当前上下文里还能按预期收发数据”。这个判断必须贴合你的协议特征——比如某些设备要求心跳间隔严格 ≤ 30s，那就得在归还前记录最后心跳时间，获取时比对。
