sync.Pool 并非 GC 优化开关，仅在高频（>10k/s）分配短生命周期小对象时可能有效；Get 可能返回 nil，须显式检查；Put 前必须 Reset，避免脏数据与内存泄漏；大对象（>32KB）或长生命周期对象禁用；对象不可跨 goroutine 传递，需及时 Put。
sync.pool 不是 gc 优化开关，用错反而让 gc 更忙、heapalloc 持续上涨。 它只在你明确观测到某类小对象（如 bytes.buffer、[]byte）分配频次极高（>10k/s）、且生命周期极短时才可能有效；否则大概率白忙一场，甚至拖慢整体吞吐。
Get 返回 nil 是常态，不是 bug
GC 触发时会清空所有池中对象，Get() 可能返回 nil —— 这是设计使然，不是异常。很多人直接解引用导致 panic：buf := pool.Get().(*bytes.Buffer)，一旦 Get() 返回 nil 就崩。
- 必须显式检查：
v := pool.Get(); if v == nil { v = new(bytes.Buffer) } -
New字段只是兜底工厂，只在Get()找不到可用对象时调用一次，不保证每次都执行 - 不要在
New里做耗时操作（如os.Open），它可能在任意 goroutine 中被调用
Put 前不 Reset = 脏数据 + 隐形内存泄漏
Pool 不做任何状态清理。Put() 进去一个没重置的 bytes.Buffer，下次 Get() 拿到的可能是上次写满的缓冲区，len(buf.Bytes()) 非零、内容残留；更糟的是含指针字段的结构体，比如字段是 map[string]int 或 *http.Request，未清零会导致 GC 无法回收其引用的整块内存。
- 必须在
Put()前调用Reset()（如buf.Reset()）或手动清空：slice = slice[:0]、ptr = nil、mapField = nil - 若结构体无
Reset()方法，建议封装并实现它，避免每次使用都重复写重置逻辑 - 别依赖
New返回“干净”对象：如果字段含指针或 map，&T{}不等于“已初始化”，需显式赋值或置nil
对象大小和生命周期决定它到底省不省内存
Go 1.19+ 默认将 >32KB 的对象绕过本地 mcache，直接走堆分配；放进 Pool 的大对象基本不会被复用，还干扰 GC 扫描节奏。同样，生命周期长的对象（如被闭包捕获、或随 HTTP request context 存活整个请求链路）一旦进池，可能滞留多轮 GC，变成“伪内存泄漏”。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 适合：HTTP handler 中临时
bytes.Buffer、JSON 解析用的map[string]interface{}、固定大小的struct{ ID uint64; Code int } - 禁用：含
chan/map/ 外部资源句柄的结构体、单个实例 >32KB、生命周期超过单次 handler 执行时间的对象 - 验证是否真有效：压测时对比
go tool pprof --alloc_space（看分配量降没降）和--inuse_objects（看 inuse heap 是否反升）
最常被忽略的一点：Pool 对象归属必须严格限定在单个 goroutine 内，不能跨 goroutine 传递指针；Put 的时机要“用完即放”，而不是等函数结束才 defer Put() —— 后者会让对象卡在池里，其他 goroutine 拿不到，复用率归零。
立即学习“go语言免费学习笔记（深入）”；
