Go 每次请求都创建 Client 为什么会导致连接资源浪费

如果一个 Go 服务在每次请求里都写 &http.Client{}，问题不只是多创建了几个结构体。Client 通常持有带连接缓存的 Transport；请求结束就丢掉它，后续请求也就无法稳定复用同一组持久连接。更稳妥的做法是让一个配置好的 http.Client 活得足够久，在请求之间复用，并在每次拿到响应后关闭 Response.Body。

为什么 Client 的连接状态不能跟着请求一起销毁

http.Client 是请求策略和传输层的外壳，真正维护连接复用状态的通常是它的 Transport。把 Client 放在服务对象、依赖注入容器或包级变量中，意味着连接缓存可以跨请求存在；把它写在循环内部，则每轮都可能丢失这份状态，出现重复建连、更多握手和更多临时资源。

这里的“复用”不是说所有请求一定共用一条 TCP 连接，而是由同一个 Transport 根据目标地址、协议和空闲状态管理连接。Client 只要配置一致，就能把超时、重定向和 Cookie 等策略也统一起来。

一段可复用的请求代码需要同时关闭 Body

可以把共享 Client 和请求函数拆开。下面的例子只读取 JSON 文本，重点是错误分支也不遗忘响应体：

package main

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

// Client 在服务生命周期内复用，避免每次调用都丢失 Transport 状态。
var client = &http.Client{Timeout: 5 * time.Second}

func fetch(url string) ([]byte, error) {
    resp, err := client.Get(url)
    if err != nil {
        return nil, err
    }
    // 成功拿到响应后，无论后续读取是否成功都要释放 Body。
    defer resp.Body.Close()

    if resp.StatusCode = 300 {
        return nil, fmt.Errorf("unexpected status: %s", resp.Status)
    }
    // 读到 EOF 有助于 Transport 判断连接是否可以继续复用。
    data, err := io.ReadAll(resp.Body)
    if err != nil {
        return nil, err
    }
    return data, nil
}

defer resp.Body.Close() 应该紧跟在 err == nil 之后，因为此时才确定 resp 可用。状态码检查放在读取前可以减少无意义的解析，但如果错误响应的 Body 也需要完整消费，应该按业务需要读取或限制读取后再关闭。

Body 读不完时，为什么只 Close 还不够稳

官方文档给出的关键条件是：Body 既读到 EOF 又关闭时，底层 RoundTripper 才更有机会复用 keep-alive 连接。Transport 在关闭 Body 时会尝试异步读取一部分剩余内容，但这不是“随便 Close 都等价于读完”的保证；未消费的响应很大时，连接仍可能被放弃并重新建立。

因此可以按结果类型做选择：

什么时候才该新建 Client 或关闭空闲连接

如果两个依赖需要完全不同的代理、TLS、Cookie 或 Transport 配置，可以分别创建长期存在的 Client；这是配置隔离，不是按请求清理。程序优雅退出、测试结束或明确更换 Transport 时，可以调用 client.CloseIdleConnections() 清理当前空闲连接。它也不是每次请求后的必做动作，否则会主动削弱连接复用。

验收时先检查三点：Client 是否在循环外；每个成功响应是否都有 Close；需要复用的响应是否被消费到 EOF。只要这三处生命周期一致，连接资源浪费通常就能从“每次请求丢状态”回到可控范围。

相关问题

http.Client 可以被多个 goroutine 共用吗？

可以。官方文档明确说明 Client 可并发使用，前提是不要在请求进行时无保护地修改共享配置。

每次创建 Request 和每次创建 Client 一样吗？

不一样。Request 描述单次请求，Client 承担跨请求的策略和 Transport 关系；通常每次请求新建 Request 是自然做法。

Response.Body 只调用 Close 会不会泄漏？

Close 能释放响应资源，但未读到 EOF 时不保证连接可复用。对需要复用的正常响应，读取完成后再关闭更稳妥。