对象复用在Go中能提升性能，但仅限高频创建/销毁的小对象（如bytes.Buffer），通过sync.Pool降低分配压力；需重置状态、避免指针字段，并非万能缓存。
对象复用在 Go 中是否真能提升性能？
多数情况下，能，但只在特定场景下显著——尤其是高频创建/销毁小对象（如 sync.Pool 管理的临时缓冲、网络请求中的 bytes.Buffer 或自定义结构体）。Go 的 GC 虽然高效，但频繁分配仍会触发额外的写屏障、内存扫描和堆增长，复用可绕过这部分开销。
sync.Pool 是最常用也最容易误用的方式
sync.Pool 不是万能缓存，它不保证对象一定被复用，也不保证存活时间；GC 会清空所有未被引用的 Pool 实例。它的价值在于「降低短生命周期对象的分配压力」，而非「减少内存占用」。
- 必须用
New字段提供构造函数，否则Get()可能返回nil - 避免把含指针或大字段的对象放进
Pool——可能延长其他对象的生命周期，反而阻碍 GC - 不要在
Put()前修改对象内部状态（如未重置切片底层数组），否则下次Get()拿到的是脏数据
var bufPool = sync.Pool{
New: func() interface{} {
return new(bytes.Buffer)
},
}
// 正确用法：每次 Get 后重置
buf := bufPool.Get().(*bytes.Buffer)
buf.Reset() // 必须调用，否则残留旧内容
// ... use buf ...
bufPool.Put(buf)
对比基准：alloc vs pool 的典型耗时差异
在压测中，对单次处理需创建 10 个 struct{ a, b int } 的场景，sync.Pool 复用可将分配相关耗时从 ~25ns 降至 ~8ns（实测于 Go 1.22 / Linux x86_64）。但若对象本身较大（> 2KB）或生命周期超过一次请求，则复用收益急剧下降，甚至因同步开销反超直接分配。
- 小对象（ 1k）、短生命周期（函数内创建即弃）——复用收益明显
- 含
map、slice或指针字段的对象——务必在Put()前清理（如buf.Reset()、slice = slice[:0]） - 跨 goroutine 长期持有对象——别用
sync.Pool，改用对象池 + 手动管理或直接 new
比 Pool 更轻量的复用：复用参数接收器或闭包变量
某些场景下，根本不需要 sync.Pool。比如 HTTP handler 中反复解析 JSON，可复用一个 json.Decoder 并设置 UseNumber()；或者在循环中复用一个局部 strings.Builder，比每次都 new(strings.Builder) 更直接有效。
立即学习“go语言免费学习笔记（深入）”；
- HTTP handler 内复用
json.Decoder时，注意它不是并发安全的，需 per-request 实例或加锁 - 闭包中捕获可复用对象（如预分配的
[]byte）比全局sync.Pool更快，因为无原子操作开销 - 编译器无法逃逸分析出的栈对象，强制复用反而可能导致逃逸到堆，得不偿失——先跑
go build -gcflags="-m"确认逃逸行为
