忘记关闭 HTTP response body 会带来什么连接问题？

在 Go 里调用 http.Get 或 Client.Do 后，如果忘记关闭 resp.Body，最先受影响的通常不是这一请求的返回值，而是后续请求的连接复用：HTTP/1.x 下，Transport 可能无法把当前 TCP 连接放回 keep-alive 池，循环请求会不断新建连接，进一步带来连接数上升、握手开销增加和吞吐下降。

官方地址：https://pkg.go.dev/net/http

正确习惯是：拿到无错误的 response 后，立即为 resp.Body.Close() 注册清理；如果还要复用 HTTP/1.x 连接，则按业务需要把 body 读到 EOF，再关闭它。只关心状态码也不能跳过 body 的收尾。

先区分：未关闭和未读尽不是同一件事

Response.Body 是一个流式的 io.ReadCloser。Go 官方文档把两个动作放在一起描述：调用方负责关闭 body；如果 body 没有读到 EOF 并关闭，底层 Transport 可能无法复用持久 TCP 连接。也就是说，“忘记 Close”是明显的资源生命周期错误，而“只读了一部分”则会让当前响应仍然占据连接复用所需的边界。

把这件事放到请求链路里看，Client 持有带缓存连接的 Transport，Response 把响应头和 body 交给调用方；只有 body 的结束状态被正确处理，下一次请求才有机会继续使用已有连接。

基线现象：只看状态码也会影响下一次请求

下面这段代码只需要状态码，却把 body 丢在了函数外。单次调用看不出异常，但当它被放进轮询、批处理或健康检查循环时，连接复用就可能持续变差。

func statusCode(url string) (int, error) {
	resp, err := http.Get(url)
	if err != nil {
		// 请求没有拿到可用响应时，不要访问 resp.Body。
		return 0, err
	}
	// 这里没有 Close，响应体的生命周期没有结束。
	return resp.StatusCode, nil
}

在 HTTP/1.x 中，同一连接上的响应按顺序排列；客户端若不知道当前 body 已经结束，就不能可靠地从这条流中找到下一条响应的起点。可观察的对比指标包括连接建立次数、TLS 握手次数、请求延迟分位数和 Transport 的空闲连接数量，而不是只看某一次请求是否返回 200。

这不是“所有请求都会立刻泄漏一个文件描述符”的简单结论：协议版本、响应体大小、Transport 配置和服务端行为都会影响表现。但把 body 留给垃圾回收处理，不能替代明确的 Close。

按业务选择收尾方式

最常见的完整读取场景是把响应交给 io.ReadAll，然后用 defer 保证成功路径和后续返回路径都能关闭。

func readBody(url string) ([]byte, error) {
	resp, err := http.Get(url)
	if err != nil {
		// err 非 nil 时，响应通常不可用，直接返回即可。
		return nil, err
	}
	defer resp.Body.Close()

	data, err := io.ReadAll(resp.Body)
	if err != nil {
		// 读取失败也会经过 defer，避免留下未关闭的 body。
		return nil, fmt.Errorf("读取响应体失败: %w", err)
	}
	return data, nil
}

如果 body 很大，不要为了连接复用把内容一次性放进内存，而应在处理函数中持续读取；但无论是解码器、文件写入还是流式转发，最终都要负责关闭。

func discardBody(url string) (int, error) {
	resp, err := http.Get(url)
	if err != nil {
		// 没有响应时不做 body 清理，避免空指针访问。
		return 0, err
	}
	defer resp.Body.Close()

	// 只关心状态码时消费可读内容，给 HTTP/1.x 连接复用留下机会。
	if _, err := io.Copy(io.Discard, resp.Body); err != nil {
		return 0, fmt.Errorf("消费响应体失败: %w", err)
	}
	return resp.StatusCode, nil
}

错误分支、非 2xx 与协议边界

HTTP/2 使用多路复用，一个流上未读尽的 body 不会像 HTTP/1.x 那样直接阻塞同一连接上的其他流；但这不意味着可以省略 Close。body 仍然是调用方负责的资源，代码也可能在代理、降级到 HTTP/1.x 或换 Transport 后继续运行。

循环代码可以把“拿到 response 就注册 Close”作为固定检查点，再根据响应体大小决定是完整读取、流式处理还是丢弃内容。这样性能对比才有意义：先记录未修复版本的连接建立和延迟，再只改 body 生命周期，最后对比同样请求量下的指标。

相关问题

只写 defer resp.Body.Close()，还需要读取 body 吗？

如果业务需要响应内容，当然要读；如果只关心状态码，建议消费可读内容后再关闭。单独关闭能结束资源生命周期，但不能把“未读尽的响应”自动等同于已经读完。

非 200 响应是不是可以不关闭？

不可以。非 2xx 只是 HTTP 响应状态，不等于 Client.Do 返回错误；只要拿到了 response，就应按同样规则读取或关闭 body。

HTTP/2 下忘记关闭就没影响吗？

不能这样推断。HTTP/2 的复用模型不同，但 body 仍需要明确收尾；同时客户端可能协商到 HTTP/1.x，统一的关闭习惯更安全。

可以把这条规则留在代码审查清单里：成功拿到 response，先安排 Close；需要复用连接，再按场景读到 EOF；错误分支不解引用 response。