sync.Pool复用对象、预设切片容量、避免逃逸可减少70%+高频GC；需重置状态、判空兜底、禁存含指针复杂结构，并优先栈分配。
sync.Pool 复用对象、减少堆分配、预设切片容量——这三招能直接砍掉 70%+ 的高频 GC 触发，尤其在 HTTP handler 或协议解析这类短生命周期场景中效果最明显。
为什么频繁 GC 会卡住你的服务？
Go 的 GC 是并发标记清除（如 Go 1.22+ 的 STW 极短），但触发太勤仍会拖慢吞吐：每次堆增长达 GOGC 百分比（默认 100）就启动一轮扫描。高频分配 → 堆快速膨胀 → GC 频繁跑 → 协程等待 STW 或辅助标记 → 延迟毛刺。这不是“GC 慢”，而是“你喂得太勤”。
用 sync.Pool 复用缓冲区和临时结构体
适用于每次请求都 new 的对象：比如 []byte、strings.Builder、自定义的 RequestCtx。Pool 不保证复用，但能极大降低分配次数。
- 必须在
Put()前重置状态：例如buf = buf[:0]或调用sb.Reset()，否则下次 Get 可能读到脏数据 -
Get()返回interface{}，务必做类型断言或确保池中只存一种类型 - Pool 中的对象可能被任意 GC 清空，所以
Get()后要判空并兜底初始化（New 函数就是干这个的） - 别往 Pool 里塞含指针的复杂结构（如未清空的
map、持有context.Context的对象），容易污染或泄漏
var bufPool = sync.Pool{
New: func() interface{} {
return make([]byte, 0, 4096)
},
}
func handle(r io.Reader) {
buf := bufPool.Get().([]byte)
defer bufPool.Put(buf)
buf = buf[:0]
_, err := io.ReadFull(r, buf[:cap(buf)])
if err != nil {
return
}
// use buf
}
让小对象留在栈上，而不是逃逸到堆
栈分配零成本、无 GC；一旦逃逸，就变成 GC 扫描目标。用 go build -gcflags="-m -l" 看逃逸分析结果，重点关注 “moved to heap”。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 避免返回局部变量地址：
return &User{}一定逃逸；改用值返回return User{} - 闭包别捕获大变量：比如在循环里定义函数并引用整个
users []User，会导致整块切片逃逸 - 传参优先值类型：小结构体（*User；接口参数（如
fmt.Println(s)）也可能引发字符串逃逸 - 固定长度数组优先声明：
[32]byte栈分配，make([]byte, 32)默认堆分配
预分配容量，堵死切片扩容的内存浪费
每次 append 触发扩容，都要 malloc 新底层数组、memcpy 旧数据、free 旧内存——三重开销，还制造碎片。
立即学习“go语言免费学习笔记（深入）”；
- 已知长度时，用
make([]T, 0, N)显式指定 cap，比如解析 JSON 数组前拿到 size hint - 避免在循环里反复
append单个元素后取res[:]；改用索引赋值：items[i] = item - 过度预分配（如 cap=1MB）虽省扩容，但可能长期占内存不释放；按 P99 请求大小设 cap 更稳妥
- 对
map同样适用：make(map[string]int, 100)避免哈希表多次 rehash
// ❌ 每次 append 都可能扩容
var records []Record
for _, id := range ids {
records = append(records, Record{ID: id})
}
// ✅ 一次分配到位
records := make([]Record, 0, len(ids))
for i, id := range ids {
records[i] = Record{ID: id} // 直接索引赋值
}
真正难的不是记住这些技巧，而是判断哪条路径正在偷偷分配——压测时用 go tool pprof -alloc_objects 看堆分配热点，比凭感觉优化靠谱得多。 
