Go HTTP 响应体只剩换行时为什么会影响连接复用

如果 Go HTTP 客户端读完业务内容后，响应体里只剩一个换行符，关键不在“换行很小”，而在于这个换行仍然是 Body 中的未读字节。对 HTTP/1.x 来说，Transport 必须先确认当前响应已经读完，才能把底层连接安全地放回连接池；因此只读到 payload、还没有读到最后的 \n，再调用 Close，可能让下一次顺序请求无法复用原连接。

最稳妥的判断是：需要内容就一直读到 io.EOF，然后关闭；只需要状态码时，也要明确自己接受 Transport 的关闭回收策略。Go 1.27 已经会在关闭后对一小段未读的 HTTP/1 响应体做有限异步清理，但这不是把“未读响应体”变成可以长期忽略的理由。

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

先把“只剩换行”还原成字节问题

HTTP 响应体不是按“业务字段”自动切开的字符串，而是一个连续的字节流。假设服务端返回的内容是 payload\n，其中 payload 有 7 个字节，那么客户端读取 7 个字节后，读取游标停在换行之前：

p a y l o a d \n
0 1 2 3 4 5 6 7

此时业务上可能已经拿到了想要的文本，但传输层并不知道“换行无关紧要”。它只知道响应体还有一个字节没有读走。调用 Close 会释放调用方持有的 Body；至于底层连接能否继续承载下一次 HTTP/1.x 请求，要由 Transport 根据剩余数据和协议状态决定。

EOF、Close 和复用不是同一个动作

这三个概念容易被写成一句“读完并关闭”，但排查时应该分开看：

• Read 推进响应体游标；读到 io.EOF 表示当前响应体已经没有更多内容。
• Close 表示调用方不再使用这个 Body，Transport 可以开始回收资源。
• 连接复用表示底层 HTTP/1.x TCP 连接仍然满足继续解析下一次请求的条件。

如果还有一个换行没有读到，Close 并不等价于“调用方已经读到了 EOF”。在旧版本的实现或大响应体场景中，Transport 可能选择放弃这条连接，因为继续下载并丢弃剩余数据不一定比重新建连更划算。

用一段最小代码看出尾部差异

下面的示例故意只读 payload，让最后一个换行留在 Body 中。它用于说明读取边界，不代表所有 Go 版本都会稳定地表现为“下一次必然新建连接”。

package main

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

func readOnlyPayload(url string) error {
	resp, err := http.Get(url)
	if err != nil {
		return err
	}
	defer resp.Body.Close() // 中文注释：无论后续读取结果如何，都释放响应体

	buf := make([]byte, len("payload"))
	if _, err := io.ReadFull(resp.Body, buf); err != nil {
		return err // 中文注释：读取不足时不要把部分内容当成完整业务结果
	}
	fmt.Printf("body=%q\\n", buf) // 中文注释：此时末尾的换行仍可能留在 Body 中
	return nil
}

这段代码的问题不是 defer，而是它只保证读到了预期的业务前缀，没有保证响应体到达 EOF。如果这个 URL 返回的确实是 payload\n，那个换行就成为 Transport 需要处理的未读尾部。

需要正文时：直接读到 EOF

如果调用方最终需要完整正文，最清楚的写法是让读取函数负责读完，再关闭 Body。这样业务代码不需要猜测尾部是否还有换行、空格或分块解码后的剩余内容。

func fetchText(url string) ([]byte, error) {
	resp, err := http.Get(url)
	if err != nil {
		return nil, err
	}
	defer resp.Body.Close() // 中文注释：ReadAll 返回后再关闭，避免遗漏资源

	body, err := io.ReadAll(resp.Body) // 中文注释：持续读取，直到得到 EOF 或真实读取错误
	if err != nil {
		return nil, err // 中文注释：网络中断等错误不能被当成完整响应
	}
	return body, nil
}

对小型 JSON、文本或状态响应，这通常是最容易维护的方案。若正文可能很大，就不要为了复用连接而无条件把全部内容读进内存，应改用流式消费，或者按明确的上限做清理。

只关心状态码时：选择关闭策略

健康检查、HEAD 类请求或只关心状态码的调用，不一定需要保存正文。此时有三种常见选择：

无论选哪一种，都不要把“最后只剩换行”当成可以修改响应内容的信号。换行可能是协议正文的一部分，也可能是服务端格式化输出的一部分；连接复用只关心读取和回收是否安全。

旧版本或大响应：用有限 drain 控制成本

在需要兼容旧 Go 版本，或者不想把整个大响应读完时，可以先消费一个明确的上限，再关闭。上限不是保证复用，而是控制“为了争取复用最多愿意丢弃多少数据”。

func drainAndClose(body io.ReadCloser, limit int64) error {
	_, readErr := io.CopyN(io.Discard, body, limit) // 中文注释：最多丢弃 limit 字节，不无限下载
	closeErr := body.Close()                       // 中文注释：无论是否达到上限，都释放 Body
	if readErr != nil && readErr != io.EOF {
		return readErr // 中文注释：网络读取错误优先返回，便于定位连接异常
	}
	return closeErr // 中文注释：读取正常或到达 EOF 时，再返回关闭错误
}

例如，limit 可以按业务响应大小和网络成本设定。若只剩一个换行，有限 drain 很快就会到达 EOF；若还有数百 MB，函数会在达到上限后结束，Transport 可能放弃当前连接，这往往比无止境丢弃更合理。

HTTP/1.x 和 HTTP/2 不要混为一谈

“连接复用受影响”主要是 HTTP/1.x 的排查视角。HTTP/1.x 在同一条 TCP 连接上串行解析请求和响应，下一条响应从哪里开始，依赖上一条响应的边界已经被正确消费。因此未读尾部会让连接回收变得谨慎。

HTTP/2 在一条连接上使用独立的流和帧，流结束由协议帧明确标记；单个响应流的关闭不等同于关闭整个 TCP 连接。所以用 HTTP/1.x 的“是否回到连接池”现象去解释 HTTP/2，容易得到错误结论。实际是否走 HTTP/2，还取决于 TLS、Transport 配置和服务端协商结果。

Go 1.27 的官方说明还提到，Transport 关闭未读 HTTP/1 响应体后会尝试在有限时间和字节数内异步 drain，并会在明确带有 Connection: close 时跳过无意义的清理。这是实现层面的优化，不应替代业务层对 Body 生命周期的清晰管理。

用 httptrace 判断第二次请求是否复用了连接

不要只凭服务端日志里的请求数量判断复用。客户端可以使用 httptrace.ClientTrace 观察 GotConnInfo.Reused，把“是否复用”从猜测变成可见的诊断字段：

func doWithTrace(client *http.Client, url string) error {
	// 中文注释：实际文件还需要导入 fmt、io、net/http 和 net/http/httptrace
	trace := &httptrace.ClientTrace{
		GotConn: func(info httptrace.GotConnInfo) {
			fmt.Printf("reused=%v wasIdle=%v\\n", info.Reused, info.WasIdle) // 中文注释：记录本次连接是否来自复用
		},
	}

	req, err := http.NewRequest(http.MethodGet, url, nil)
	if err != nil {
		return err // 中文注释：URL 构造失败时不要发送半成品请求
	}
	req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace)) // 中文注释：把追踪信息绑定到本次请求
	resp, err := client.Do(req)
	if err != nil {
		return err
	}
	defer resp.Body.Close() // 中文注释：诊断结束也必须遵守 Body 生命周期
	_, err = io.Copy(io.Discard, resp.Body) // 中文注释：读到 EOF，减少未读尾部对结果的干扰
	return err
}

示例中还需要导入 net/http/httptrace。如果把“只读 payload”的版本和“读到 EOF”的版本分别用于连续请求，再比较 Reused，就能定位问题到底来自未读尾部，还是来自服务端主动关闭、代理、协议协商或 Transport 配置。

排查清单

1. 确认响应体的真实字节边界：最后一个 \n 是正文，还是读取函数提前停止留下的尾部。
2. 确认是否调用了 resp.Body.Close()，并检查是否在仍需读取正文前过早关闭。
3. 确认问题发生在 HTTP/1.x 还是 HTTP/2，不要用同一套连接现象解释两种协议。
4. 确认 Go 版本：Go 1.27 有有限异步 drain，旧版本的行为不能直接套用。
5. 用 httptrace.GotConnInfo.Reused 观察顺序请求，再排除 Connection: close、代理和服务端主动断开。

常见问题

只剩一个换行，为什么不直接忽略？

因为它仍是响应体字节。业务可以忽略它，但传输层必须先处理它，才能判断下一次 HTTP/1.x 响应从哪里开始。

调用 Close 后一定不能复用吗？

不一定。Go 1.27 的 Transport 会有限度地异步清理小段未读响应体；但是否复用还受协议、响应头、剩余长度和连接状态影响。需要确定性时，显式读到 EOF 更直观。

HTTP/2 还需要关心这个换行吗？

仍然要正确关闭 Body，但单个响应流的未读尾部不应简单等同于 HTTP/1.x 的整条 TCP 连接不可复用。先确认实际协议，再解释现象。

总结

Go HTTP 响应体只剩换行时，真正的边界是“是否还未读到 EOF”，而不是“剩余内容是否有业务价值”。需要正文就完整读取后关闭；只关心状态码时，根据 Go 版本和响应大小选择直接关闭或有限 drain；遇到顺序请求变慢，再用 httptrace 看连接是否复用，并把 HTTP/1.x、HTTP/2、服务端主动关闭等因素分开判断。