Go Transport DisableKeepAlives 如何影响连接复用

排查 Go HTTP 客户端连接数时，最容易混淆的是 Transport.DisableKeepAlives。它控制的是 HTTP 层的 keep-alive：设为 true 后，一条连接只服务一个 HTTP 请求，后续请求需要重新建立连接；它不是 TCP keepalive 探活开关。默认值为 false，长期运行的客户端通常应该复用同一个 Transport。

一、DisableKeepAlives 关闭的是 HTTP 复用

这个字段的名字很像网络层参数，但 Go 文档明确把它放在 http.Transport 的连接管理语义里。开启后，Transport 不会让一条 TCP 连接承载下一次 HTTP 请求；服务端通常也会在响应后看到连接结束。它和 TCP keepalive 无关，所以修改它不能替代系统层的断链探测。

先把几个概念分开，排查会快很多：

二、开启和关闭时连接池会出现什么差异

假设连续向同一个 HTTPS 主机发起三次请求。默认配置下，第一次请求建立连接；如果响应体被正确处理且连接仍可用，后两次有机会复用它，减少 TCP/TLS 握手。DisableKeepAlives: true 时，每次请求都按单次连接处理，连接复用这条路径被切断。

这里有两个常见误判。第一，关闭 keep-alive 不等于“每次请求一定只有一个系统连接”，代理、HTTP 版本和失败重试仍可能改变实际网络行为。第二，看到连接数上涨也不能立刻归因于该字段；响应体未关闭、请求并发、目标主机变化和连接池上限都要一起看。

如果只是希望主动清理已经闲置的连接，可以保留复用能力，在合适的生命周期调用 Client.CloseIdleConnections()。这与把整个 Transport 设成不复用，是两个不同粒度的动作。

三、哪些情况可以考虑临时关闭

短命命令行程序、对端明确要求请求后断开，或正在定位某个代理/服务端对持久连接处理异常时，关闭可以作为隔离变量的手段。它让每次请求都走更完整的建连路径，便于判断问题是否只出现在连接复用之后。

但对高并发服务，长期关闭通常会放大握手、CPU、延迟和临时端口压力。更稳妥的做法是复制一个独立的 Transport 进行小范围灰度，不要修改全局共享客户端；确认问题后，再回到连接池参数、响应体处理和服务端超时配置上。

四、用代码验证，而不是凭感觉改开关

下面的示例只展示请求侧的判断边界：无论是否关闭复用，都要关闭响应体；观察连接复用时，可以接入 httptrace，不要把“请求成功”当成复用证据。

tr := &http.Transport{
    // true 用于隔离 HTTP keep-alive 问题；普通客户端保持 false。
    DisableKeepAlives: false,
}
client := &http.Client{Transport: tr}

req, err := http.NewRequest(http.MethodGet, "https://example.com/health", nil)
if err != nil {
    return err // 请求构造失败时没有响应体需要关闭。
}
resp, err := client.Do(req)
if err != nil {
    return err // 网络错误可能发生在拿到响应之前。
}
defer resp.Body.Close() // Body 生命周期仍由调用方负责。

if resp.StatusCode != http.StatusOK {
    return fmt.Errorf("health status: %s", resp.Status)
}
_, err = io.Copy(io.Discard, resp.Body) // 读完有助于 HTTP/1 连接再次复用。
return err

实际排查时可依次检查：是否复用了同一个 Transport；是否每个响应都关闭 Body；是否混用了不同主机或代理；是否把 IdleConnTimeout 误当成禁用复用；最后再比较 DisableKeepAlives 两种配置下的握手次数和延迟。

常见问题

DisableKeepAlives 设为 true 会关闭 TCP keepalive 吗？

不会。它是 HTTP Transport 的连接复用开关，TCP keepalive 属于更底层的探活机制。

关闭响应体后还能复用连接吗？

只调用 Close 是资源回收的必要动作；在 HTTP/1 场景，想提高复用机会通常还要按响应大小和业务需要读取到 EOF，不能把两者混为一个开关。

短脚本是否应该默认关闭 keep-alive？

不必。请求很少时收益有限，保持默认值更简单；只有对端兼容性或明确的生命周期要求支持时，才把关闭作为局部方案。