Go的http.Client默认复用连接，但需全局复用客户端实例并合理配置http.Transport的MaxIdleConns、MaxIdleConnsPerHost和IdleConnTimeout等参数，且须与服务端keepalive超时对齐。
Go的http.Client默认就复用连接，但需避免常见误用
Go 的 http.Client 默认启用 HTTP/1.1 连接复用（keep-alive），底层通过 http.Transport 管理连接池。但复用不会自动发生——如果每次请求都新建 http.Client 实例，或配置了不当的 Transport，连接照样无法复用。
- 全局复用推荐：声明一个包级变量（如
var httpClient = &http.Client{...}），在程序生命周期内重复使用 - 切勿在高频请求循环中
&http.Client{}—— 这会绕过连接池，每个请求新建 TCP 连接 - 默认
http.DefaultClient也复用连接，但不建议直接用它，因为无法定制超时和 Transport
http.Transport 是连接复用的核心配置点
连接复用行为由 http.Transport 控制，关键字段包括：
-
MaxIdleConns：整个 Transport 允许保持的最大空闲连接数（默认0，即无限制；生产环境建议设为100左右） -
MaxIdleConnsPerHost：每个 Host（如api.example.com）最多保留的空闲连接数（默认0，即MaxIdleConns；建议显式设为50或更高） -
IdleConnTimeout：空闲连接保活时间（默认30s；若后端服务 idle timeout 更短，需调低此值，否则连接可能被对方主动关闭） -
TLSHandshakeTimeout和ResponseHeaderTimeout建议显式设置，避免阻塞连接池
httpClient := &http.Client{
Timeout: 10 * time.Second,
Transport: &http.Transport{
MaxIdleConns: 200,
MaxIdleConnsPerHost: 100,
IdleConnTimeout: 60 * time.Second,
TLSHandshakeTimeout: 10 * time.Second,
},
}HTTP/2 自动启用连接复用，但需服务端支持且禁用某些 Transport 设置
Go 1.6+ 默认在满足条件时升级到 HTTP/2：客户端使用 HTTPS、服务端支持 ALPN、且未禁用 HTTP/2。此时连接复用更彻底（单连接多路复用），无需额外配置。
- HTTP/2 下
MaxIdleConnsPerHost仍生效，但意义弱化——同一 host 只需一个连接即可并发多请求 - 若手动设置了
Transport.TLSClientConfig.NextProtos，务必包含"h2"，否则可能降级到 HTTP/1.1 - 禁用 HTTP/2 的典型错误：设置
Transport.ForceAttemptHTTP2 = false（已废弃），或清空NextProtos - 验证是否用了 HTTP/2：检查响应的
resp.Proto是否为"HTTP/2.0"
连接没复用？先检查这些实际信号
不要只看代码逻辑，观察运行时表现更可靠：
- 抓包看 TCP 连接数：
netstat -an | grep :443 | grep ESTABLISHED | wc -l—— 高频请求下稳定在个位数才说明复用有效 - 日志里出现大量
"http: server closed idle connection"或"EOF"错误，大概率是IdleConnTimeout> 后端 keepalive timeout - 用
curl -v https://example.com看响应头是否有Connection: keep-alive（HTTP/1.1）或Alt-Svc: h2=（HTTP/2） - 注意 DNS 缓存：若请求 URL 经常换 IP（如负载均衡轮转），
PerHost连接池会被分散，看起来像没复用
连接复用不是“开了就一定生效”的开关，它依赖 Transport 配置、服务端策略、网络稳定性三者配合。最容易被忽略的是 IdleConnTimeout 与服务端配置的对齐——差 1 秒，就可能导致连接在复用前被双方各自关闭。
