sync.pool仅适用于高频创建销毁且生命周期限于单次请求或goroutine的临时对象；误用会导致脏数据、内存碎片或资源泄漏，其new函数非构造器且不保证线程安全调用，对象在gc时才被清空，无法预测存活时间。
sync.Pool 什么时候该用、什么时候不该用
它不是万能缓存，也不是所有对象都适合丢进去。真正该用的场景只有两个：高频创建销毁的临时对象（比如 bytes.Buffer、sync.WaitGroup）、且生命周期严格限定在单次请求或单个 goroutine 内。
常见误用是把带状态的对象（如已写入数据的 bytes.Buffer）放进去复用，结果下一个 goroutine 拿到的是脏数据；或者把大对象（比如几 MB 的结构体）塞进池子，反而加剧内存碎片和 GC 扫描压力。
- 适合：
json.Decoder、http.Header、短生命周期的切片（[]byte预分配缓冲） - 不适合：
net.Conn、带锁的结构体、含指针指向长期存活对象的实例 - 性能影响：池子本身无锁但有 per-P 局部性，跨 P 获取会触发 slow path，高并发下注意
Get/Put均衡
sync.Pool.New 字段不是构造函数，而是兜底工厂
New 只在池子为空时被调用，而且不保证只调一次——它可能被多个 goroutine 同时触发，所以必须是线程安全的。更重要的是，它不控制对象生命周期，也不会在对象被回收时自动调用清理逻辑。
典型错误是把资源释放逻辑（比如 Close()）写在 New 里，或者在里面初始化全局共享状态（如复用一个 rand.Rand 实例），导致数据竞争。
立即学习“go语言免费学习笔记（深入）”；
-
New应只做最轻量初始化：分配零值结构体、预设容量的切片、空bytes.Buffer - 不要在
New中调用time.Now()、rand.Intn()等非幂等操作 - 如果需要清理，得靠使用者自己在
Put前手动重置，比如buf.Reset()
sync.Pool 对象不会被立即回收，GC 时才清空
Pool 不是引用计数容器，也没有“过期”机制。你 Put 进去的对象，可能在下次 Get 时就被返回，也可能在下一次 GC 后彻底消失——这完全由运行时决定，无法预测。
这意味着不能依赖 Pool 做资源保活，也不能假设 Put 后对象还留在内存里。有些代码试图用 Put 来“延迟释放”，结果发现连接没关、文件没 flush，因为对象早被 runtime 清掉了。
- GC 触发后，每个 P 的本地池会被清空，私有对象保留一次，共享池全丢
- 没有 API 能查池中当前有多少对象，调试只能靠 pprof 查
sync.Pool相关指标 - 若需强保活，得配合其他机制（比如引用计数 + finalizer），但代价远超 Pool 本身
如何验证 sync.Pool 是否真的起了作用
别光看 Get 次数变少，重点看堆分配次数和 GC 频率是否下降。用 go tool pprof 看 runtime.mallocgc 调用栈，对比开启/关闭 Pool 时的 inuse_space 和 allocs 差异。
最容易被忽略的是：Pool 效果在低并发下几乎为零，因为对象根本没机会被复用；而高并发下如果 Put 不及时（比如 defer 放太晚），对象还是逃逸到堆上。
- 用
go run -gcflags="-m" main.go确认关键对象是否逃逸 - 在基准测试中固定 goroutine 数（如
go test -bench=. -benchmem -benchtime=5s） - 检查
runtime.ReadMemStats中的PauseTotalNs和NumGC，比看吞吐量更准
Pool 的边界很窄：它只缓解特定模式下的分配压力，一旦对象大小波动大、生命周期不可控、或复用率低于 30%，收益就迅速归零。这时候与其硬调 Pool，不如先看能不能减少分配本身。
