sync.Pool能显著降低GC压力，但仅适用于高频分配、短生命周期、大小稳定的小对象；误用会导致内存滞留、GC频次上升及脏数据复用，Get后必须手动Reset，Put前须确保对象已脱离所有goroutine作用域。
直接说结论：sync.Pool 能显著降低高频短命对象的 GC 开销，但用错比不用更危险——它不保证复用、不检测使用状态、不清理残留数据，只在「高频创建 + 短期存活 + 结构体大小适中」这三点同时满足时才值得引入。
sync.Pool.Get() 返回的对象为什么总是脏的？
因为 sync.Pool 不做任何状态重置。你 Put 进去的对象，下次 Get 出来时，字段值、slice 长度/容量、map 内容全都是上次留下的。
- 错误写法：
buf := pool.Get().([]byte)直接用 —— 如果上次用了 200 字节，这次len(buf)还是 200，buf[0]可能是上个请求的垃圾数据 - 正确做法：每次
Get后必须手动重置，比如buf = buf[:0]（对 slice）、req.Header = make(http.Header)（对 map 字段） - 结构体字段也要清零：
buf.pos = 0、buf.err = nil，不能依赖 New 函数返回时的初始值
sync.Pool.New 函数为什么不能返回全局变量或复用底层数组？
因为 New 是并发安全的前提——它必须每次返回一个**全新内存块**。如果返回共享实例，多个 goroutine 同时读写就会竞态。
- 危险写法：
New: func() interface{} { return &globalBuf }—— 所有 goroutine 共享同一块内存 - 危险写法：
New: func() interface{} { return make([]byte, 1024) }后没清空内容，又没在Put前重置len，下次Get到的就是残留数据 - 安全写法：
New: func() interface{} { return &MyBuf{data: make([]byte, 0, 1024)} }，且每次Get后执行buf.data = buf.data[:0]
sync.Pool.Put() 放回去之前，到底能不能还被其他 goroutine 访问？
不能。一旦调用 Put，对象就可能立刻被另一个 goroutine 的 Get 拿走。此时若原 goroutine 还在读写，就是典型的 use-after-free。
立即学习“go语言免费学习笔记（深入）”；
- 典型翻车场景：在
defer pool.Put(buf)里放回，但函数内部启动了 goroutine 并把buf传了进去 - 异步回调、channel 发送、闭包捕获变量，都意味着对象生命周期已超出当前函数作用域
- 安全边界很明确：只有确认对象不再被任何地方持有指针后，才能
Put—— 通常放在处理逻辑末尾，且无 goroutine 启动、无 channel 操作、无闭包引用
Go 1.19+ 的 sync.Pool 为什么复用率突然变低？
因为本地池（per-P）清理更激进了：当某个 P 长时间闲置（比如大量 goroutine 阻塞在 I/O），它绑定的 pool 会被提前清空，而不是等到 GC。
- 影响最明显的是短平快 HTTP 请求场景：每个请求分配一个 goroutine，处理完就退出，P 很快闲置 → 本地池被清，复用率下降
- 不是 bug，是设计权衡：避免闲置 P 占着大量内存不释放
- 调试时别只看 GC 次数，要配合
GODEBUG=gctrace=1和-race，确认对象是否真被复用、有没有竞态
真正难的从来不是怎么写 sync.Pool，而是判断某个对象该不该放进 Pool——它不解决所有分配问题，只解决那一小撮「创建贵、活不久、量很大」的对象。多一个 make([]byte, 0, 128) 不会压垮程序，但少一次误用的 Put 可能引发线上静默数据污染。
