Golang网络编程中连接复用的原理

http连接复用依赖http.Transport的连接池，需复用同一client、读完并关闭resp.Body、host与协议一致、服务端支持keep-alive；不关Body会导致连接无法归还，引发资源耗尽；关键参数包括MaxIdleConns、MaxIdleConnsPerHost和IdleConnTimeout。

HTTP 连接复用靠的是 http.Transport 的连接池

go 的 http.Client 默认就支持连接复用，根本原因不是 client 本身，而是它底层的 http.Transport —— 它内部维护了一个带超时管理的空闲连接池。只要满足几个硬性条件，下次请求就会从池里取一个已建立的 TCP 连接，跳过三次握手和 TLS 握手（如果是 https），大幅降低延迟。

• 必须使用同一个 *http.Client 实例（全局复用 client 变量）
• 响应体 resp.Body 必须被完整读取并调用 resp.Body.Close()
• 目标 host 和协议一致（比如都是 https://api.example.com）
• 服务端返回了 Connection: keep-alive，且未主动断连（Go HTTP server 默认开启 keep-alive）

不关 resp.Body 就等于“锁死”连接

这是最常踩的坑：明明用了全局 client，但压测时连接数暴涨、too many open files 报错、QPS 上不去。根本原因是没关 body，导致连接无法归还到池中，一直卡在“正在使用”状态，直到 IdleConnTimeout 超时才回收——而这个时间默认是 30 秒，远跟不上高并发节奏。

• 哪怕你只想要状态码，也得至少调用 io.copy(io.Discard, resp.Body) 或 ioutil.ReadAll(resp.Body) 再 Close()
• 用 defer resp.Body.Close() 是常见写法，但注意 defer 在函数 return 后才执行，若中间 panic 或提前 return，可能漏关
• 更稳妥的是：读完立刻关，别依赖 defer（尤其在长生命周期 goroutine 中）

http.Transport 关键参数怎么调才合理

默认配置适合低流量场景，生产环境必须调参。核心三个字段控制连接池行为：

transport := &http.Transport{     MaxIdleConns:        100,          // 全局最多保持 100 个空闲连接     MaxIdleConnsPerHost: 20,           // 每个 host 最多 20 个空闲连接（防止单域名占满池）     IdleConnTimeout:     90 * time.Second, // 空闲连接最长存活 90 秒 }

• MaxIdleConnsPerHost 比 MaxIdleConns 更关键——多数服务只调用少数几个下游，设太小（如 2）会导致频繁新建连接；设太大（如 100）又可能挤占其他 host 的资源
• IdleConnTimeout 不宜过长（>2 分钟），否则连接池积压大量“半死”连接；也不宜过短（
• 如果下游服务不稳定，可加 ResponseHeaderTimeout 防止卡在 header 阶段，但它不影响连接复用逻辑

TCP 层复用和 HTTP/2 多路复用不是一回事

别混淆概念：http.Transport 的连接复用是 HTTP/1.x 下的“串行复用”（一个连接同一时间只能处理一个 request-response），而 HTTP/2 的多路复用（multiplexing）允许在单个 TCP 连接上并发传输多个 stream。Go 的 net/http 在客户端和服务端都原生支持 HTTP/2，但前提是 TLS 握手协商成功（即服务端提供 ALPN 协议列表含 h2）。

立即学习“go语言免费学习笔记（深入）”；

• HTTP/1.x 复用靠 keep-alive + 连接池；HTTP/2 复用靠帧（frame）+ 流（stream）+ 二进制协议
• 即使启用了 HTTP/2，resp.Body.Close() 仍必须调用——它释放的是 stream 资源，不是 TCP 连接本身
• 用 httptrace.ClientTrace 的 GotConn 回调可验证是否真复用了连接（Info.Reused == true）

连接复用看着简单，实际成败全系于两个动作：用对 client 实例 + 关掉每一个 body。其余参数只是锦上添花；漏掉任一，池子就形同虚设。