Go 的 http.Client 默认启用连接复用，但服务端返回 Connection: close、客户端设置 req.Close = true 或未读取完 resp.Body 均导致复用失效；需始终调用 resp.Body.Close()，合理配置 Transport 参数并验证复用效果。
Go 的 http.Client 默认已启用连接复用（keep-alive），但若直接使用 net.Conn 或自建 TCP 长连接池，不加控制极易导致文件描述符耗尽、TIME_WAIT 泛滥或连接空转超时失效。
为什么默认的 http.Client 复用有时不生效
常见于服务端返回 Connection: close、客户端主动设置 req.Close = true、或响应体未被完整读取（如 resp.Body.Close() 漏调、提前 return 导致 body 未 consume）。此时连接无法归还到复用池。
- 务必在所有分支中调用
resp.Body.Close()，哪怕只读 header - 避免手动设置
req.Header.Set("Connection", "close") - 检查服务端是否强制关闭：用
curl -v看响应头，或抓包确认FIN是否由服务端发起 - 如果必须短连接，显式配置
Transport.MaxIdleConnsPerHost = 0，避免空闲连接堆积
自建 net.Conn 连接池的关键参数控制
用 sync.Pool 管理 *net.TCPConn 时，不能只缓存连接本身，必须绑定生命周期管理逻辑——尤其是读写超时、心跳保活和错误状态清理。
-
SetReadDeadline和SetWriteDeadline必须每次读写前重设，否则过期后后续操作会直接失败 - 连接空闲超过服务端
keepalive timeout（通常 60–120s）会被静默断开，需配合应用层心跳（如发送"PING\r\n"）探测有效性 - 从
sync.Pool获取连接后，先做一次非阻塞conn.Write或conn.SetReadDeadline测试，失败则丢弃并新建 - 避免把
net.Conn放入sync.Pool后再调用conn.Close()—— 应在 Close 前清空池引用，否则可能复用已关闭连接
http.Transport 的关键调优项（非默认值）
默认配置适合通用场景，高并发短请求（如微服务间调用）需针对性收紧：
立即学习“go语言免费学习笔记（深入）”；
tr := &http.Transport{
MaxIdleConns: 200,
MaxIdleConnsPerHost: 200,
IdleConnTimeout: 90 * time.Second,
TLSHandshakeTimeout: 5 * time.Second,
// 若服务端支持 HTTP/2，可省略该配置；否则确保不设为 0
ExpectContinueTimeout: 1 * time.Second,
}-
MaxIdleConns控制全局空闲连接上限，MaxIdleConnsPerHost是单 host 限制，两者都需设（后者不继承前者） -
IdleConnTimeout应略小于服务端 keepalive timeout，避免客户端保留无效连接 - 若服务端是 Nginx，默认
keepalive_timeout是 75s，这里设成60s更安全 - 禁用
ResponseHeaderTimeout或设为合理值（如5s），防止慢响应拖垮整个连接池
如何验证连接是否真正复用
不要只看 netstat -an | grep :PORT | wc -l，它包含大量 TIME_WAIT。重点观察 ESTABLISHED 数量是否稳定、以及 /proc/PID/fd/ 下 socket 文件数增长趋势。
- 启用 Go 的 HTTP trace：
httptrace.ClientTrace，监听GotConn和PutIdleConn事件，确认连接被回收 - 在
Transport.IdleConnTimeout触发前后打日志，看是否频繁新建连接 - 用
ss -i查看具体连接的retrans、rto、qsize，判断是否存在拥塞或缓冲区问题 - 若用
net/http/httputil.DumpRequestOut抓包，注意Connection头是否为keep-alive，且无Close字样
连接复用不是“开了就稳”，核心在于连接生命周期与业务请求节奏的对齐——超时设太长，积压无效连接；设太短，复用率归零。真实压测时，ESTABLISHED 连接数应趋近于并发请求数，而非其数十倍。
