Go sync.Pool 适合复用 bytes.Buffer 吗：清理、生命周期与误用边界

线上接口偶尔把上一个请求的 JSON 尾巴带进下一个响应，日志里却看不出业务字段写错。最后发现，问题不在序列化，而是一个放进 sync.Pool 的 bytes.Buffer 取出后没有先清空。sync.Pool 可以帮 Go 程序减少短命对象分配，但它不负责替你管理对象状态，也不保证对象一定会被下一次取到。

复用 bytes.Buffer 的安全前提是：取出后先 Reset，只在对象确实短命、可丢弃且不跨请求保存时使用；放回之前还要确认没有把它的地址、切片或字符串引用泄露出去。

问题现场：响应体为什么会带上一次请求的内容

假设服务要拼一个小 JSON 响应，为了少分配几次，代码把缓冲区放进池里：

var responsePool = sync.Pool{
    New: func() any { return new(bytes.Buffer) },
}

func buildResponse(id int) []byte {
    buf := responsePool.Get().(*bytes.Buffer)
    defer responsePool.Put(buf)

    fmt.Fprintf(buf, `{"id":%d,"ok":true}`, id)
    return buf.Bytes()
}

第一次调用看起来正常，第二次却可能得到两段 JSON 拼接。更隐蔽的是，测试通常只调用一次，或者恰好池在两次调用之间被运行时清空，于是问题很难稳定复现。

这里还有第二个问题：返回的切片仍然指向缓冲区的底层数组，函数把它交给调用方后，缓冲区又可能马上被下一次请求改写。就算补上 Reset，这个引用关系也没有消失。

先验证两个事实：池不是缓存，Reset 也不是释放

sync.Pool 的定位是临时对象池。运行时可以在合适的时机清掉池里的对象，因此业务不能依赖“放进去，下次一定还在”。Get 没拿到对象时会调用 New（如果设置了），否则返回 nil。

Reset 则是把缓冲区的读写位置归零，让后续写入从逻辑上的空缓冲区开始。它通常保留已经申请的容量，方便同类小对象继续使用；这不等于内存永远被池持有，也不等于大容量会自动缩小。

buf := responsePool.Get().(*bytes.Buffer)
buf.Reset() // 取出后清理旧内容

fmt.Fprintf(buf, `{"id":%d,"ok":true}`, id)
body := append([]byte(nil), buf.Bytes()...)
responsePool.Put(buf)
return body

这个版本用 append 复制了响应数据，调用方不再依赖池内缓冲区。复制有成本，但它把对象生命周期和响应生命周期切开了；对小响应来说，这个边界通常比省掉一次复制更值得。

故障根因：三个生命周期被误当成了一个

这类代码经常同时混淆三件事：

• 池中对象的生命周期：由运行时和当前程序的使用方式决定，不能作为业务状态存储。
• 缓冲区内容的生命周期：从本次写入开始，到下一次 Reset 或覆盖为止。
• 返回切片的生命周期：由调用方决定，可能远远长于当前函数。

如果返回 buf.Bytes() 后马上把 buf 放回池，第三个生命周期就会与第二个生命周期重叠。调用方还没读完，另一个请求已经写入同一块底层数组，结果可能是数据被覆盖、响应内容变化，甚至出现并发下的竞态。

另一个误区是把 sync.Pool 当作“昂贵对象缓存”。数据库连接、带配置的客户端、需要关闭的文件等对象，都不应该随意放进这里。它们有明确的所有权和释放协议，适合显式管理。

修复方案：把清理、复制和归还写成一条完整路径

在 HTTP 处理函数里，建议让池对象只活在当前请求的构造阶段，并把最终响应交给框架或调用方：

var responsePool = sync.Pool{
    New: func() any { return new(bytes.Buffer) },
}

func buildResponse(id int) []byte {
    buf := responsePool.Get().(*bytes.Buffer)
    if buf == nil {
        buf = new(bytes.Buffer)
    }
    buf.Reset()

    fmt.Fprintf(buf, `{"id":%d,"ok":true}`, id)
    body := append([]byte(nil), buf.Bytes()...)

    // 不让过大的缓冲区长期回到池里。
    if buf.Cap() 

这里的容量阈值不是通用常数，而是一个需要用实际响应大小和内存曲线验证的边界。某次上传或异常拼接把容量撑到几 MB 后，不应继续把这个大对象放回一个服务所有请求共享的池里。

如果调用链能够直接写入响应，而且写入方不会在返回后继续使用缓冲区，也可以避免复制；但这需要把所有权写清楚。只要函数返回的是 []byte、异步任务还要读取，或者响应会被缓存，就应该复制。

复查结果：用测试覆盖污染、空池和大容量三个边界

不要只测试“能返回正确 JSON”。至少要检查连续调用、返回值独立性和大缓冲区处理：

func TestBuildResponseDoesNotShareBuffer(t *testing.T) {
    first := buildResponse(1)
    second := buildResponse(2)

    if string(first) != `{"id":1,"ok":true}` {
        t.Fatalf("first response was changed: %s", first)
    }
    if string(second) != `{"id":2,"ok":true}` {
        t.Fatalf("unexpected second response: %s", second)
    }
}

再用 go test -race ./... 检查是否有切片被异步读取。竞态测试不能证明所有业务边界都正确，但它很擅长抓住“函数返回后还在改同一块内存”这种错误。

如果压测后内存没有下降，先看缓冲区容量分布和池的命中收益，不要只盯着分配次数。大对象回池、池命中率很低、复制成本很高时，去掉池反而可能更简单。

什么时候该用，什么时候直接 new

适合使用的通常是高频、短命、结构简单、可随时重新创建的临时对象，例如请求拼接缓冲区、临时编码器或一次性格式化辅助对象。对象必须能在取出后恢复到干净状态。

下面几种情况更适合直接 new(bytes.Buffer) 或用普通构造：

• 调用频率不高，性能数据没有显示分配是瓶颈。
• 对象携带请求、租户或用户状态，清理很容易漏字段。
• 对象会跨请求、跨协程或跨队列保存。
• 对象释放时机有业务含义，需要明确关闭、提交或回滚。

常见问题

sync.Pool.Get 一定能拿到之前 Put 的对象吗？

不能。池可以被运行时清空，业务只能把它当作降低临时分配压力的机会，不能依赖命中。

bytes.Buffer.Reset 会释放底层内存吗？

通常不会立即释放已分配容量。它主要重置逻辑长度；是否保留大容量要结合对象大小设置回池条件。

返回 buf.Bytes() 后还能把 buf 放回池吗？

只有在返回数据已经复制、且外部不再持有底层切片时才安全。否则下一次写入可能覆盖调用方仍在读取的数据。

sync.Pool 适合放数据库连接吗？

不适合。连接有关闭、健康检查和并发复用协议，应使用连接池或明确的资源管理方式。

最后的检查清单

把 sync.Pool 放进生产代码前，至少确认四点：取出后会清理；返回切片不会指向仍会复用的底层数组；异常路径也会归还或丢弃对象；压测数据能证明它带来收益。只要其中一项说不清，普通构造往往是更稳的选择。