不能直接用sync.Pool管理TCP连接，因其仅复用对象而不感知网络状态，无法做健康检查、超时回收、心跳探测或连接数限制，归还的失效连接会导致panic或静默失败。
Go 里没有现成的“长连接池”通用函数，必须自己封装结构体 + 管理逻辑；直接用 sync.Pool 是错的，它不负责连接健康检查和超时回收。
为什么不能直接用 sync.Pool 管理 TCP 连接
sync.Pool 只做对象复用，不感知网络状态。一个 net.Conn 归还时可能已被对端关闭、读写超时、或卡在半关闭状态——sync.Pool 会原样塞回去，下次 Get 出来直接 panic 或静默失败。
- 它不支持设置最大空闲数，容易撑爆文件描述符（Linux 默认 1024）
- 它不提供获取超时控制，调用方可能无限阻塞在
Get - 它无法触发心跳探测或写测试，归还前没法判断连接是否还活着
- 它不暴露活跃连接数、等待请求数等关键指标，出问题时无从监控
ConnPool.Get() 必须带 context 和健康检查
获取连接不能只从 channel 取，得先验证可用性。常见错误是取出来就用，结果第一次 Write 就报 write: broken pipe。
- 用
select+ctx.Done()控制等待上限，避免 goroutine 挂起 - 取出连接后立即调用
conn.SetReadDeadline(time.Now().Add(100 * time.Millisecond))，然后conn.Read(nil)测试是否可读（仅试探，不消费数据） - 若读失败且 err 不是
io.EOF或net.ErrClosed，说明连接已断，丢弃并新建 - 测试通过后重置 deadline（如需后续读写），再返回给业务使用
ConnPool.Put() 归还前要重置协议状态
比如 Redis 或 MySQL 协议连接，归还时若缓存了未读响应、处于 multi 事务中、或认证态未清理，下一次 Get 出来就会错乱。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 对 Redis 连接，Put 前执行
conn.Write([]byte("PING\r\n"))并读响应，确保连接干净 - 对自定义二进制协议，Put 前应清空缓冲区、重置解析器状态机
- 若连接已关闭或
Write失败（如write: connection reset by peer），直接 close，不归还 - 归还时检查当前空闲数是否超
maxIdle，超了就 close 掉，别堆着
连接池参数必须和对端 Keep-Alive 设置对齐
服务端设了 IdleTimeout: 60s，客户端却配 IdleConnTimeout: 90s，那最后 30 秒的空闲连接必然被服务端静默关掉，客户端还不知道，下次拿出来就死连。
- 客户端
IdleConnTimeout应 ≤ 服务端Keep-Alive timeout（通常减 5–10 秒留余量） - 服务端若没显式配置，需实测其默认 idle 超时（Nginx 默认 75s，Go
http.Server默认 3m） - 心跳间隔必须 IdleConnTimeout，否则连接会在心跳前就被池回收
- 所有超时（read/write/idle）都建议用
time.Duration显式赋值，别依赖 magic number
真正难的不是写个 Get/Put，而是让每个连接在归还时“洗干净”，在取出时“验过身”，并且整个池子的生命周期能被 metrics 观察到——这些细节漏掉一个，压测时就容易出现连接数暴涨、goroutine 泄漏、偶发 EOF 错误。
