Golang如何做HTTP连接池复用_Golang连接复用教程【速学】-Golang-PHP中文网

go的http.client默认复用连接，需全局复用实例并配置transport的maxidleconns、maxidleconnsperhost、idleconntimeout等关键参数，同时注意服务端响应头和http/2混用影响。

golang如何做http连接池复用_golang连接复用教程【速学】

HTTP client 默认就复用连接，不用手动配连接池

Go 的 http.Client 默认启用了连接复用（keep-alive），底层用 http.Transport 管理连接池，只要不显式关闭或配置错误，大多数场景下连接自然复用。

常见错误是每次请求都新建一个 http.Client 实例，比如在函数里写 client := &http.Client{}——这会导致每次新建 Transport，旧连接无法回收，既浪费资源又容易触发 too many open files 错误。

全局复用一个 http.Client 实例（比如定义为包变量）
不要在短生命周期函数里反复 new http.Client
如果需要定制，只改 http.DefaultClient.Transport 或新建自定义 http.Transport，别动 client 本身

自定义 Transport 时必须设 Timeout 和 MaxIdleConns

默认的 http.DefaultTransport 对连接数和超时控制比较宽松，高并发下容易打满连接或卡死。直接用它跑压测或微服务调用，常遇到 net/http: request canceled (Client.Timeout exceeded while awaiting headers) 或连接堆积。

关键参数不是越多越好，而是这几个必须显式设：

MaxIdleConns：整个 Transport 允许的最大空闲连接数（建议设为 100～1000，视 QPS 调整）
MaxIdleConnsPerHost：每个 host（如 api.example.com）最多保持多少空闲连接（建议至少 100）
IdleConnTimeout：空闲连接存活时间（推荐 30s，太长占资源，太短频繁重连）
TLSHandshakeTimeout 和 ResponseHeaderTimeout 必须设，否则 DNS 慢或后端卡住时 goroutine 无限挂起

示例片段：

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

tr := &http.Transport{
    MaxIdleConns:        1000,
    MaxIdleConnsPerHost: 1000,
    IdleConnTimeout:     30 * time.Second,
    TLSHandshakeTimeout: 10 * time.Second,
    ResponseHeaderTimeout: 10 * time.Second,
}

复用失效的典型信号：Connection: close 或 HTTP/1.0 响应

即使 client 和 transport 都配对了，连接仍可能不复用——最常见原因是服务端主动断连。抓包或打印响应头会看到 Connection: close，或者响应协议是 HTTP/1.0（它默认不 keep-alive）。

这时 Go client 会乖乖关掉连接，下次请求只能新建。这不是你代码的问题，但得知道怎么确认：

用 resp.Header.Get("Connection") 检查是否为 close
看 resp.Proto 是不是 "HTTP/1.0"
服务端 Nginx/Apache 若没开 keepalive_timeout，或加了 add_header Connection close，也会导致复用失败

HTTP/2 自动启用，但要避免混用 HTTP/1.1 和 HTTP/2 的 Transport

Go 1.6+ 默认支持 HTTP/2，且只要服务端支持、TLS 配置正确，http.Transport 会自动升级，无需额外开关。但它和 HTTP/1.1 共享同一套连接池参数（比如 MaxIdleConns），而 HTTP/2 连接是多路复用的，单个连接能并发处理多个请求。

坑在于：如果你为 HTTP/1.1 流量调大了 MaxIdleConns，却没意识到 HTTP/2 下其实不需要那么多连接，反而可能掩盖真实瓶颈；更麻烦的是，若 Transport 同时被 HTTP/1.1 和 HTTP/2 请求共用，而服务端只对部分路径支持 HTTP/2，连接复用行为会变得难以预测。

调试时用 curl -v https://host/ 看是否出现 ALPN, offering h2 和 Using HTTP2, server supports multi-use
不要给同一个 http.Transport 同时配置 ForceAttemptHTTP2: true 和自定义 DialContext（除非你清楚自己在做什么）
HTTP/2 下 MaxIdleConnsPerHost 的意义变弱，重点该盯 MaxConnsPerHost（Go 1.19+ 支持）