sync.Pool在GC时分两轮清理：首次GC将本地池对象移至victim缓存，二次GC才彻底丢弃，故对象最多存活至“下下一次GC”前；victim只读、不参与fast path，仅缓解复用率骤降，但不重置状态，使用前必须手动Reset。
sync.pool 在 gc 时不会立即清空对象，而是分两轮处理：第一次 gc 把本地池对象移到 victim 缓存，第二次 gc 才真正丢弃 —— 所以对象最多活到“下下一次 gc”前，但具体哪次被删，你无法控制。
GC 清理不是全量清空，而是分阶段迁移
每次 GC 触发时，runtime 会执行 poolCleanup，但它不直接释放所有对象：
- 每个 P 的本地私有池（
private）和共享队列（shared）内容被清空，对象直接失去引用，等待 GC 回收 - 当前全局池（
p.local）被整体“降级”为 victim 缓存（p.victim），而新分配的p.local初始化为空 - 原来的 victim 缓存（如果存在）则被彻底丢弃 —— 这就是“两次 GC 才清理”的来源
这意味着：你在第 N 次 GC 前 Put 进去的对象，可能在第 N+1 次 GC 后还留在 victim 中，直到第 N+2 次 GC 才消失。但如果你的 goroutine 在第 N+1 次 GC 后立刻调用 Get()，它仍可能从 victim 里捞出那个对象。
Victim 缓存不是“备用池”，而是 GC 协同机制
victim 不对外暴露，也不参与常规 Get() 的 fast path；它的唯一作用是缓解 GC 突刺性回收带来的复用率骤降：
-
Get()走完本地 private → local shared → 其他 P 的 shared 后，才查victim -
victim是只读的：它不接受Put()，也不会被任何 goroutine 主动填充 - 它的存在让对象多了一次“苟延残喘”的机会，但代价是延长了内存驻留时间 —— 对大对象或带指针字段的结构体，可能拖慢整体 GC 效率
比如你 Put 了一个含 *bytes.Buffer 字段的结构体，没重置指针，它进入 victim 后仍持有对底层字节数组的引用，会阻止那块内存被归还 OS。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
为什么不能靠 Victim 缓存做状态兜底
很多人误以为 “victim 里对象更‘新’，字段应该更干净”，这是危险错觉：
- victim 中的对象和原池中的一样，字段值完全随机 —— 它只是没被 GC 扫描掉，不代表被自动重置
-
New函数绝不会在 victim 命中时触发，所以你拿不到兜底初始化逻辑 - 哪怕对象刚从 victim 返回，你也必须像对待任何
Get()结果一样，手动调用Reset()或清零关键字段
典型反例：buf := pool.Get().(*bytes.Buffer); buf.WriteString("hello") —— 如果没 buf.Reset() 就直接 Put()，下次从 victim 拿出来的 buf 里可能还残留上次的 "hello\000\000..."，导致解析错误或 panic。
真正关键的不是 victim 存多久，而是你是否在每次 Get() 后、使用前就重置状态 —— GC 和 victim 都不关心你的业务逻辑，它们只管内存能不能回收。
