sync.pool 仅适用于高频创建、短生命周期、大小稳定的对象，如 bytes.buffer；禁用于含外部资源、状态依赖或跨 goroutine 的对象，且必须手动重置状态、避免 defer 泄漏、防止重复 put。
sync.Pool 什么时候该用，什么时候别碰
它不是万能对象缓存，只适合「高频创建 + 短生命周期 + 大小稳定」的对象。比如 bytes.Buffer、自定义的解析上下文结构体、临时切片。如果你的对象带外部资源（如文件句柄、网络连接）、有状态依赖、或者生命周期跨 goroutine 边界，sync.Pool 会悄悄破坏逻辑——它不保证对象复用顺序，也不保证不被 GC 清掉。
- 常见错误现象：
nil指针 panic、数据错乱、偶发内存泄漏（其实是旧对象残留未清） - 典型误用场景：把数据库连接、HTTP client 实例塞进 Pool；在 HTTP handler 中 Put 一个修改了字段但没重置的结构体
- 性能影响：Pool 本身有锁开销，对象太少（几 MB）时，收益远低于管理成本
New 和 Get 的配合必须重置对象状态
sync.Pool 的 New 字段只在 Get 没拿到可用对象时调用，但它不负责清理。你 Put 进去的对象，下次 Get 可能直接返回——里面字段全是上次留下的脏数据。
- 正确做法：Put 前手动清空关键字段，或在
New返回的对象里做默认初始化，再在 Get 后强制重置 - 示例：如果 Pool 存的是
type ParserCtx struct { Input []byte; Err error }，Get 后必须重置ctx.Err = nil、ctx.Input = ctx.Input[:0] - 容易踩的坑：只清空指针字段（如
ctx.Data = nil），却忘了 slice 的底层数组还连着旧数据，导致内存无法释放
Put 的时机很关键：不能在 defer 里无脑放
很多教程教你在函数开头 ctx := pool.Get().(*ParserCtx)，结尾 defer pool.Put(ctx)。这看起来干净，但一旦函数 panic 或提前 return，defer 可能根本没执行，对象就丢了——Pool 不会帮你追踪漏掉的 Put。
- 更稳妥的做法：在明确的、不会跳过的出口路径上 Put，比如处理完请求后、解析完一段数据后
- 如果真要用 defer，确保它包裹的是「一定会执行」的逻辑，且对象在 defer 前没被意外修改或逃逸到其他 goroutine
- 兼容性注意：Go 1.19+ 对 Pool 内部做了优化，但 Put nil 或已 Put 过的对象仍会 panic，务必检查是否重复 Put
别指望 Pool 解决 GC 压力大的根本问题
如果 profile 显示 runtime.mallocgc 占比高，先看是不是算法层面在反复分配大 slice 或嵌套结构；sync.Pool 只是把一部分分配从 GC 转移到手动管理，反而可能让 pprof 难以定位真实热点。
- 验证是否真有效：用
go tool pprof -alloc_space对比开启前后堆分配总量，而不是只看 GC 次数 - 测试陷阱：本地压测时 Pool 效果明显，但生产环境因 goroutine 数量、负载分布不同，复用率可能骤降——Pool 是 per-P 的，不是全局共享池
- 真正复杂的地方在于：你要为每个对象类型单独设计 New/Get/Put 的契约，而这个契约一旦写错，bug 往往延迟暴露、难以复现
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
