Go net/http.Client 怎样减少临时分配

如果一个 Go 服务在高频调用 HTTP 接口，临时分配多半不是由某一行代码单独造成的，而是由客户端、传输层、请求体编码和响应体生命周期共同叠加。比较稳妥的做法是：让 http.Client 和 Transport 跨请求复用，减少编码过程中的中间缓冲，确保响应体读完并关闭，再用基准测试确认确实减少了 allocs/op 和 B/op。

官方资料：https://pkg.go.dev/net/http

先复用 Client 和 Transport，再处理请求体缓冲；不要把正在被 Transport 读取的数据提前放回池中，也不要为了追求零分配而牺牲响应体关闭、超时和错误处理。

• 客户端复用：Client 与 Transport 都可以安全地被多个 goroutine 并发使用。
• 连接复用：Transport 默认会缓存连接，但响应体没有读完并关闭时，后续请求可能无法充分复用持久连接。
• 缓冲复用：sync.Pool 适合短生命周期的临时对象，不适合保存业务状态或正确性数据。
• 收益判断：必须用 go test -benchmem 观察分配次数和字节数，不能只凭代码形状下结论。

先把 Client 和 Transport 放到请求循环外

我在排查 HTTP 热路径时，通常先看有没有这样的写法：每次调用都创建一个新的 http.Client，甚至再创建一个新的 http.Transport。这样做不仅产生短命对象，还会让 Transport 的连接缓存无法跨请求发挥作用。

官方文档明确建议复用 Client 和 Transport，并说明它们可以被多个 goroutine 并发使用。若只是调整空闲连接参数，可以在初始化时克隆默认 Transport，然后把得到的实例交给一个共享 Client。

package httpx

import (
    "net/http"
    "time"
)

var sharedTransport = func() *http.Transport {
    // 克隆默认配置，避免直接修改全局 DefaultTransport。
    transport := http.DefaultTransport.(*http.Transport).Clone()
    // 这个数是连接池容量示例，实际值应按并发和上游主机数调整。
    transport.MaxIdleConnsPerHost = 32
    return transport
}()

var sharedClient = &http.Client{
    // Client 只在进程初始化时创建，后续请求共享同一个 Transport。
    Transport: sharedTransport,
    // 超时覆盖连接、重定向以及读取响应体的整体生命周期。
    Timeout: 5 * time.Second,
}

这里的关键不是把数字 32 当成通用答案，而是把配置和生命周期固定下来。若业务访问很多不同主机，还要结合 MaxIdleConns、IdleConnTimeout 和上游连接特征调整；如果服务退出或配置热切换，再通过 CloseIdleConnections 做有边界的清理。

请求体编码时，只回收真正的临时缓冲

JSON 请求常见的分配链路是：创建编码器、扩容一个缓冲区、把缓冲区交给请求体，再为下一次调用重新创建。可以把编码中间态放进 sync.Pool，但要分清“编码缓冲”和“发送中的请求数据”。编码结束后，Transport 仍可能在异步读取请求体，所以不能把仍被请求使用的底层字节数组直接放回池中。

下面的函数只池化 bytes.Buffer，返回一份独立的 payload。这样会保留一次必要的数据复制，却避免每次编码都重新申请 Buffer；如果 payload 本身很大，是否值得这次复制，要用基准测试和实际请求大小来判断。

package httpx

import (
    "bytes"
    "encoding/json"
    "fmt"
    "sync"
)

var jsonBufferPool = sync.Pool{
    New: func() any {
        // 池中只放没有业务状态的临时编码缓冲。
        return new(bytes.Buffer)
    },
}

func encodePayload(value any) ([]byte, error) {
    buffer := jsonBufferPool.Get().(*bytes.Buffer)
    buffer.Reset()
    defer func() {
        // 清空后再归还，避免下一次看到上一次请求的内容。
        buffer.Reset()
        jsonBufferPool.Put(buffer)
    }()

    if err := json.NewEncoder(buffer).Encode(value); err != nil {
        // 编码失败时仍由 defer 负责回收临时 Buffer。
        return nil, fmt.Errorf("encode request: %w", err)
    }

    // 返回独立 payload，不能让请求继续引用即将归还的 Buffer。
    payload := make([]byte, buffer.Len())
    copy(payload, buffer.Bytes())
    return payload, nil
}

如果请求体来自已经存在的字节切片，可以直接用 bytes.NewReader(payload) 交给 http.NewRequestWithContext，避免先把字节切片转换成字符串再转回来。标准库对常见的 *bytes.Reader、*bytes.Buffer 和 *strings.Reader 会设置长度及可重放所需的 GetBody，这对重定向或幂等请求的重试语义也有帮助。

让请求一直持有自己的 payload

把临时缓冲归还得太早，是“看起来减少分配、实际引入数据竞争或请求体损坏”的典型错误。请求创建后，直到 Client.Do 返回并且底层已经完成对请求体的使用，payload 都必须保持有效。一个简单的调用层可以这样组织：

func postJSON(ctx context.Context, endpoint string, value any) error {
    payload, err := encodePayload(value)
    if err != nil {
        return err
    }

    // bytes.Reader 只读取这份独立 payload，不引用池中的编码 Buffer。
    req, err := http.NewRequestWithContext(ctx, http.MethodPost, endpoint, bytes.NewReader(payload))
    if err != nil {
        return fmt.Errorf("create request: %w", err)
    }
    req.Header.Set("Content-Type", "application/json")

    resp, err := sharedClient.Do(req)
    if err != nil {
        return fmt.Errorf("send request: %w", err)
    }
    defer resp.Body.Close()

    // 读到 EOF 有利于 Transport 复用持久连接；这里不保留响应正文。
    if _, err := io.Copy(io.Discard, resp.Body); err != nil {
        return fmt.Errorf("read response: %w", err)
    }
    if resp.StatusCode >= http.StatusBadRequest {
        return fmt.Errorf("unexpected status: %s", resp.Status)
    }
    return nil
}

这段示例需要同时导入 bytes、context、fmt、io 和 net/http。它刻意没有把响应体放进池里：响应体由 Transport 管理，调用方的责任是按约定读取并关闭，而不是接管内部实现。

响应体读完并关闭，比追求一个小对象更重要

Client.Do 成功返回时，Response.Body 非空，调用方必须关闭它。只关闭而不消费响应体，或者在错误分支忘记关闭，都会让连接复用机会下降，并在高并发下制造更多连接和调度压力。

如果正文不需要保存，io.Copy(io.Discard, resp.Body) 是清空读取路径的直观写法；如果正文要解析，就在解析完成后关闭，并给响应大小设置业务层上限。这里的“读完”是为了配合连接复用，不代表所有响应都应该无上限地读入内存。

func readStatus(resp *http.Response) error {
    defer resp.Body.Close()

    // 不需要正文时消费到 EOF，但不把全部内容存进新的切片。
    if _, err := io.Copy(io.Discard, resp.Body); err != nil {
        return err
    }
    // 状态码判断和资源关闭相互独立，任何分支都会执行 Close。
    if resp.StatusCode != http.StatusOK {
        return fmt.Errorf("remote status: %s", resp.Status)
    }
    return nil
}

sync.Pool 只适合“可丢弃”的短命对象

sync.Pool 的语义是缓存临时对象，不保证每次 Get 都命中，也不保证对象会一直留在池中。因此它适合降低高频临时缓冲的创建压力，却不适合保存连接、认证信息、业务缓存或必须存在的状态。

使用时可以记住三条边界：

• 归还前清空敏感或大尺寸内容，避免无意延长数据的生命周期。
• 对象归还后不能再被调用方引用；尤其不要把它作为异步请求体继续使用。
• 池化逻辑本身也有取出、重置和归还成本，低频路径可能因此变慢。

用 benchmem 判断是否真的减少了分配

“复用了一个 Buffer”不等于“整个请求少分配了一个 Buffer”。URL 解析、Header、请求对象、JSON payload、响应解析和错误包装都可能产生分配，而且编译器逃逸分析和输入大小会改变结果。把优化前后的两种实现放在同一组基准中，至少观察每次操作的字节数和分配次数。

func BenchmarkPostJSON(b *testing.B) {
    ctx := context.Background()
    value := struct {
        ID   int    `json:"id"`
        Name string `json:"name"`
    }{ID: 7, Name: "demo"}

    b.ReportAllocs()
    for i := 0; i 

正式压测还要区分网络等待和本地分配：同一个远端接口的响应时间波动，可能掩盖很小的内存收益。先用本地、稳定的测试服务观察趋势，再用生产流量确认连接复用、超时和错误处理没有被破坏。

几种常见写法怎么取舍

相关问题

每个请求都创建 Client 一定会立刻产生明显性能问题吗？

不一定。低频、短命命令行程序可能几乎感受不到差异，但服务端热路径会失去 Transport 的连接缓存复用机会。先复用共享实例，再用基准和连接指标判断收益。

可以把 bytes.Buffer 直接作为请求 Body 再马上放回 sync.Pool 吗？

不可以。Transport 可能在调用返回后仍异步读取或关闭请求体。应返回独立 payload，或者设计一个明确的自定义 Body 生命周期，确保请求完全结束后再回收底层存储。

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

可以关闭资源，但未读完的正文可能降低底层连接复用机会。若正文不需要，通常应消费到 EOF 后关闭；若正文很大，则按业务需要做限量读取并接受连接可能不能复用的结果。

sync.Pool 能保证减少 allocs/op 吗？

不能保证。它是临时对象缓存，可能被清空，也有 Get、Reset 和 Put 的成本。只有在稳定基准和真实负载中观察到收益时，才值得保留池化代码。