高频计算模块易吃内存是因为频繁分配导致TotalAlloc飙升、GC加剧；应使用sync.Pool复用对象、预分配slice容量、避免变量逃逸。
为什么高频计算模块容易吃内存
高频计算模块常伴随大量中间数据生成，比如反复 make([]byte, n)、append 扩容、闭包捕获变量逃逸到堆——这些操作在单次调用中不明显，但每秒几千次就会快速推高 runtime.MemStats.TotalAlloc，触发更频繁的 GC，甚至出现周期性停顿。关键不是“用了多少内存”，而是“分配了多少次”。
用 sync.Pool 复用缓冲区和结构体
对固定大小或可复用的临时对象（如 []byte、bytes.Buffer、自定义计算上下文），sync.Pool 是最直接有效的手段。它绕过 GC，让对象在 goroutine 间安全复用。
-
New函数必须返回**零值已清空**的对象，不能带残留状态；否则并发下会出错 - 池中对象可能被 GC 清理，所以每次
Get()后要检查是否为 nil，必要时重新初始化 - 不要把大对象（> 16KB）放进池——它们不走 mcache，复用收益低，还可能拖慢 GC 扫描
var calcBufPool = sync.Pool{
New: func() interface{} {
return make([]byte, 0, 1024)
},
}
func doCalc(input []byte) []byte {
buf := calcBufPool.Get().([]byte)
defer calcBufPool.Put(buf[:0]) // 归还前截断长度，保留底层数组
// ……计算逻辑，往 buf 写结果
return append(buf, input...) // 注意：返回值若需长期持有，应 copy
}
预分配 slice 容量并避免隐式扩容
高频循环中 append 不指定初始容量，会导致指数级扩容（2→4→8→16…），每次扩容都触发底层数组拷贝。即使最终长度已知，漏掉 make 就等于主动制造内存压力。
- 输入长度已知时，直接
make([]T, 0, len(input)) - 输出长度可估算（如哈希计算固定 32 字节），就按最大可能值预分配
- 避免在循环内重复调用
len()或cap()判断——编译器未必能优化，且易误判扩容时机
错误写法：result := []int{}; for _, x := range data { result = append(result, x*2) }
正确写法：result := make([]int, 0, len(data)); for _, x := range data { result = append(result, x*2) }
检查逃逸并推动变量留在栈上
高频函数里一个 return &struct{...} 或闭包引用局部变量，会让整个结构体逃逸到堆——哪怕只多分配几个字节，乘以 QPS 就是 GB 级额外开销。
立即学习“go语言免费学习笔记（深入）”；
- 用
go build -gcflags="-m" calc.go查看关键函数，重点找escapes to heap提示 - 小结构体（
≤ 128B）尽量传值而非指针，减少取地址行为 - 避免在循环内创建新闭包，尤其当闭包捕获了循环变量（
for i := range xs { go func(){ use(i) }() }）——i 会逃逸
真正难处理的是：某些计算逻辑天然需要堆分配（如递归深度不确定、结果 size 动态变化）。这时别硬压栈，优先用 sync.Pool + 预估上限做缓冲池，比放任逃逸更可控。
