Go transport 怎么处理连接复用

Go 里如果每次请求都新建 http.Transport，连接复用基本就被自己切断了。更稳的做法是让同一个上游共享一个长期存活的 Transport 和 http.Client，请求完成后读完并关闭 Response.Body，再按主机数量调整空闲连接参数。

官方资料：https://pkg.go.dev/net/http

连接复用的关键不在“把 keep-alive 打开”这一句，而在三个边界：Transport 要活得足够久，响应体要正确结束，空闲连接策略要和上游数量匹配。需要确认效果时，用 httptrace 观察 GotConnInfo.Reused。

先分清 Client、Transport 和空闲连接

http.Client 负责更高层的请求行为，例如重定向和 Cookie；真正实现 RoundTripper、维护连接缓存的是 http.Transport。同一个 Transport 会按目标连接方法保存可再次使用的连接，默认的 DefaultMaxIdleConnsPerHost 是 2。这里的“复用”是连接级别的复用，不是把上一次响应直接拿来当缓存。

同一上游共享长期存活的 Transport

我在排查“请求量一上来连接数也跟着涨”的代码时，最先看的是 Transport 的创建位置。把它放在服务对象或依赖注入容器里，只初始化一次，通常比给每个请求创建新 Client 更符合连接池的设计。Client 和 Transport 都支持多个 goroutine 并发使用。

package upstream

import (
    "context"
    "fmt"
    "io"
    "net/http"
    "time"
)

// APIClient 将一个上游的 Client 与 Transport 作为长期依赖复用。
type APIClient struct {
    client *http.Client
}

// NewAPIClient 只在服务初始化阶段创建连接池配置。
func NewAPIClient() *APIClient {
    transport := &http.Transport{
        MaxIdleConns:        100,
        MaxIdleConnsPerHost: 8,
        IdleConnTimeout:     90 * time.Second,
    }
    return &APIClient{client: &http.Client{Transport: transport}}
}

// Get 让调用方的 Context 参与请求取消，并完整处理响应体。
func (a *APIClient) Get(ctx context.Context, target string) ([]byte, error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, target, nil)
    if err != nil {
        return nil, fmt.Errorf("创建请求失败: %w", err)
    }
    resp, err := a.client.Do(req)
    if err != nil {
        return nil, fmt.Errorf("请求失败: %w", err)
    }
    defer resp.Body.Close() // 无论后续读取是否成功，都及时释放响应体。
    if resp.StatusCode = 300 {
        return nil, fmt.Errorf("上游状态异常: %s", resp.Status)
    }
    body, err := io.ReadAll(resp.Body)
    if err != nil {
        return nil, fmt.Errorf("读取响应失败: %w", err)
    }
    return body, nil
}

示例中的数字只是说明配置位置，不是所有服务的通用答案。低频上游可以保留较小的空闲容量；同一主机有稳定并发时，再根据连接建立成本、响应体大小和服务端限制做容量调整。

响应体不收尾，连接就很难回到池里

只拿 StatusCode 就返回，是连接复用最常见的破坏方式。调用方至少要关闭 Body；对于希望让 HTTP/1.x 持久连接继续发挥作用的响应，通常还应把正文读到 EOF。网络错误、非 2xx 状态和正常返回都要覆盖到关闭逻辑。

按上游数量调节空闲连接，而不是盲目关闭 keep-alive

MaxIdleConnsPerHost 控制每个主机保留多少条空闲连接，MaxIdleConns 控制所有主机的总上限，IdleConnTimeout 控制空闲连接多久后自行关闭。DisableKeepAlives 会让每条连接只服务一次请求，通常会失去复用收益，不适合作为连接数问题的第一反应。

如果服务切换上游、证书配置或代理策略，旧连接不应继续留在池里，可以在变更点调用：

// CloseIdleConnections 只清理当前 Transport 中已经空闲的连接。
func rotateUpstream(tr *http.Transport) {
    tr.CloseIdleConnections()
}

它不是“关闭所有正在使用的请求”，也不是让下一次请求永远新建连接；它只处理已经处于 keep-alive 空闲状态的连接。HTTP/2 的连接管理还受其协议实现影响，不能只按 HTTP/1.x 的连接条数解释。

用 httptrace 判断复用是否真的发生

当日志只剩下“请求成功”，很难知道第二次调用是否复用了连接。httptrace.ClientTrace.GotConn 可以把 GotConnInfo.Reused 写入诊断日志，适合在压测前的小范围排查中使用。

trace := &httptrace.ClientTrace{
    GotConn: func(info httptrace.GotConnInfo) {
        // Reused 只表示这条连接曾被使用，不等于请求一定更快。
        log.Printf("conn reused=%v was_idle=%v", info.Reused, info.WasIdle)
    },
}
req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))

如果连续请求的 Reused 一直为 false，再回头检查 Transport 是否被重复创建、Body 是否提前中断、目标主机是否变化，以及是否主动关闭了 keep-alive。不要只凭一次 true 就推断连接池容量足够。

常见问题

每次创建 http.Client，为什么连接复用会变差？

如果每个 Client 都带着新的 Transport，就会产生彼此隔离的连接池。把 Client 和 Transport 提升到长期存活的服务依赖中，才能让后续请求看到同一组空闲连接。

只调用 resp.Body.Close，不读正文可以吗？

关闭是必须的，但是否能复用还取决于响应是否被完整消费、协议和底层连接状态。需要稳定复用的普通响应，优先读到 EOF 再关闭；大响应或主动截断时，应接受连接可能被丢弃。

MaxIdleConnsPerHost 调得越大越好吗？

不是。它只决定空闲连接保留上限，过大会增加客户端和服务端的资源占用。先按稳定并发、主机数量和连接建立成本估算，再结合 httptrace 与服务端指标调整。