Go Response.Body 只调用 Close 不读取完为什么连接不复用

Go 里看到 resp.Body.Close() 并不等于响应体已经读完。对 HTTP/1.x 来说，如果 Body 还没到 EOF，Transport 可能无法把这条 TCP 连接放回 keep-alive 复用池；但官方实现也会在 Close 时尝试异步读完一段内容，所以“每次都手写 io.ReadAll”并不是唯一答案。真正要分开判断的是：正文是否还需要、响应体有多大、关闭后是否值得复用。

先分清 Close、EOF 与连接复用的关系

http.Client 在收到响应头后就可以返回 Response，Body 仍然是按需流式读取的 io.ReadCloser。因此 Close 只表示调用方结束使用，不自动保证完整消费了网络上的响应内容。

官方文档的措辞是“可能无法复用”，不是“只要 Close 就一定新建连接”。当前 Transport 会在关闭 Body 时，在保守上限内异步尝试读到 EOF；响应很小的时候，单独 Close 也可能保住复用。但这不是应用层应依赖的精确阈值，服务端响应大小、传输协议和中断位置都会改变结果。

按响应大小选择读取策略

小响应的常见写法如下，注意读取错误不能被忽略；否则得到的半截数据可能被当成正常业务结果。

resp, err := client.Do(req)
if err != nil {
    return err
}
defer resp.Body.Close() // 无论后续状态如何，都释放响应体

body, err := io.ReadAll(resp.Body) // 读到 EOF，给 HTTP/1.x 复用留下机会
if err != nil {
    return fmt.Errorf("read response body: %w", err) // 区分网络读取失败
}
if resp.StatusCode = 300 {
    return fmt.Errorf("unexpected status %s: %s", resp.Status, body)
}
return nil

把 Body 生命周期放进可复用函数

在循环或多个错误分支里，推荐让一个小函数同时负责请求、读取和关闭。这样不会把 defer 留在长循环的外层，也不会在解析失败时漏掉 Close。

func readText(client *http.Client, req *http.Request) (string, error) {
    resp, err := client.Do(req)
    if err != nil {
        return "", err
    }
    defer resp.Body.Close() // 函数返回时统一关闭 Body

    data, err := io.ReadAll(resp.Body)
    if err != nil {
        return "", err
    }
    if resp.StatusCode != http.StatusOK {
        return "", fmt.Errorf("status=%s", resp.Status)
    }
    return string(data), nil
}

同时确认 client 和 Transport 是长期复用的对象。每次循环都创建新的 http.Client，即使 Body 处理正确，也会把连接池拆散；排查时还要留意服务端主动发送 Connection: close、代理行为和是否实际协商成 HTTP/2。

常见问题

只调用 Close 会不会泄漏连接？

不应把 Close 省略；它会结束 Body 的使用并触发 Transport 的回收尝试。但只 Close 不保证 HTTP/1.x 连接一定复用，是否复用由响应剩余内容和传输条件共同决定。

所有响应都应该先 io.ReadAll 吗？

不是。需要正文且体积可控时可以读完；不需要正文或响应可能很大时，及时 Close 通常比无意义地读完整体更合理。

CloseIdleConnections 能解决这个问题吗？

不能。它只关闭已经空闲的连接，不会把未读 Body 变成可复用连接。先修正 Body 生命周期，再根据应用退出或切换上游的需要关闭空闲连接。