标准库 net/http 连接池不适用于纯 TCP 场景，因其复用逻辑绑定 HTTP 生命周期，无法管理自定义协议的原始字节读写；sync.Pool 也不适合直接缓存 net.Conn，因它不感知连接状态且 GC 无序回收。
为什么标准库的 net/http 连接池不适用于纯 TCP 场景
Go 标准库的 http.Transport 确实内置了连接池，但它只管理 HTTP 协议层的连接，底层虽用 net.Conn，但所有复用逻辑（如 idle 超时、最大空闲数、协议协商）都绑定在 http.Request/http.Response 生命周期上。一旦你直接读写原始字节（比如对接自定义二进制协议、Redis RESP、MQTT TCP 层），http.Transport 就完全失效——它不会帮你维护一个可用的 net.Conn 列表，更不会自动重连或剔除断连。
用 sync.Pool 管理 net.Conn 的常见误区
sync.Pool 适合缓存临时对象（如 []byte、结构体），但不适合直接放 net.Conn：它不感知连接状态，无法判断某个 Conn 是否已关闭、是否超时、是否被远端主动断开；且 Pool 的 GC 回收是无序的，可能把刚放进去的活跃连接回收掉。
- 错误做法：
pool.Put(conn)后不检查conn.Close()是否已调用，下次Get()可能拿到已关闭的连接 - 错误做法：把未设置
SetDeadline的连接放进去，复用时因阻塞读写直接卡死 goroutine - 正确思路：必须自己维护连接生命周期，
sync.Pool只做辅助（比如缓存连接结构体字段，而非连接本身）
手动实现可检测、可驱逐的 TCP 连接池核心逻辑
本质是维护一个带状态的连接队列 + 定期健康检查。关键不是“存”，而是“怎么判断能用”和“什么时候该扔”。
- 每个连接包装为结构体，含
net.Conn、最后使用时间lastUsedAt、是否标记为待关闭markedForClose - 获取连接时：遍历池中连接，跳过已关闭、超时（如 >5m 未用）、或
Write返回io.ErrClosedPipe的连接；找到后更新lastUsedAt - 归还连接前：必须执行一次轻量探测（如写一个 1 字节心跳或读
0字节非阻塞），失败则直接Close()并丢弃 - 后台启动 goroutine 定期扫描（如每 30s）：关闭所有
lastUsedAt超过MaxIdleTime的连接
示例关键判断：
立即学习“go语言免费学习笔记（深入）”；
if conn == nil || !conn.(*wrappedConn).isValid() {
conn = dial()
}其中 isValid() 内部调用 conn.SetReadDeadline(time.Now().Add(100 * time.Millisecond)); _, err := conn.Read(nil)，忽略 io.EOF 和 timeout，其余 err 视为失效。
连接池与业务协议耦合时必须处理的三个细节
很多自定义协议（如游戏服务器、设备上报）要求连接建立后先发认证包、维持会话 ID、或有粘性路由逻辑。这些不能交给通用池处理，必须下沉到池的使用者侧。
- 连接获取后首次使用前，必须由业务代码完成 handshake（例如发送
auth命令并等待 OK）；失败则需显式调用pool.Invalidate(conn)，而非简单Close() - 若协议依赖连接上的上下文（如用户 token 存在
conn的私有字段），不能复用连接——此时池应退化为连接工厂，或按上下文哈希分桶（map[string]*Pool） - 写操作失败（如
write: broken pipe）后，不要试图复用该连接，立即Close()并从池中移除；标准库的net.Conn.Write不保证原子性，部分写入成功 + 随后报错会导致协议解析错位
真正难的从来不是“怎么存连接”，而是“怎么信得过这个连接此刻还能收发数据”。状态检查永远要放在每次读写前，而不是只在 Get/Put 时做一次。
