sync.Pool仅适用于高频创建、短生命周期、结构稳定的对象，如*bytes.Buffer；若对象含外部依赖、生命周期需严格控制或分配不频繁，则应避免使用，否则会增加GC压力和内存碎片。
sync.Pool 什么时候该用，什么时候别碰
它不是万能缓存，也不是全局对象池。只适合「高频创建 + 短生命周期 + 结构稳定」的对象，比如 *bytes.Buffer、*sync.WaitGroup、自定义的解析上下文结构体。如果对象带外部依赖（如含 http.Client 字段）、需严格控制生命周期（如连接池），或者单次分配不频繁（每秒几百次以下），用 sync.Pool 反而增加 GC 压力和内存碎片。
- 常见错误：把
sync.Pool当成“避免 new 的银弹”，结果对象长期滞留池中，占用内存不释放 - 典型场景：HTTP 中间件里反复构造的
RequestCtx、日志库中的Entry、JSON 解析用的临时Decoder - 注意：Pool 中对象可能被任意 Goroutine 拿走，不能假设调用
Put后还能再用；也不能在Put时修改对象状态（比如清空 map 却没重置指针）
New 字段必须返回新实例，不能复用旧对象
sync.Pool 的 New 字段是兜底机制，只在池空时触发。如果这里返回了之前 Put 过的对象（比如从池里又取一个再返回），会导致对象循环引用或状态污染。
- 错误写法：
New: func() interface{} { return pool.Get() }—— 极易引发 panic 或数据错乱 - 正确写法：
New: func() interface{} { return &MyStruct{} }或return bytes.NewBuffer(nil) - 性能影响：如果
New函数太重（比如初始化大 slice 或打开文件），会拖慢首次 Get，建议只做轻量初始化
Put 和 Get 不配对？对象就丢了
sync.Pool 不保证 Put 进去的对象一定被后续 Get 拿到，更不保证“谁 Put 谁 Get”。它的核心逻辑是：GC 时清空整个池；每个 P（处理器）维护本地私有池，跨 P 时才进共享池；Get 优先从本地拿，没有才尝试共享池，最后才调 New。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 常见错误：在 defer 里无条件
Put，但对象中途已被其他 goroutineGet并修改 —— 导致状态混乱 - 安全做法：确保对象生命周期完全由当前函数控制，用完立刻
Put，且不跨 goroutine 传递指针 - 调试技巧：给对象加标记字段（如
inPool bool），在Put前断言!obj.inPool，可快速发现重复 Put 或提前 Put
Go 1.22+ 的 Pool 性能变化与实测建议
Go 1.22 对 sync.Pool 做了本地池扩容优化，减少锁竞争，但在高并发下仍可能成为瓶颈。实测显示：当每秒 Get/put 超过 100 万次，且对象大小 > 2KB 时，池本身开销可达 5%～10% CPU。
立即学习“go语言免费学习笔记（深入）”；
- 兼容性注意：Go 1.21 及以前版本，
Pool在 fork 后子进程不会继承内容，但 Go 1.22 开始部分 runtime 优化可能影响 fork 行为，长周期服务需留意 - 参数差异：无需手动调优，但可通过
GODEBUG=pooldebug=1查看池命中率（输出到 stderr） - 容易忽略的点：Pool 中对象不会被 GC 扫描其内部指针 —— 如果你 Put 的是一个含指针的大 struct，而 New 里没清零，旧指针可能阻止一批内存被回收
真正难的不是写对 sync.Pool，而是判断某个对象到底值不值得放进池里。压测前后看 p99 分配耗时和堆增长速率，比凭感觉靠谱得多。
