sync.Pool不是性能开关，而是高频小对象的“减压阀”；用错反而拖慢服务、污染数据、引发panic。
直接说结论：sync.Pool 不是性能开关，而是高频小对象的“减压阀”；用错反而拖慢服务、污染数据、引发 panic。
sync.Pool.Get() 返回 nil 怎么办？
这是最常被忽略的起点——Get() 返回 nil 完全合法，且在冷启动、GC 刚跑完、P 本地池空闲超 5ms（Go 1.19+）时频繁发生。
- 别直接类型断言：
buf := pool.Get().(*bytes.Buffer)→ panic - 正确写法必须判空：
buf := pool.Get().(*bytes.Buffer); if buf == nil { buf = new(bytes.Buffer) } - 更推荐统一入口：把判空 + 初始化逻辑封装进
GetBuffer()函数，避免每个调用点重复写 - 注意：
New回调本身不线程安全，可能并发触发多次，所以里面只能做轻量初始化（如new(T)或bytes.NewBuffer(nil)），不能开文件、建连接
Put 前不 Reset 就等于往池里投毒
Put() 不校验、不清理、不重置——它只负责把指针交还给调度器。下一毫秒被别的 goroutine 拿走时，残留字段就是 bug 温床。
- 对
*bytes.Buffer：必须调buf.Reset()，不是只改buf.Len() - 对
[]byte：必须执行b = b[:0]，保留 cap 但清空 len；只做b = nil或b = make([]byte, 0)会丢掉预分配容量 - 对自定义 struct：实现幂等
Reset()方法，显式清空 slice（s = s[:0]）、map（m = nil，不是make(map[K]V)）、error（err = nil）、指针字段（p = nil） - 切忌 defer 无脑 Put：如果
Get()返回的是New创建的新对象，而你又 defer Put，等于刚建好就塞回去——下次 Get 可能拿到未初始化的“新”对象
为什么不能池化 string？
string 是只读结构体，底层指向的字节数组不可修改，也无法安全重置。强行池化既无效又危险。
立即学习“go语言免费学习笔记（深入）”；
- 池化
string本身没意义：每次string(b)转换都不分配新内存，但 string 本身无法复用内容 - 真正该池化的是
[]byte：预分配 cap（如make([]byte, 0, 512)），Get后b = b[:0]，写完用string(b)零拷贝转出 - 别用
string(append(b, ...))：append 可能扩容并返回新底层数组，原池对象失效 - strings.Builder 不可替代 sync.Pool：它内部用 []byte，但非线程安全、不可跨 goroutine 复用，Reset() 也不释放底层数组；适合单次构建，不适合高频复用场景
哪些对象绝对不该放进 Pool？
误放不仅无效，还会引入泄漏、panic 或状态污染。
- 大对象（> 32KB）：Go 分配器绕过 Pool，Put 进去基本不会被复用
- 含
runtime.SetFinalizer的对象：Pool 不负责 finalizer 管理，GC 时行为不可控 - 带外部资源引用的对象：如
http.Request（含 context 和 conn）、os.File（fd 不可复用）、含未释放锁的 struct - 生命周期跨 goroutine 的对象：比如 middleware 中 Get，子 goroutine 里 Put —— 违反所有权约定，导致对象丢失或竞争
- 非指针类型（如
int、string）：复用收益低，同步开销反而更高
真正难的不是写 Get 和 Put，而是判断一个对象“能不能安全 Reset”——它内部有没有隐藏状态（比如未暴露的 buffer、未 reset 的 map 迭代器、未关闭的 channel）。这点没法靠工具检查，只能靠读源码、压测、看 pprof -alloc_space 里的对象存活链。
