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