能，但需满足结构体≥1KB、含slice/map/指针且逃逸到堆；否则Pool开销反超收益，且Get后必须重置字段、New中禁止副作用、Put须确保对象不再被任何goroutine持有。
sync.Pool复用大结构体真能减GC吗
能，但前提是“大”得有说服力——通常指单个实例 > 1kb、含多个 slice/map/指针字段、且每次分配都触发堆分配。小于这个量级的结构体，sync.pool 的原子操作和本地池查找开销反而可能超过分配成本。
常见错误现象：runtime.ReadMemStats 显示 Mallocs 下降了，但 HeapAlloc 持续上涨，GC 周期没变短。根本原因不是没复用，而是 Put 进去的对象没重置，导致业务层逻辑反复 alloc 新内存（比如 slice append 时扩容出新底层数组）。
- Go 1.19+ 对大于 32KB 的对象会绕过 MCache 直接走 mheap，复用率断崖下跌，慎用
- 结构体里有指向长期存活对象的指针（如全局配置、缓存 map），Put 后会把那些对象“钉”在内存里，GC 无法回收
- 用
go tool compile -gcflags="-m -l"确认该结构体确实逃逸到堆 —— 如果没逃逸，栈分配本身就不进 GC，池化纯属干扰
Get后必须重置哪些字段
sync.Pool.Get() 返回的不是新对象，是上一轮用过的“旧货”。不重置就直接用，等于拿别人擦过嘴的纸巾擦自己脸。
典型需手动清理的字段类型：
-
[]byte字段：必须用s.Data = s.Data[:0]（清长度，不 realloc）；不能只赋nil，否则下次append仍可能复用旧底层数组 -
map[string]interface{}字段：用mapclear(s.Cache)（Go 1.21+）或s.Cache = nil后再make，避免残留键值干扰逻辑 - 数值字段（
int,bool,time.Time）：显式置零，别依赖 struct 零值 —— 上次用完可能改过它们 - 指针字段（如
*http.Request）：必须设为nil，否则 GC 会因该指针继续追踪整个请求树
New函数里不能写什么
New 是兜底工厂，不是初始化钩子。它只在池空时调用，且不保证每次 Get 都触发。写错会导致多 goroutine 共用同一块内存。
立即学习“go语言免费学习笔记（深入）”；
- 禁止返回全局变量地址：
return &globalBuf→ 所有 P 共享一个实例，竞态高发 - 禁止做副作用操作：
os.Open、http.Get、加锁、访问未同步的map→ New 可能在任意 goroutine 中执行，且可能被 GC 触发多次 - 禁止返回未初始化的指针：
return new(MyStruct)→ 字段全为零值，但内部[]byte的cap是 0，后续append必然扩容，失去复用意义 - 正确写法：
return &MyStruct{Data: make([]byte, 0, 4096), Cache: make(map[string]int)}
Put时机比你想的更关键
sync.Pool.Put() 不检测引用，也不等你。一旦放进去，下一毫秒就可能被别的 goroutine 拿走。此时若原 goroutine 还在读写它，就是 use-after-free。
- 别无脑
defer pool.Put(x)：如果函数启动了 goroutine 并传入x，或把x写入 channel，或作为闭包变量捕获，defer就是定时炸弹 - HTTP handler 中，Put 应放在
w.Write()完成之后、函数return之前，而非开头 - 对
io.Copy(dst, src)类场景，Put 必须等 copy 完全结束才调用，不能靠 defer - 最安全判断：该对象不再被任何 goroutine 持有、没传出函数作用域、没注册回调、没进 channel
真正难的不是写 Pool，是确认对象生命周期是否真的“短”——很多你以为的临时结构体，其实因为一次异步调用或一次 map 存储，就悄悄变成了长生命周期对象。这时候加 sync.Pool，等于给 GC 堆里埋雷。
