sync.pool适合复用创建开销大、生命周期短、可安全重置的对象，如bytes.buffer、sync.waitgroup（需清空）、自定义解析器；new须返回干净实例，reset须显式清零字段，put/get需及时且同goroutine执行。
sync.Pool 适合复用什么类型对象
它只适合复用「创建开销大、生命周期短、可被安全重置」的对象，比如 *bytes.Buffer、*sync.WaitGroup（需清空）、自定义的解析器结构体。不是所有对象都值得放进去——如果构造函数很快（如 struct{}），或者对象带不可清除的外部状态（如已注册回调、持有文件描述符），放进 sync.Pool 反而增加 GC 压力和逻辑混乱。
- 常见误用：把含指针字段但不清零的结构体直接 Put 进去，下次 Get 到的是脏数据
- 典型适用场景：HTTP handler 中临时分配的 JSON 解析缓冲区、日志格式化器、protobuf 消息实例
- 注意
sync.Pool不保证对象一定被复用，GC 时会清空整个池，所以不能依赖“一定命中”
New 字段必须返回可复用的干净实例
sync.Pool 的 New 函数不是初始化钩子，而是兜底工厂——当池为空时才调用。它必须每次返回一个「状态干净、可立即使用」的对象。如果你在 New 里做一次性初始化（比如打开文件、启动 goroutine），就踩坑了。
- 错误写法：
New: func() interface{} { return &MyParser{conn: dial()}}—— 每次 New 都新建连接 - 正确写法：
New: func() interface{} { return &MyParser{}}，然后在 Get 后手动调用p.Reset() - Reset 方法必须显式清空所有可变字段，尤其注意切片字段要用
s = s[:0]而非s = nil（后者会丢掉底层数组）
Put/Get 顺序和时机决定实际效果
对象只有在「明确不再需要后立刻 Put」，且「Get 后尽快 Reset」，才能真正降低分配压力。延迟 Put 或忘记 Reset，等于白用 sync.Pool。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 别在 defer 里 Put：handler 中 defer Put 可能拖到请求结束，期间池被 GC 清空，失去复用意义
- Get 后第一件事应该是 Reset，而不是先读字段再判断要不要 Reset
- 避免跨 goroutine 传递 Pool 对象：Put 和 Get 最好在同一个 goroutine 完成，否则可能触发锁竞争，反而比 new 慢
- 实测发现：高并发下，如果对象平均存活时间 sync.Pool 复用率明显下降，此时不如直接 new
怎么验证 sync.Pool 真起作用了
别靠直觉，看 go tool pprof 的堆分配火焰图，或对比 GODEBUG=gctrace=1 下的 allocs/op。关键指标是 gc N @X.Xs X MB/s 中的 MB/s 是否下降，以及 benchstat 显示的 B/op 是否减少。
- 加一行
runtime.ReadMemStats(&m); fmt.Println(m.Mallocs)在压测前后，看 malloc 次数是否显著降低 - 注意：
sync.Pool本身不减少 GC 次数，只减少单次 GC 扫描的对象数量；如果观察到 GC 频率上升，说明池里塞了不该塞的大对象 - 线上慎用未充分压测的 Pool 实现——某些情况下，Pool 内部的 lock contention 会让吞吐量反降 5%~10%
真正难的不是写对 sync.Pool 的 API 调用，而是判断哪些字段该 Reset、Reset 到哪一层、以及 Pool 生命周期和业务请求生命周期是否对齐。这些地方没想清楚，代码跑得越快，问题藏得越深。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
