Get后必须手动Reset，因为sync.Pool只复用底层内存和指针，不自动清零len、cap、Err等字段；New仅兜底创建干净对象，而Get返回的极大概率是他人用过的脏实例，不Reset会导致bytes.Buffer残留旧内容、json.Unmarshal解析出旧key、Header混入前序Cookie等数据污染。
sync.Pool 不复用函数，它复用的是函数返回的、可安全重置的对象实例；所谓“复用函数创建的对象”，本质是靠 New 返回干净对象 + Get 后手动 Reset + Put 前确保无残留状态，三者缺一不可。
为什么 Get 后必须手动调 Reset，不能只靠 New 初始化？
sync.Pool 完全不关心你对象的业务语义，它只存指针、取指针。底层内存（比如 []byte 的底层数组）大概率被复用，但 len、cap、Err、pos 这些字段不会自动归零——New 只在池空时兜底调用，而 Get 返回的极大概率是别人用过的脏对象。
- 常见错误现象：
bytes.Buffer.String()返回上一次拼接内容；json.Unmarshal解析出旧 key；http.Request.Header混入前一个请求的 Cookie - 必须重置的典型操作：
buf.Reset()、decoder.DisallowUnknownFields()、ctx.Input = ctx.Input[:0]、ctx.Err = nil、for k := range ctx.cache { delete(ctx.cache, k) } - 别信“New 已初始化就不用 Reset”——New 是懒加载工厂，不是构造入口；它不保证每次 Get 都走 New，更不负责清理上一次状态
New 函数写错会直接破坏整个 Pool 行为
New 必须返回全新、干净、线程安全的实例，且不能有副作用。它会被多个 goroutine 并发调用，一旦写错，轻则数据污染，重则 panic。
- 绝对禁止：
return pool.Get()（循环引用）、return &globalBuf（多 goroutine 共享同一实例） - 正确写法必须满足两个条件：返回全新分配的对象（如
new(bytes.Buffer)或make([]byte, 0, 1024)），且所有字段处于可复用状态（零值或已内部重置） - 不能在
New里做耗时操作（如打开文件、发起 HTTP 请求），也不能依赖未同步的共享变量
Put 的时机和前置条件比 Get 更容易踩坑
Put 是无条件交还指针，不做任何校验。放进去什么，下次 Get 就可能拿出来什么——没重置就 Put，等于往池里塞毒药。
立即学习“go语言免费学习笔记（深入）”；
- 典型反模式：
defer pool.Put(x)看似简洁，但函数 panic 或提前 return 时 defer 不执行，对象永久丢失；或对象被意外逃逸到 channel / 全局变量后又被 Put，导致后续 goroutine 拿到脏数据 - 稳妥做法：在明确不再使用对象后立刻
Put，例如data := b.Bytes(); pool.Put(b)，而非等 defer - Put 前必须清空所有可变字段：只设
obj.Data = nil不够，obj.Input是 slice 时还得obj.Input = obj.Input[:0]，否则底层数组残留旧数据，内存无法释放 - 禁止重复 Put：Go 1.19+ 仍会 panic，务必确保每个对象只 Put 一次
sync.Pool 不是万能缓存，适用边界非常明确
它只适合高频创建、短生命周期、大小稳定、无外部资源依赖的临时对象。超出这个范围，收益远低于风险。
- 推荐类型：
bytes.Buffer、json.Decoder、固定 cap 的[]byte、自定义解析上下文结构体（含Reset()方法） - 危险类型：
http.Request/http.ResponseWriter（含 conn 引用）、os.File（fd 不可复用）、带sync.Mutex未重置的结构体、含闭包或全局 map 引用的对象 - GC 行为影响大：每次 GC 会清空池中未被持有的对象，高频率 GC（如小堆配置）会让 Pool 失效；长时间不 GC 又可能滞留旧对象占用内存
- 验证是否有效：用
go tool pprof -alloc_space对比前后runtime.mallocgc调用次数，而不是只看代码有没有加Get/Put
最难的不是写对 Get 和 Put，而是判断一个对象“能不能安全 Reset”——它内部有没有隐藏状态、是否依赖外部生命周期、字段是否真能被干净覆盖。这点没法靠工具检查，只能靠读源码、压测、看 heap profile 里的对象存活链。
