Go HTTP 响应体忘记关闭为什么连接池越来越小

先说结论：Go HTTP 客户端拿到成功响应后，resp.Body 由调用方负责关闭；如果响应体没有读完并关闭，Transport 可能无法复用 HTTP/1.x 的持久连接。循环请求中表现出来的“连接池越来越小”，通常不是池子突然消失，而是可复用的空闲连接减少，重复建连、等待和资源占用随之上升。

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

排查时把问题拆成三件事：是否进入了成功响应分支、是否在每个分支释放了 Body、是否复用了同一个 http.Client 和 Transport。

为什么不关闭 Body 会让连接复用变差

Client.Do 返回的 Response 在没有错误时会带有非空的 Body。这个字段不是只读的字符串，而是一个需要调用方结束生命周期的 io.ReadCloser。当程序提前返回、只读取部分内容或直接忽略它时，底层连接就不一定能回到 Transport 的可复用状态。

对于一个需要完整读取的小响应，最直接的写法是先确认错误，再安排关闭：

func fetch(client *http.Client, url string) ([]byte, error) {
    resp, err := client.Get(url)
    if err != nil {
        // 请求没有得到可用响应，不能访问 resp.Body。
        return nil, err
    }
    defer resp.Body.Close() // 无论后面读取成功还是失败，都释放响应体。

    body, err := io.ReadAll(resp.Body) // 小响应读到 EOF，便于连接复用。
    if err != nil {
        // 读取失败仍会执行上面的 Close，避免错误分支泄漏。
        return nil, err
    }
    return body, nil
}

这里的关键不是把 defer 写在某个固定位置，而是保证它位于“确认 err == nil 且 resp 可用”之后。不要在 client.Get 返回错误时无条件访问 resp.Body。

先检查错误分支，再决定读取多少内容

常见错误代码是在循环里只取状态码，却把响应体丢在一旁：

for _, url := range urls {
    resp, err := client.Get(url)
    if err != nil {
        // 错误分支没有可用响应体，记录错误后继续处理下一项。
        continue
    }
    // 错误示例：只看状态码，遗漏了 resp.Body.Close()。
    if resp.StatusCode != http.StatusOK {
        continue
    }
    // 这里也可能只取了部分正文，然后直接进入下一轮。
}

应当把关闭放进成功响应后的共同路径，状态码分支也不能绕过它。若正文很小，直接 io.ReadAll；若只是确认请求完成并且响应体可以丢弃，可以先把内容读完再关闭：

resp, err := client.Do(req)
if err != nil {
    // 包括请求错误或重定向策略错误，按错误处理，不重复关闭未知响应。
    return err
}
defer resp.Body.Close()

if resp.StatusCode = 300 {
    _, copyErr := io.Copy(io.Discard, resp.Body) // 丢弃正文但读到 EOF。
    if copyErr != nil {
        return copyErr
    }
    return fmt.Errorf("unexpected status: %s", resp.Status)
}

如果接口是大文件下载或流式响应，就不要为了“复用连接”强行把整个正文读入内存；应由消费方持续读取，并在结束、取消或失败时关闭。关闭是生命周期责任，是否读完则取决于业务是否需要正文和响应类型。

循环请求里同时检查 Client 和 Transport

即使每个 Body 都关闭了，如果每一轮都创建新的 http.Client 或 Transport，也会失去连接池的共享价值。官方文档建议客户端和传输层复用，它们可以安全地并发使用。

var sharedClient = &http.Client{
    Transport: &http.Transport{
        MaxIdleConns:        32, // 允许保留的空闲连接总数。
        MaxIdleConnsPerHost: 8,  // 单个主机的空闲连接上限。
    },
    Timeout: 10 * time.Second, // 防止单次请求长期占住调用方。
}

func checkURLs(urls []string) error {
    for _, url := range urls {
        resp, err := sharedClient.Get(url)
        if err != nil {
            // 网络错误没有可消费的成功响应，进入下一项或返回错误。
            return err
        }
        _, readErr := io.Copy(io.Discard, resp.Body) // 读完可丢弃的响应正文。
        closeErr := resp.Body.Close()                // 每一轮显式结束 Body 生命周期。
        if readErr != nil {
            return readErr
        }
        if closeErr != nil {
            return closeErr
        }
    }
    return nil
}

不要把 defer resp.Body.Close() 放在一个很大的循环里：它会等整个函数返回才批量执行，循环次数多时仍可能同时持有大量响应体。可以把单次请求封装到小函数里使用 defer，或者像上例一样在每轮读取后显式关闭。

用证据判断修复是否覆盖完整

可以按下面的顺序检查，而不必先修改 MaxIdleConns 等参数：

• 搜索所有 Do、Get、Post 调用，确认成功响应后一定能到达 Close。
• 检查非 2xx、解析失败、超时取消和提前返回分支，确认它们不会跳过响应体清理。
• 确认循环外只创建一次长期复用的 Client；不要把新的 Transport 放进每次请求的函数体。
• 观察修复前后是否仍频繁新建 TCP 连接、是否有大量未结束请求或文件描述符持续增长。指标只用于定位现象，不应替代代码责任检查。

需要注意，关闭响应体不等于保证所有协议都按同一种方式复用连接；HTTP/2 的复用模型与 HTTP/1.x 不同，代理、服务端响应和网络错误也会影响连接状态。但对 Go 客户端而言，“成功响应的 Body 由调用方负责关闭”仍是必须满足的基础约束。

常见问题

只调用 Close，不读取正文，可以吗？

可以结束资源生命周期，但是否能获得最佳的 HTTP/1.x 连接复用取决于响应是否读到 EOF、响应体大小和 Transport 的处理。小响应通常读完再关闭；流式或大响应则按业务消费并及时关闭。

请求返回 err 时还要关闭 resp.Body 吗？

通常按错误处理并忽略响应对象。只有文档明确给出的特殊返回场景才单独处理；不要在所有错误路径上假设 resp 一定可用。

调大连接池参数能解决泄漏吗？

不能。参数只能改变容量或空闲策略，不能替代每次响应的读取和关闭。先修复 Body 生命周期，再根据真实并发量调整 Transport 参数。

总结：先在成功响应分支接管 Response.Body，按需要读取并关闭；再确认循环复用同一个 Client/Transport。连接复用变差时，优先检查这两个责任边界，而不是盲目扩大连接池。