sync.pool 仅在对象高频分配、短生命周期且可安全重置时有效；get 后必须手动 reset，put 前须确保无引用，new 仅兜底创建全新对象，误用会导致内存滞留、脏数据或 use-after-free。
sync.Pool 能缓解 GC 压力，但只在对象满足「高频分配 + 短生命周期 + 可安全重置」时才有效；用错反而导致内存滞留、脏数据、use-after-free 甚至 STW 时间变长。
Get 后必须手动 Reset，不能依赖 New 或默认状态
sync.Pool 不会自动清理对象内容。Get 返回的 *bytes.Buffer 可能还带着上一次写入的字节；[]byte 切片的 len 可能非零、底层数组残留旧数据；自定义结构体字段若未重置，逻辑状态直接穿透复用。
-
buf.Reset()是必须调用的——它清长度、保留底层数组，这才是复用价值所在 - slice 字段重置写法是
s.Data = s.Data[:0]，不是s.Data = nil（后者丢弃底层数组） - map 字段需先
for k := range m { delete(m, k) }或用mapclear（Go 1.21+），不能只赋nil - New 函数不参与每次 Get 的初始化，它只在池空时兜底调用一次，不能当 reset 钩子用
Put 前必须确认对象已彻底脱离所有 goroutine 作用域
sync.Pool.Put 不做任何引用检查，也不等待。一旦 Put 进去，该对象可能下一毫秒就被其他 goroutine 的 Get 拿走——此时若原 goroutine 还在读写它，就是典型的 use-after-free。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 禁止在
defer pool.Put(x)中无条件归还：比如启动了异步 callback、写入 channel、或闭包捕获了x，都极危险 - 安全时机是业务逻辑完全结束之后：没发 channel、没启 goroutine、没作为返回值传出、也没被任何闭包引用
- HTTP handler 中，Put 必须放在所有中间件和业务逻辑执行完毕后，不能放在 defer 里就完事
- 含指针字段（如
*http.Request）的结构体，Put 前必须显式置nil，否则引用滞留会阻止 GC 回收关联内存
New 函数必须每次返回全新对象，且不能有副作用
New 是兜底工厂，不是初始化入口。它被调用的唯一条件是当前所有本地池 + victim cache 都为空，且调用时机不可控——可能在任意 goroutine 中触发。
- 错误写法：
var globalBuf bytes.Buffer; return &globalBuf→ 所有 goroutine 共享同一实例，必然竞态 - 正确写法：
return &bytes.Buffer{}或return &MyStruct{Data: make([]byte, 0, 1024)}→ 每次分配新内存 - 禁止在 New 里做耗时操作（如
os.Open、http.Get），它会阻塞 Get 路径 - 若对象需预分配容量（如 4KB 底层数组），必须在 New 里完成；Get 后再扩容就失去复用意义
验证是否真正在降低 GC 压力，而不是囤积对象
写了 sync.Pool 不等于性能提升。Pool 没有容量限制，每个 P 维护本地池 + victim cache，流量波峰过后闲置对象不会立刻释放，要等下一次 GC 才清空——这反而抬高堆占用、拉长 STW。
- 监控
runtime.ReadMemStats中Mallocs - Frees差值：长期不收敛说明 Pool 在囤积对象 - 用
go tool pprof http://localhost:6060/debug/pprof/heap?debug=1对比allocs/op是否下降 - 开启
GODEBUG=gctrace=1观察 GC 频次和 pause 时间变化 - Go 1.21+ 注意：开启
runtime.SetMutexProfileFraction或runtime.SetBlockProfileRate时，pprof 采样与 Pool 存在已知冲突，可能导致指标失真
最易被忽略的一点：sync.Pool 不是“对象生命周期管理器”，它不跟踪引用、不判断状态、不保证复用。你写的每一行 Reset、每一次 Put 时机判断、每一个 New 返回值，都在替它做本该由你负责的内存契约。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
