Go HTTP Client 为什么频繁建连接：Response.Body 没读完和没关闭的排查

接口 QPS 没涨多少，监控里却发现到同一依赖的建连次数一路上升：延迟偶尔抖一下，连接池里的空闲连接又总是留不住。查到最后，问题不一定在 MaxIdleConns，而可能只是某个状态码分支提前返回，Response.Body 既没读完也没关闭。Go 的 net/http 文档写得很直接：想让底层持久连接有机会复用，响应体需要读到 EOF 并关闭。

连接数异常，先别急着调 Transport 参数

这个现场很容易把人带偏。图表上看见新建连接增多，第一反应常常是把 MaxIdleConnsPerHost 调大；但如果应用自己没有把已经拿到的响应体收好，空闲连接配得再多也难以稳定复用。这里先别急着改参数，先找一条最常访问的下游路径，把状态码、返回长度和退出位置串起来。

重点看三个信号：同一域名的握手或建连指标是否明显增加；调用链里是否出现大量非 2xx 或业务拒绝的提前返回；这些返回前有没有读取和关闭 resp.Body。很多代码只在 JSON 解码成功后才写 defer，而真正经常发生的 401、429、502 分支却直接离开了函数。

先把 Close 放到拿到响应后的第一行

下面这种写法表面上很短，却把资源清理留给了偶然。状态码不符合预期时，函数在读取 body 前就返回；调用次数一多，连接复用自然变得不稳定。

func probe(ctx context.Context, client *http.Client, endpoint string) error {
	req, err := http.NewRequestWithContext(ctx, http.MethodGet, endpoint, nil)
	if err != nil {
		return err
	}

	resp, err := client.Do(req)
	if err != nil {
		return err
	}

	if resp.StatusCode != http.StatusNoContent {
		return fmt.Errorf("unexpected status: %s", resp.Status)
	}
	return nil
}

先把 defer resp.Body.Close() 放在 client.Do 成功之后，所有后续分支才有同一条清理路径。Go 官方文档还说明：Client.Do 成功时返回的 Body 非空；调用方应关闭它。这个规则不因响应有没有业务内容而失效。

func probe(ctx context.Context, client *http.Client, endpoint string) error {
	req, err := http.NewRequestWithContext(ctx, http.MethodGet, endpoint, nil)
	if err != nil {
		return err
	}

	resp, err := client.Do(req)
	if err != nil {
		return err
	}
	defer resp.Body.Close()

	if _, err := io.Copy(io.Discard, resp.Body); err != nil {
		return fmt.Errorf("read response body: %w", err)
	}
	if resp.StatusCode != http.StatusNoContent {
		return fmt.Errorf("unexpected status: %s", resp.Status)
	}
	return nil
}

这里的 io.Copy(io.Discard, resp.Body) 不是为了保留内容，而是让小而可预期的响应体走到 EOF。随后由 defer 关闭 body，处理路径就完整了。

读到 EOF 和限制响应大小，是两个不同的决定

“每次都把 body 全读掉”也不能脱离场景。内部健康检查、固定格式的小 JSON、受协议约束的状态响应，完整读取通常很合适；如果下游可能返回超大错误页、持续流或不可信内容，硬读到 EOF 反而会拉长等待并消耗内存。连接复用是性能目标，响应预算才是边界条件。

例如接口约定返回不超过 1 MiB 的 JSON，可以先限制读取量；一旦超过这个预算，就返回错误并关闭 body。此时不要承诺连接一定能回到空闲池，重点是服务没有被异常响应拖住。

const maxPayload = 1  maxPayload {
		return nil, fmt.Errorf("response body exceeds %d bytes", maxPayload)
	}
	return data, nil
}

这段代码刻意把“安全读取”和“连接复用”分开。响应没有超限时，读取会走到结尾；超过限制时，函数优先退出并让 Close 收口。不要为了追求一次连接复用，把未知大小的响应无限制读进进程。

验证时要把 Client 创建位置一起看

补上 body 处理后，下一步才轮到 Client 和 Transport。官方文档建议复用 Client 与 Transport：它们能安全地被多个 goroutine 共用，内部还保存了缓存的 TCP 连接。若每次业务调用都临时构造一个 http.Client 或 http.Transport，即使 body 处理正确，也会人为削弱连接池的作用。

我通常会先确认 Client 是否在应用启动时创建，再确认所有请求都走同一个实例，最后才观察 body 修复前后的建连曲线。只改一个变量更容易看出原因：先跑一段可控压测，记录新建连接与请求量的比例；合入修复后在相同条件下再跑一次。若比例没有变化，再去看服务端是否主动关闭、协议是否切换、代理是否拦截连接，而不是一口气改掉所有 Transport 设置。

一个分支漏掉 Close，为什么能拖慢整条链路

真实项目里漏点往往不在主路径，而在错误包装和重试判断附近。比如先读了几个字节做错误日志就返回，或者重定向、鉴权失败、限流时直接抛错。低流量下它们不明显；当某个依赖开始间歇报错，反复新建连接的成本就会和重试一起被放大。

排查时把响应处理抽成一个小函数，能减少这种分支分裂。函数内部明确谁负责读取、谁负责关闭、超过大小限制怎么办；调用方只处理业务结果。这里不是为了多抽象一层，而是让“每个返回路径都收口”变成一眼能检查的约束。

上线后用这些证据确认修复有效

• 同一依赖的每秒新建连接数与请求量之比是否下降。
• 非 2xx、重定向和业务拒绝分支是否也经过统一的 body 处理。
• 调用点是否复用同一个 http.Client，而不是在循环或请求处理函数里新建。
• 大响应、慢响应和取消请求是否仍能在设定的时延与大小边界内退出。
• 修复后延迟没有因为无边界读取而变差，错误响应也没有带来内存尖峰。

连接数降下来不代表所有网络问题都解决了，但至少能证明响应资源处理从“碰运气”变成了可检查的规则。剩下的异常，再沿着服务端关闭、代理策略和协议协商去看，范围会小得多。

常见问题

只写 defer resp.Body.Close() 就一定能复用连接吗？

不一定。Go 文档要求 body 同时读到 EOF 并关闭，底层 Transport 才可能复用持久连接。是否最终复用还会受服务端、代理和协议条件影响。

JSON Decoder 解析成功后还要继续读吗？

不要假设一次解码必然消费到响应末尾。若接口响应大小受控且希望争取复用，解析后应确认剩余 body 已被消费；若内容大小不可信，先遵守自己的读取预算。

发生 4xx 或 5xx 时也需要关闭 body 吗？

需要。只要 client.Do 成功返回了 response，就应立即安排关闭；错误状态恰恰最容易出现提前返回而漏掉清理。

每个请求新建一个 http.Client 有问题吗？

通常不合适。Go 文档建议复用 Client 和 Transport，它们能并发使用并维护内部连接状态。除非有明确隔离需求，否则应把 Client 放到可复用的生命周期里。

这类故障修复不靠一项神奇参数。先把 body 的读取和关闭放进每一条返回路径，再确认 Client 的复用位置，最后用相同负载对比连接指标，结论会更可靠。