Go sync.Pool 清空对象后再放回池

使用 sync.Pool 复用 bytes.Buffer、临时切片或请求上下文对象时，“清空对象”通常指清理对象自身的旧状态，而不是把 Pool 里的条目全部删除。最小安全顺序是：Get 取出对象，调用对象的 Reset 或显式清理字段，完成当前请求的写入，最后确认没有其他引用后再 Put。

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

Pool 只提供可丢弃的临时复用机会，不能保证下一次 Get 一定拿到上一次 Put 的对象；对象是否干净，必须由使用方在边界处负责。

先分清“清空对象”和“清空池”

sync.Pool 的职责是保存可复用的临时对象，并允许运行时在需要时把它们丢弃。它没有让调用方可靠地枚举或清空全部条目的接口，所以业务代码不应该围绕“池里当前有几个对象”来设计。

真正需要清理的是对象状态。例如 bytes.Buffer.Reset 会把可读长度恢复为零，但仍可能保留底层容量；一个自定义结构体则要自己清理切片长度、错误值、租户标识或请求级指针。清理策略必须和对象类型绑定。

Get 后先恢复可用状态

推荐把“取出后恢复初始状态”写成固定入口，而不是依赖上一次调用恰好留下了什么。下面的示例让 New 负责创建指针，Get 后立即 Reset，并在所有写入结束后归还。

package main

import (
    "bytes"
    "fmt"
    "sync"
)

var bufferPool = sync.Pool{
    New: func() any {
        // 返回指针，避免把可变缓冲区复制进接口值。
        return new(bytes.Buffer)
    },
}

func render(name string) string {
    buf := bufferPool.Get().(*bytes.Buffer)
    // 清掉上一次使用留下的可读内容，再开始本次写入。
    buf.Reset()
    defer bufferPool.Put(buf)

    fmt.Fprintf(buf, "hello, %s", name)
    // 在 Put 前先把结果复制成独立字符串，避免归还后继续读 buf。
    return buf.String()
}

这里的 defer 只负责“函数退出时归还”，不负责清理。清理动作放在 Get 之后更直观，也能覆盖 New 创建对象和 Pool 返回旧对象两种来源。

使用完成后再 Put

Pool 中的对象不能同时属于当前调用方和其他调用方。只要返回值、异步任务、日志写入或下游函数仍然持有缓冲区引用，就不能提前 Put。归还后，下一次 Get 可能立刻拿到同一个对象，也可能拿到新对象，甚至拿不到任何旧对象。

如果对象中带有请求级字段，显式清理可以放在归还前，也可以由下一次 Get 的统一入口完成，但团队最好只选择一种责任模型。对 bytes.Buffer 一类对象，常见做法是 Get 后 Reset；对带有敏感业务字段的结构体，则应在归还前明确置零或断开引用，并评估是否真的适合进入 Pool。

容量、敏感数据和类型边界怎么处理

清空长度不等于释放底层容量。某次异常大请求可能让缓冲区容量明显增长，之后它仍可能被复用。如果对象容量可能失控，可以在归还前按上限判断：小对象放回 Pool，大对象直接丢弃。这个上限是业务取舍，不是 sync.Pool 的配置项。

const maxBufferCap = 64  maxBufferCap {
        return
    }
    // Reset 只清理可读长度，归还前仍要确认没有外部引用。
    buf.Reset()
    bufferPool.Put(buf)
}

另外，Pool 不是安全擦除工具。即使先把字节写成零，也不能把它当作秘密数据生命周期控制方案；对于高敏感内容，应优先使用更明确的生命周期设计，减少复用带来的残留风险。

什么时候值得引入 sync.Pool

可以用三个条件做决定：对象创建频率高、对象只在短时间内使用、对象可以被安全地重新初始化。如果对象需要可靠保存、必须按容量精确管理、生命周期跨越请求，或者清理成本接近重新分配，就不适合为了“看起来省分配”而使用 Pool。

最后记住：Get 的结果可能来自 New，也可能是任意可用对象；Put 只表示交还复用机会。围绕这两个语义安排清理和所有权，才是“清空对象后再放回池”的完整做法。

常见问题

sync.Pool 能不能手动清空全部对象？

业务代码不能依赖一个可枚举、可精确清空的 Pool。需要丢弃整个复用策略时，通常是让 Pool 失去引用或更换新的 Pool 变量，但这属于整体生命周期设计，不是逐个清理条目。

Put 之前和 Get 之后，清理应该放在哪里？

两种方式都可以，但必须统一责任。Get 后清理能确保拿到旧对象和新对象都进入同一初始状态；Put 前清理能减少对象在池中停留时的残留内容。复杂对象可在两处分别承担不同职责，但要写清楚，避免遗漏字段。