Go net/http Client确保响应体关闭并复用连接的处理方案

Go 服务里用 http.Client 调第三方接口时，连接数不断上升、延迟偶尔抖动，常见原因不是“连接池太小”，而是响应体生命周期没有收好。可复用的处理方案只有一个核心：复用同一个 Client，拿到成功响应后立刻安排关闭，真正需要连接复用时把 Body 读到 EOF，再分别判断读取错误和 HTTP 状态码。

复用 Client 与 Transport，先划清响应责任

http.Client 的底层 Transport 会维护缓存连接，因此适合在服务启动时创建一次并被多个 goroutine 共享。默认的 http.Client 可以直接使用；需要限制空闲连接、设置超时或配置代理时，再显式创建自己的 Transport。不要把下面的初始化代码放进请求函数。

var apiClient = &http.Client{
    Timeout: 8 * time.Second, // 给一次请求设置总超时，避免调用长期悬挂
    Transport: &http.Transport{
        MaxIdleConns:        32,              // 控制全局空闲连接上限
        MaxIdleConnsPerHost: 8,               // 为单个上游保留可复用连接
        IdleConnTimeout:     90 * time.Second, // 空闲过久的连接自动回收
    },
}

这里的连接复用不是调用方直接操作 TCP 连接，而是让 Transport 有机会把本次响应对应的连接放回池中。关闭 Body 是最低要求；对于普通 HTTP/1.x keep-alive 响应，读到 EOF 后再关闭更稳妥。

封装请求函数，读完响应后再关闭 Body

把“创建请求、执行、读取、关闭、状态码判断”放进一个小函数，业务层只拿到字节或错误，最容易避免早退分支漏掉 Close。下面的例子故意先完整读取响应，再处理状态码；这样即使上游返回 404 或 500，也不会把响应体留在半开状态。

func fetch(ctx context.Context, url string) ([]byte, error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    if err != nil {
        return nil, fmt.Errorf("创建请求: %w", err)
    }

    resp, err := apiClient.Do(req)
    if err != nil {
        // Do 返回错误时，通常没有可供业务读取的响应体
        return nil, fmt.Errorf("发送请求: %w", err)
    }

    body, readErr := io.ReadAll(resp.Body)
    closeErr := resp.Body.Close() // 读完后明确关闭，释放响应资源
    if readErr != nil {
        return nil, fmt.Errorf("读取响应体: %w", readErr)
    }
    if closeErr != nil {
        return nil, fmt.Errorf("关闭响应体: %w", closeErr)
    }
    if resp.StatusCode = 300 {
        // 非 2xx 不是 Transport 错误，保留状态码便于上层分类处理
        return nil, fmt.Errorf("上游返回 HTTP %d: %s", resp.StatusCode, strings.TrimSpace(string(body)))
    }
    return body, nil
}

示例需要导入 context、fmt、io、net/http、strings 和 time。生产代码也可以使用 defer resp.Body.Close()，但在统一封装里显式接住关闭错误更容易保留诊断信息。若响应很大，不要无界地 io.ReadAll，应改用带上限的读取策略。

用状态码与读取错误分别判断结果

Client.Do 的 err 表示请求没有正常完成，例如网络或重定向处理失败；非 2xx 响应本身不会自动变成 error。响应体读取失败则发生在拿到响应头之后，不能和状态码混为一谈。

并发和异常场景下的检查清单

同一个 Client 可以被多个 goroutine 并发使用，但单个 Response.Body 仍只属于当前请求。检查代码时，重点看四处：每个 Do 成功分支是否都关闭 Body；非 2xx 是否也读取或有界消费正文；提前返回前是否已经关闭；是否在测试和生产里意外创建了多个 Transport。

取消上下文会终止请求及其响应读取，但它不替代正常的 Body 关闭。需要主动清理空闲连接时可以调用 apiClient.CloseIdleConnections()，这属于生命周期管理动作，不是每次请求后的固定步骤。

常见问题

只调用 Close，不读完 Body，可以复用连接吗？

不应把它当成稳定保证。Transport 会在关闭时尝试异步读到 EOF，但有保守上限；想提高 HTTP/1.x keep-alive 复用概率，应在响应体可控时读完再关。

非 2xx 要不要直接 return，省掉读取正文？

可以有界读取错误正文后再返回，尤其是接口需要诊断信息时。无论是否读取，都必须关闭 Body；不要把非 2xx 当成 Do 的网络错误。

每次请求都 new 一个 Client 会立刻出错吗？

不一定立刻报错，但会失去共享 Transport 状态和连接池收益。服务端程序通常把 Client 作为长期对象注入或包级复用。