Go Transport 为什么没有复用 HTTP 连接

Go 的 http.Transport 默认会缓存连接，所以同一个客户端连续访问同一个服务时，通常可以复用已有连接。遇到每次请求都像重新 TCP 拨号，先不要急着调大连接池：最常见的原因是每次请求都创建了新的 Transport，或者 Response.Body 没有读完并关闭。只有把这两个基础条件排除后，才值得继续看空闲超时、每主机上限、主动关闭和服务端协议。

为什么连接池看起来没有复用

排查时先把“没有复用”拆成两个问题：客户端是否拿到了同一个 Transport，以及 Transport 是否找到了可以使用的空闲连接。下面几种写法会直接破坏第一层条件。

func fetch(ctx context.Context, url string) (*http.Response, error) {
	// 每次调用都创建新的 Transport，连接池也会随调用一起变成新的。
	transport := &http.Transport{}
	client := &http.Client{Transport: transport}

	// 这个请求结束后，后续调用不会看到上一次 Transport 的空闲连接。
	req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
	if err != nil {
		return nil, err
	}
	return client.Do(req)
}

正确的边界是把 Transport 或 Client 放在长期存活的组件里，让多个请求共享它们。官方文档明确建议复用 Transport，并说明 Transport 可以被多个 goroutine 并发使用。若只是把同一个请求函数复制到多个协程里，却仍然在函数内部 new Transport，协程共享的只是代码，不是连接池。

出现 Transport 不复用 HTTP 连接的情况，大多是请求流程中某处违反了 Go 标准库连接复用的触发规则，顺着请求链路排查对应断点就能定位根因。

Response.Body 没有读完，连接可能回不去

第二个高频原因是响应体处理不完整。Client.Do 返回成功后，resp.Body 必须由调用方关闭；对于 HTTP/1.x，默认 Transport 不能保证在响应体没有读完并关闭时复用持久 TCP 连接。只写 defer resp.Body.Close()，但中途提前返回且没有消费剩余内容，仍可能让复用机会变少。

func getText(ctx context.Context, client *http.Client, url string) (string, error) {
	// NewRequestWithContext 让取消信号覆盖建连、响应头和响应体读取。
	req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
	if err != nil {
		return "", err
	}

	resp, err := client.Do(req)
	if err != nil {
		return "", err
	}
	// 无论后续读取成功还是失败，都必须关闭响应体。
	defer resp.Body.Close()

	// 需要复用 HTTP/1.x 连接时，先把响应体消费到 EOF。
	body, err := io.ReadAll(resp.Body)
	if err != nil {
		return "", err
	}
	if resp.StatusCode >= http.StatusBadRequest {
		return "", fmt.Errorf("remote status: %s", resp.Status)
	}
	return string(body), nil
}

如果业务不需要响应内容，也不能把 Body 当成无关字段丢掉，可以用 io.Copy(io.Discard, resp.Body) 消费它，再关闭 Body。大响应体则应结合业务上限处理，不要为了追求复用而无界地把数据读入内存。

用 httptrace 判断到底有没有复用

日志里看到“请求很慢”并不能证明连接没有复用。httptrace.ClientTrace 的 GotConn 回调会给出 GotConnInfo：Reused 表示连接是否被复用，WasIdle 表示它是否来自空闲池，IdleTime 则能帮助判断它在池里闲置了多久。连接地址还能辅助识别请求是否真的落在同一个主机和端口。

func requestWithTrace(ctx context.Context, client *http.Client, url string) error {
	trace := &httptrace.ClientTrace{
		GotConn: func(info httptrace.GotConnInfo) {
			// Reused 和 WasIdle 是判断连接池命中情况的核心信号。
			if info.Conn == nil {
				return
			}
			log.Printf("reused=%t was_idle=%t idle=%s local=%s remote=%s",
				info.Reused,
				info.WasIdle,
				info.IdleTime,
				info.Conn.LocalAddr(),
				info.Conn.RemoteAddr(),
			)
		},
	}
	// 把 trace 放进请求上下文，而不是修改全局 Transport。
	ctx = httptrace.WithClientTrace(ctx, trace)
	req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
	if err != nil {
		return err
	}

	resp, err := client.Do(req)
	if err != nil {
		return err
	}
	// 诊断请求也要完整处理 Body，避免排查代码本身改变连接行为。
	defer resp.Body.Close()
	_, err = io.Copy(io.Discard, resp.Body)
	return err
}

如果连续请求的 Reused 一直为 false，先沿下面的顺序排查，而不是直接把 MaxIdleConnsPerHost 改成很大的数字。

几个容易漏掉的连接池边界

同一个 Transport 不等于所有请求共享一条连接。连接池按目标主机等条件管理，访问不同域名、端口或代理路径时，通常会落到不同的连接集合。HTTP/2 还可以在一条连接上并发多路请求，此时“复用”表现为多路复用，不应简单按 HTTP/1.x 的连接数量理解。

空闲连接也会被回收。MaxIdleConnsPerHost 控制每个主机保留的空闲 keep-alive 连接数，设置为 0 时使用默认值 2；IdleConnTimeout 则控制空闲连接最多保留多久。高并发服务可以按请求波峰、上游限制和资源预算调整，但它们解决的是连接池容量，不会修复 Body 未关闭或每次 new Transport 的问题。

主动关闭优先级更高。检查请求是否设置了 Close，Transport 是否启用了 DisableKeepAlives，以及服务端或代理是否返回了关闭连接的信号。若使用自定义 Dial、DialTLS 或 TLSClientConfig，还要留意 HTTP/2 的默认尝试条件可能发生变化。

一份稳定的处理清单

生产代码里可以先保持一个共享 Client，再按实际并发设置 Transport 参数：

var sharedClient = &http.Client{
	Transport: &http.Transport{
		// 跨所有主机的空闲连接总上限。
		MaxIdleConns: 100,
		// 单个上游主机保留的空闲连接上限。
		MaxIdleConnsPerHost: 10,
		// 空闲连接超过这个时长后主动回收。
		IdleConnTimeout: 90 * time.Second,
	},
	Timeout: 15 * time.Second,
}

// 业务请求都复用 sharedClient，不在每次调用中重新创建 Transport。
func callUpstream(ctx context.Context, url string) (*http.Response, error) {
	req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
	if err != nil {
		return nil, err
	}
	return sharedClient.Do(req)
}

这段配置不是越大越好：先用 Reused、请求延迟、上游连接数和错误率观察，再决定是否调参。若一条请求链需要长期保持空闲连接，也应配合 CloseIdleConnections 的生命周期管理，避免在配置热更新或组件下线时留下不必要的连接。

相关问题

为什么我已经复用了 Client，Reused 仍然经常是 false？

先看 Response.Body 是否每次都读完并关闭，再检查请求是否访问了不同主机、端口或代理路径；最后才看空闲超时和连接池上限。

MaxIdleConnsPerHost 调大后就一定能复用吗？

不能。它只决定每个主机最多保留多少空闲连接，不能修复新建 Transport、主动关闭、服务端关闭或未处理响应体等问题。

HTTP/2 下还要关注 keep-alive 连接数吗？

仍要关注连接生命周期，但 HTTP/2 可以在单条连接上承载多个并发请求，连接数量和请求复用率的含义与 HTTP/1.x 不完全相同，应结合协议和 GotConnInfo 一起判断。