热路径结构体复用必须用sync.Pool且Reset需幂等清零，因高频new导致GC压力与内存碎片；须满足字段可清零、无运行时资源、不逃逸三原则，Get/Put须同goroutine成对执行。
热路径结构体复用必须用 sync.Pool，但直接套用会出错——关键不在“放进去”，而在“拿出来之后怎么清干净”。
为什么热路径里结构体不能每次都 new
HTTP handler、gRPC 方法、消息解析循环这类每秒成千上万次执行的代码段，就是热路径。每次调用都 new(MyStruct) 会导致：
- 堆分配激增，触发高频 GC（尤其在 QPS > 3000 时，STW 时间可能从 1ms 跳到 50ms+）
- 内存碎片化，
runtime.mcache压力上升，间接拖慢其他 goroutine 分配 - 哪怕结构体只有几个字段，百万次/秒的分配也吃不消
什么样的结构体能进 Pool：三看原则
不是所有结构体都适合。必须同时满足：
-
字段全为值类型或可幂等清零的引用类型：比如
Data []byte可用data = data[:0]，但Cache map[string]int必须clear(cache)或cache = make(map[string]int) -
不含未导出状态或运行时绑定资源：禁止含
*http.Request、context.Context、sync.Mutex字段；带io.ReadCloser的必须在Reset()里Close() - 不逃逸到长生命周期作用域：不能被闭包捕获、不能塞进全局 map、不能传给异步 goroutine 后再 Put
Get/Put 必须成对且在同 goroutine 内完成
常见错误是把对象塞进中间件上下文，然后在 handler 里取出来 Put——这违反了 sync.Pool 的 per-P 设计，大概率走 slow path 甚至 panic。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 正确姿势：handler 入口第一行
obj := pool.Get().(*MyStruct)，紧接着obj.Reset() - Put 时机必须是响应已写出、所有子 goroutine 已退出、对象不再被任何栈帧引用之后
- 别用
defer pool.Put(obj)：panic 或提前 return 会让 defer 不执行，对象永久丢失 - 稳妥写法：
func handle(c *gin.Context) { buf := bufPool.Get().(*bytes.Buffer) defer buf.Reset() // 注意：这里是 Reset，不是 Put // ... 处理逻辑 c.JSON(200, data) bufPool.Put(buf) // 显式放回，在确定出口处 }
Reset 方法怎么写才安全
New 函数只兜底，真正决定复用是否安全的是 Reset()。它必须幂等、无副作用、覆盖所有可变字段。
-
bytes.Buffer：调buf.Reset()（清空buf.b长度，保留 cap） - 自定义结构体：
func (s *Packet) Reset() { s.ID = 0 s.Code = 0 s.Data = s.Data[:0] // 不是 s.Data = nil s.Err = nil clear(s.Headers) // Go 1.21+，替代 for range delete } - 含 map 字段：
clear(m)或for k := range m { delete(m, k) }，不能留nil引用导致后续 panic - 禁止在
Reset()里做 I/O、锁操作、或调用外部函数
最常被忽略的一点：GC 会在任意时刻清空整个池，所以 Reset() 不仅要防脏数据，还要防 nil pointer dereference——比如 s.Cache 是指针字段，Reset() 里得设为 nil 或重新 make，否则下次 Get 到的可能是已被 GC 回收的内存地址。
