sync.Pool通过victim缓存机制实现“延后一拍”清理：每次GC前调用poolCleanup，将local移至victim并置local为nil，上轮victim被丢弃交由GC回收；Get只读local，victim仅过渡，不参与获取。
sync.Pool 不参与 runtime.GC 的标记-清除流程，它自己有一套独立的、与 GC 强耦合但又不重叠的清理机制。
sync.Pool 的 victim 缓存机制怎么工作
每次 GC 开始前（STW 阶段），运行时会调用 poolCleanup 函数，把当前所有 sync.Pool 实例的 local 字段挪到 victim，再把 local 置为 nil；上一轮 GC 时的 victim（即更早的 local）则被直接丢弃，交由 GC 回收。
- 这意味着：你
Put()进去的对象，**不会在本次 GC 被回收**，而是“延后一拍”——下次 GC 才真正释放 -
Get()永远只从local取，victim是只读的、仅用于过渡，不会被Get()命中 - 所以高频短连接场景下，
Get()后刚Put()，对象可能还没来得及进victim就被 GC 清掉了——不是 bug，是设计使然
runtime.GC() 对 sync.Pool 没有即时效果
手动调用 runtime.GC() 会触发一次完整 GC 周期，但它**不会提前触发 poolCleanup**；该函数只在 runtime 自动调度的 GC 前执行。也就是说：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 你在代码里写
runtime.GC()，哪怕立刻看到gc N @X.Xs日志，sync.Pool的local也不会马上清空 - 池中对象是否消失，取决于它是否已进入
victim，以及本轮 GC 是否真把它底层数组标为不可达 - 别指望靠
runtime.GC()来“强制清空池”——它既不保证命中，也不控制 victim 生命周期
Pool 对象逃逸后，GC 回收和 Pool 清理是两件事
如果 sync.Pool 里缓存的是一个 bytes.Buffer，而这个 buffer 的底层数组因为闭包捕获或返回值逃逸到了堆上，那么：
立即学习“go语言免费学习笔记（深入）”；
-
poolCleanup仍会把buffer实例本身（指针）从local移走，但底层数组还在堆上活着 - GC 是否回收该数组，取决于有没有其他变量还指向它——比如你忘了调
buf.Reset()，导致后续Put()时 buffer 内部仍持有旧数据引用 - 常见误操作：
buf := pool.Get().(*bytes.Buffer); buf.WriteString("hello"); pool.Put(buf)—— 如果没Reset()，下次Get()拿到的 buffer 里还带着上次的字符串，append 时可能扩容并再次逃逸
真正难控的不是 “Pool 什么时候清”，而是 “对象底层数组是否还在被隐式引用”。逃逸分析 + buf.Reset() + 不长期持有 dst 切片，这三者缺一不可。
