Golang网络请求慢怎么优化_连接复用与超时设置说明_技术教程

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。

必须分层设置超时：

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 缓存，不能依赖版本升级自动解决。