HTTP客户端默认不复用连接，因http.DefaultClient的MaxIdleConns和MaxIdleConnsPerHost默认为0；需自定义Client并合理配置连接池、分层超时、启用HTTP/2及DNS缓存。
HTTP客户端默认不复用连接，必须显式配置
Go 的
虽然底层用了
，但它的
和
默认都是
，意味着不保活任何空闲连接，每次请求都新建 TCP 连接。这在高频调用时会显著拖慢性能，尤其当目标服务支持 HTTP/1.1 Keep-Alive 时。
实操建议：
自定义
，设置合理的连接池参数，例如：
建议不低于单 host
并发请求
数，否则会频繁触发连接关闭与重建
若调用多个不同域名的后端，
应 ≥ 所有 host 的
总和，否则全局连接数会被截断
超时设置不完整会导致 goroutine 泄漏或无限等待
只设
不够——它只控制整个请求生命周期（从 DNS 解析到响应 body 读完），但无法覆盖底层 TCP 连接建立、TLS 握手、响应头读取等中间环节。未覆盖的环节一旦卡住，就会阻塞 goroutine，长期积累引发内存增长甚至 OOM。
必须分层设置超时：
立即学习
“
go语言免费学习笔记（深入）
”；
：控制 TCP 连接建立时间，推荐
：控制 TLS 握手时间，推荐
：控制从发送请求到收到响应头的时间，推荐
（防后端卡在逻辑中不返回 header）
：如用
，设为
防等待过久
应大于以上所有值之和，例如设为
HTTP/2 自动启用但依赖 TLS 或明确指定协议
Go 1.6+ 的
默认支持 HTTP/2，但仅当满足以下任一条件时才会实际使用：
Git
程序猿必备版本控制工具
下载
请求 URL 是
（自动协商）
手动配置了
且服务端支持 ALPN h2
对
请求，需显式启用非加密 HTTP/2（不推荐，仅测试用）：
HTTP/2 的多路复用能显著降低高并发下的连接开销，但若服务端不支持或客户端未走 TLS，则仍回落到 HTTP/1.1，此时连接复用就更关键。
DNS 缓存缺失会放大网络延迟
Go 默认不缓存 DNS 查询结果，每次请求都可能触发新的
系统调用。若目标域名解析慢（如公网 DNS 延迟高、服务端无本地 DNS 缓存），会直接拖慢首
字节
时间（TTFB）。
解决方式有限但有效：
使用带缓存的 DNS 解析器，例如
+ 自建缓存逻辑（适合长期运行服务）
在
中封装缓存逻辑，例如用
缓存
，TTL 控制在
内
更简单的方式：在启动时预热 DNS，用
提前解析并丢弃结果
注意：Go 1.19+ 引入了
和缓存机制改进，但默认仍不开启 DNS 缓存，不能依赖版本升级自动解决。
http.DefaultClienthttp.TransportMaxIdleConnsMaxIdleConnsPerHost0http.Clientclient := &http.Client{
Transport: &http.Transport{
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
IdleConnTimeout: 30 * time.Second,
TLSHandshakeTimeout: 10 * time.Second,
},
}MaxIdleConnsPerHostMaxIdleConnsMaxIdleConnsPerHostclient.TimeoutTransport.DialContext5sTransport.TLSHandshakeTimeout5–10sTransport.ResponseHeaderTimeout5sTransport.ExpectContinueTimeout100-continue1sclient.Timeout30shttp.Transporthttps://Transport.TLSClientConfighttp://transport := &http.Transport{
ForceAttemptHTTP2: true,
// ... 其他配置
}getaddrinfogithub.com/miekg/dnsTransport.DialContextsync.Maphost:port → []net.IP30snet.DefaultResolver.LookupHost(context.Background(), "api.example.com")net.Resolver.StrictErrors