sync.Pool适用于高频分配、固定生命周期的小对象（如bytes.Buffer），不适用于大对象、带finalizer对象或跨goroutine生命周期不可控的实例。
sync.Pool 什么时候该用，什么时候不该用
绝大多数场景下，sync.Pool 不是性能优化的银弹，而是为高频分配+固定生命周期的小对象“兜底”的专用工具。它适合：HTTP handler 中反复创建的 bytes.Buffer、JSON 解析用的临时 map[string]interface{}、或自定义结构体切片；不适合：大对象（如 >1KB 的 struct）、带 finalizer 的对象、或生命周期跨 goroutine 不可控的实例。
常见错误现象：sync.Pool.Get() 返回 nil 或脏数据，是因为 Put 前没清空字段，或 Get 后直接复用未初始化的指针字段。
- 对象必须可安全复用：字段默认值能覆盖上一次使用残留（比如用
buf.Reset()而不是只改buf.Len()） - 不要依赖
sync.Pool.New回调做昂贵初始化（如打开文件、建连接），它可能在任意 goroutine 中被触发 - GC 会定期清理整个 Pool，所以别指望它长期缓存“热”对象
Get/put 配对必须严格、且对象归属清晰
sync.Pool 不检查对象来源，Put 一个由其他 Pool Get 来的对象，或跨 goroutine 乱传，会导致内存错乱或 panic。它的设计假设是：单个 goroutine 自己 Get → 使用 → Put，不共享、不传递。
典型误用场景：在 HTTP middleware 中 Get 一个 ctx.Value 里塞的 buffer，然后在 handler 子 goroutine 里 Put —— 这违反了所有权约定。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- Get 和 Put 必须在同一个 goroutine 内完成（尤其注意 go func() { ... } 闭包中隐式跨 goroutine）
- Put 前务必重置所有可变字段，例如
b := pool.Get().(*bytes.Buffer); b.Reset(); defer pool.Put(b) - 避免在 defer 中无条件 Put：如果 Get 返回的是 New 创建的新对象，而你又在 defer 里 Put，等于把刚建的对象立刻丢进池子——下次 Get 可能拿到未初始化的“新”对象
New 字段不是构造函数，而是兜底工厂
sync.Pool.New 只在 Get 池空时调用，且不保证线程安全——多个 goroutine 同时触发时，可能并发调用多次。它只是“懒加载”，不是初始化入口。
错误写法：New: func() interface{} { return &MyStruct{mu: &sync.RWMutex{}} }，其中 mu 是指针，复用后未重置，导致并发读写 panic。
- New 返回的对象也必须满足“可复用”前提：要么字段全为零值，要么内部已做 reset（如
new(bytes.Buffer)是安全的） - 别在 New 里做资源申请（如
os.Open），因为 Pool 不负责释放，也没法知道何时该关 - 如果 New 返回指针，确保其指向的内存不依赖外部状态（比如不能引用当前 goroutine 的栈变量）
性能收益要看 p99 分配压测，不是本地 benchmark
本地跑 go test -bench 很容易得出“用了 Pool 快 3 倍”的假结论，但真实服务中，Pool 的竞争开销（尤其是高并发 Get/Put）可能抵消甚至超过内存分配节省。Go 1.22+ 的 mcache 优化也让小对象分配更快了。
验证方式：用 pprof 看 runtime.mallocgc 占比是否显著下降，同时观察 GOMAXPROCS=1 vs =N 下吞吐变化——如果 N 越大性能越差，大概率是 Pool 锁争用成了瓶颈。
- 优先用
go tool trace查看 “Goroutine profile” 和 “Heap profile”，确认对象分配热点真在你想优化的位置 - 测试时关闭 GC（
GOGC=off）会掩盖 Pool 的真实 GC 缓解效果，要开默认 GC - Pool 的 size 效果不随数量线性增长：100 个对象的 Pool 和 1000 个，实际命中率可能差不多，但后者占更多内存
最常被忽略的一点：Pool 的对象不会被 GC 标记为“可回收”，只要还在池里，就一直算活跃内存——哪怕你 Put 了但从不再 Get，它也会撑大 RSS 直到下次 GC 扫描清理。所以别把它当通用缓存使。
