Go HTTP 请求体没有关闭为什么会耗尽连接

Go 客户端连续请求 HTTP 服务时，如果拿到成功响应后没有关闭 response.Body，连接就不能按预期结束当前响应生命周期。请求量一上来，连接池里可用的连接越来越少，最终会表现为请求等待、吞吐下降，甚至看起来像“连接耗尽”。

官方文档：https://pkg.go.dev/net/http#Client.Do

正确的基本顺序是：Client.Do 成功返回后立刻接管 Body 的关闭责任；需要内容就读取，丢弃内容就按场景读取或限制读取，最后无论业务解析是否成功都执行 Close。如果希望连接被 Transport 复用，通常还要把响应体读到 EOF。

• 成功响应：err == nil 时，调用方负责处理并关闭 Response.Body。
• 连接复用：只调用 Close 能释放响应体，但没有读到 EOF 时，当前连接未必能被复用。
• 错误分支：请求失败时不要对一个不存在的响应体调用方法，先判断 err。
• 并发排查：同时检查响应体生命周期、Transport 配置和服务端响应速度，不要把所有等待都归因于 Close。

先确认响应体的关闭责任从哪里开始

http.Client.Do 成功后返回的 Response 会携带 Body。官方文档把它定义为响应体的读取入口，并要求调用方在读取结束后关闭它。这个责任应该在拿到成功响应的同一层建立，而不是等到业务解析函数深处再临时补救。

package main

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

func fetchStatus(client *http.Client, url string) error {
	resp, err := client.Get(url)
	if err != nil {
		// 请求失败时通常没有可供业务读取的成功响应，先返回错误。
		return fmt.Errorf("发起请求失败: %w", err)
	}
	defer resp.Body.Close()

	// 读取到 EOF，给 Transport 判断当前响应已经被完整消费的机会。
	if _, err := io.Copy(io.Discard, resp.Body); err != nil {
		// 读取失败仍会执行上面的 defer，避免响应体遗留在错误路径。
		return fmt.Errorf("读取响应体失败: %w", err)
	}
	if resp.StatusCode = 300 {
		return fmt.Errorf("服务返回状态码 %d", resp.StatusCode)
	}
	return nil
}

这里的关键不是把 defer 放在函数末尾，而是放在确认 err == nil 之后、任何可能提前返回的业务逻辑之前。这样状态码不符合预期、读取失败或后续解析失败时，关闭动作仍然会执行。

需要内容和只关心状态码时，处理策略不一样

“关闭响应体”不等于“必须把响应内容保存下来”。如果接口返回 JSON，就读取它；如果只关心状态码或响应头，也要负责结束响应体生命周期。两种场景可以使用不同的读取策略，但都不能漏掉 Close。

需要解析内容时

func readJSON(client *http.Client, url string) ([]byte, error) {
	resp, err := client.Get(url)
	if err != nil {
		return nil, fmt.Errorf("请求失败: %w", err)
	}
	defer resp.Body.Close()

	if resp.StatusCode != http.StatusOK {
		// 非成功响应也要读取或关闭 Body，不能只看状态码就遗忘它。
		_, _ = io.Copy(io.Discard, resp.Body)
		return nil, fmt.Errorf("HTTP 状态码为 %d", resp.StatusCode)
	}

	data, err := io.ReadAll(resp.Body)
	if err != nil {
		return nil, fmt.Errorf("读取 JSON 响应失败: %w", err)
	}
	return data, nil
}

示例把响应读入内存，适合体积明确且有上限的 JSON。生产代码如果响应大小不可信，应使用 io.LimitReader 或流式解码，避免为了连接复用把无限大的响应一次性读入内存。

只关心状态码时

func isHealthy(client *http.Client, url string) (bool, error) {
	resp, err := client.Get(url)
	if err != nil {
		return false, fmt.Errorf("健康检查请求失败: %w", err)
	}
	defer resp.Body.Close()

	// 丢弃小体积响应内容，尽量让连接回到可复用状态。
	if _, err := io.Copy(io.Discard, resp.Body); err != nil {
		return false, fmt.Errorf("丢弃响应体失败: %w", err)
	}
	return resp.StatusCode >= 200 && resp.StatusCode 

如果响应体可能很大，不能无条件把它全部丢弃到内存或长时间读取。可以先限制最大读取量，再关闭响应体；这种取舍会优先保护客户端内存，连接复用则交给 Transport 按实际响应状态处理。

为什么不关闭会让连接越来越少

默认 Transport 会维护连接以便后续请求复用。一个请求的响应体长期未关闭，相当于当前响应仍然占着连接资源；在高并发或服务端响应较慢时，多个未结束的 Body 会叠加，客户端就可能需要新建连接、等待连接或触发连接相关错误。

还要区分两种经常被混淆的情况：

因此，“调用了 Close”是必要条件，但不是所有连接复用问题的充分解释。对小响应，读完再关通常最直接；对大响应，则要在内存、读取时间和连接复用之间做明确取舍。

把关闭动作封装到并发请求的共同出口

在业务代码里，最容易泄漏 Body 的地方通常是多个错误分支：先检查状态码直接返回、解析失败直接返回、启动 goroutine 后把响应交给另一个函数。建议让“拿到响应后立即 defer Close”成为请求封装的固定结构，再把解析结果向外返回。

type HTTPGetter struct {
	Client *http.Client
}

func (g *HTTPGetter) GetText(url string) (string, error) {
	client := g.Client
	if client == nil {
		// 复用默认客户端；长期服务仍建议显式持有一个 Client。
		client = http.DefaultClient
	}

	resp, err := client.Get(url)
	if err != nil {
		return "", fmt.Errorf("请求失败: %w", err)
	}
	defer resp.Body.Close()

	// 先限制读取上限，避免异常响应拖垮调用方内存。
	const maxBody = 2 = 300 {
		return "", fmt.Errorf("HTTP 状态码为 %d，响应片段: %q", resp.StatusCode, data)
	}
	return string(data), nil
}

并发调用时可以共享一个长期存在的 http.Client，不要在每个请求中重新创建 Client 或 Transport。共享客户端让 Transport 有机会复用连接；每个响应体仍然由当前调用负责关闭。若要设置请求超时，优先在客户端或请求上下文中明确设置，而不是靠连接泄漏来“自然结束”。

常见误区与最终速查表

• 只在成功状态码分支关闭：错误状态响应也有 Body，状态码判断前就应建立关闭责任。
• 把 defer resp.Body.Close() 写在解析函数里：调用方先返回或把 Body 传丢后，解析函数可能永远接不到它。
• 每次调用都创建 http.Client：客户端和 Transport 的生命周期过短，连接复用效果会变差。
• 认为 Close 等于完整消费：Close 能结束资源生命周期，但想稳定复用连接，通常还要考虑是否读到了 EOF。
• 把所有等待都归因于 Body：服务端慢响应、超时、代理和连接池参数也可能是根因。

代码评审时，可以按这张表逐项确认：

相关问题

只调用 response.Body.Close，不读取内容可以吗？

可以结束响应体的资源生命周期，但没有读到 EOF 时，当前连接未必能按最理想方式复用。小响应通常可以读完再关闭；大响应则根据内存和延迟要求选择限制读取后关闭。

Response.Body 需要在 err != nil 时关闭吗？

先遵循 Client.Do 的错误处理约定：请求失败时不要假设有一个可正常使用的成功响应。只有拿到 err == nil 的响应后，才进入 Body 的读取和关闭流程。

为什么已经关闭 Body，连接数还是很高？

还要检查是否反复创建 Client 或 Transport、服务端是否保持长响应、是否存在大量并发、请求是否读到 EOF，以及客户端的超时和空闲连接配置。Close 只解决响应体生命周期，不会替代完整的连接管理。

把 Body 交给另一个 goroutine 处理安全吗？

可以，但必须明确所有权：交接方负责读取和关闭，原调用方不能同时 defer 关闭，也不能在交接后继续使用同一个 Body。更简单的做法是先在当前函数读取所需数据，再把字节或解析结果交给 goroutine。