sync.pool 不是享元模式，而是 go 运行时内存复用机制；它只负责对象的借还，不管理状态共享与分离，误用会导致状态污染或并发 panic。
Go 里 sync.Pool 不是享元模式，别混用
享元模式（Flyweight）是面向对象设计模式，核心是共享内部状态、分离外部状态；而 sync.Pool 是 Go 运行时提供的内存复用机制，只管“借”和“还”，不关心对象语义。强行把业务对象塞进 sync.Pool 当享元用，会导致状态污染或并发 panic。
常见错误现象：sync.Pool.Get() 返回的对象残留上次使用时的字段值，比如一个 RequestCtx 结构体里 userID 字段没重置，下游直接误用；或者多个 goroutine 同时修改池中对象的非线程安全字段。
- 用
sync.Pool只适合无状态、可重置、构造开销大的对象，比如[]byte、bytes.Buffer、自定义结构体但带明确的Reset()方法 - 若真需要享元语义（如共享配置、只读模板），应手动管理共享实例，用包级变量 +
sync.Once初始化，而不是依赖sync.Pool -
sync.Pool.New函数仅在 Get 无可用对象时调用，不能假设它每次都会执行；不要在里面做有副作用的操作（如打日志、发请求）
预热 sync.Pool 必须在程序启动后、流量进来前完成
Go 的 sync.Pool 没有内置预热接口，首次 Get() 会触发 New，如果这时刚好是流量高峰，延迟就上去了。预热不是“多调几次 Put”，而是让池里提前存好一批干净对象。
使用场景：HTTP 服务启动后、gRPC Server 开始 Accept 前、或 worker pool 初始化阶段。
立即学习“go语言免费学习笔记（深入）”；
- 预热代码必须放在
main()或初始化函数中，且在http.ListenAndServe之前执行 - 预热数量不宜过大，一般取预期峰值并发的 10%～20%，比如预计 QPS 5000、平均处理耗时 20ms，则活跃 goroutine 约 100，预热 10～20 个对象足够
- 预热后记得
Put回去，否则对象被丢弃；示例：for i := 0; i < 16; i++ { pool.Put(newBuffer()) }
sync.Pool 在 GC 时会被清空，别指望跨轮次复用
每次 GC 触发，sync.Pool 中所有未被引用的对象都会被回收——这是设计使然，不是 bug。这意味着你不能靠它长期缓存连接、句柄或带资源的对象。
性能影响：频繁 GC（如内存分配激增）会让池失效，退化为每次都走 New；兼容性上，Go 1.13+ 对 Pool 清理策略微调过，但“GC 清空”行为始终没变。
- 别把
*sql.DB、*http.Client、文件描述符等放进去；它们该用连接池（如database/sql自带的）或长生命周期对象管理 - 如果对象含指针或大块内存，注意
Reset()方法要归零指针字段（避免 GC 无法回收底层数据），例如b.data = b.data[:0]而不是只清长度 - 可通过
runtime.ReadMemStats观察PauseTotalNs和NumGC，判断是否因 GC 频繁导致 Pool 效果打折
高并发下 sync.Pool 的实际收益取决于对象大小和分配频率
小对象（sync.Pool 帮不上忙；超大对象（>32KB）走操作系统 mmap，Pool 也难优化。真正受益的是中等尺寸（几百字节到几 KB）、高频分配/释放的对象。
容易踩的坑：用 pprof 发现 sync.Pool 的 Get/Put 占比很高，但整体分配量没降——说明对象没被复用，可能因为 Reset() 漏了字段，或 New 返回了新地址但逻辑上还是旧状态。
- 验证是否生效：用
go tool pprof -alloc_space对比开启/关闭 Pool 的堆分配总量；关注 “inuse_space” 而非 “allocs” - 对象字段尽量用值类型；含 slice 时，优先复用底层数组（
s = s[:0]），而非重新 make - 不要为每个 handler 单独建 Pool，全局一个即可；竞争在现代 Go 版本中已大幅优化，过度拆分反而增加管理成本
最常被忽略的一点：Pool 对象的 Reset() 方法必须幂等且无锁。一旦这里加了 mutex 或依赖外部状态，整个池就变成性能瓶颈。写完一定要跑 race detector。
