Go 关闭响应体前为什么有时还需要读到结束

调用 http.Client.Do 成功后，resp.Body 仍是一条按需读取的流。最稳妥的默认动作是关闭它；如果还希望 HTTP/1.x 的 keep-alive 连接尽量回到 Transport 的复用池，则在响应体可控时先读到 io.EOF 再关闭。这里的“读到结束”不是无条件的性能口诀：大响应、未知长度或不值得等待的响应，直接关闭反而更合适。

为什么 Response.Body 读到 EOF 会影响连接复用

Client.Do 返回的是响应头和一个流式 Body，不是已经落地的完整字节数组。官方文档明确要求调用方关闭非 nil 的 Body；如果 Body 没有读到 EOF 就关闭，底层 RoundTripper 可能无法复用后续请求的持久 TCP 连接。原因很直观：Transport 还需要知道当前响应的剩余字节在哪里结束，才能把同一条 HTTP/1.x 连接交给下一个请求。

但不要把它理解成“Close 之前永远必须手动读完”。当前文档同时说明，Transport 在 Body 被关闭后，会在保守上限内异步尝试读到结束。因此小响应常常只写 defer resp.Body.Close() 也能工作，只是这会把决定交给 Transport，不能当成稳定的复用承诺。HTTP/2 的复用模型也不同，不能把 HTTP/1.x 的经验机械套过去。

先读内容时如何安全地关闭响应体

如果业务要解析 JSON、读取文本或保存文件，就让读取动作明确发生在关闭之前。读取成功后再关闭；读取失败时同样要关闭，并保留错误，避免只看状态码而吞掉网络中断。

resp, err := client.Do(req)
if err != nil {
    return err // 请求阶段失败，没有可用的响应体
}
defer resp.Body.Close() // 无论读取成功或失败，都释放响应体

body, err := io.ReadAll(io.LimitReader(resp.Body, 2= 300 {
    return fmt.Errorf("服务返回 %s: %s", resp.Status, strings.TrimSpace(string(body))) // 先给出服务端信息
}
return handlePayload(body) // 读取完成后交给业务层解析

示例中的上限是业务示意，不代表所有接口都应使用同一个数值。对 JSON、错误页等可控小响应，io.ReadAll 简洁；对外部输入则应配合 io.LimitReader 或流式解码，避免为了复用连接而无限等待或占用内存。

不需要内容时怎么在复用与内存之间取舍

只判断状态码时，可以根据 ContentLength 和业务上限决定是否丢弃读取。长度明确且较小，读到 EOF 再关闭通常更利于 HTTP/1.x 连接复用；长度未知、体积可能很大，或者调用方已经超时，就不要为了复用强行把整条流读完。

if resp.ContentLength >= 0 && resp.ContentLength 

这个判断只适合长度可信且阈值合理的接口。分块传输或压缩响应可能让 ContentLength 不代表最终可读大小，所以未知长度不应自动走“读完”分支。

哪些检查项能避免响应体处理出错

排查“第二次请求变慢”或连接数异常时，先看每条成功响应是否都关闭 Body，再区分协议和响应大小。代码层面可以按下面顺序检查：

• 关闭时机：确认 Do 成功后立即安排 Close，不要在多个分支里遗漏。
• 读取错误：读取返回错误时停止解析，不要把半截 JSON 当成完整结果。
• 大小边界：对外部响应设置上限；大文件改用流式写入，不要整包 ReadAll。
• 复用预期：HTTP/1.x 的复用只是可能性，服务端主动断开、响应头或 Transport 配置都可能改变结果。

因此，正确的习惯不是“所有 Body 都先读完”，而是“所有 Body 都关闭；只有在响应可控且复用值得时才主动消费到 EOF”。

相关问题

只调用 resp.Body.Close() 会泄漏连接吗？

不一定。Close 仍是必需动作，Transport 还可能在保守上限内异步读取；但未读完的 Body 可能降低 HTTP/1.x 连接复用机会。

io.ReadAll 后还需要 Close 吗？

需要。读到 EOF 和释放 Body 是两个动作，通常用 defer resp.Body.Close() 统一收尾。

ContentLength 为 -1 能不能继续读完？

可以在业务明确允许且有大小/超时上限时流式消费；不能因为想复用连接就对未知长度无限等待。