使用-benchmem可查看基准测试中每次操作的内存分配字节数（B/op）和分配次数（allocs/op），重点关注后者以减少堆上逃逸；避免字符串与字节切片互转引发的额外分配，优先复用sync.Pool或使用unsafe包（仅限只读可控场景）；通过逃逸分析优化变量驻留位置，并预分配slice/map容量以降低扩容开销。
直接用`-benchmem`看内存分配
运行基准测试时加上 -benchmem 参数，能立刻看到每次操作的平均内存分配字节数（B/op）和分配次数（allocs/op）。比如：
go test -bench=Sum -benchmem
输出类似：BenchmarkSum-8 1000000 1245 ns/op 16 B/op 2 allocs/op。重点关注后两项——越小越好，尤其是 allocs/op，它直接反映逃逸到堆上的对象数量。
避免不必要的切片/字符串转换
在字符串处理中，string([]byte) 和 []byte(string) 都会触发新内存分配。如果只是临时读取，优先用 unsafe.String（Go 1.20+）或 unsafe.Slice 绕过拷贝，但要注意仅限**只读且生命周期可控**的场景。更安全的做法是复用 sync.Pool 管理临时切片：
立即学习“go语言免费学习笔记（深入）”；
- 定义一个
var bufPool = sync.Pool{New: func() any { return make([]byte, 0, 256) }} - 测试中用
b := bufPool.Get().([]byte)获取，用完bufPool.Put(b[:0]) - 注意：Put 前要截断长度（
[:0]），否则下次 Get 可能拿到脏数据
让小对象留在栈上，减少逃逸
Go 编译器会自动做逃逸分析，但某些写法会“逼”变量上堆。常见诱因包括：
- 把局部变量地址返回（如
return &x） - 传入接口类型参数（如
fmt.Println(x)中 x 是非接口值，但底层可能触发分配） - 闭包捕获大变量（哪怕只读，也可能导致整个结构体逃逸）
用 go tool compile -gcflags="-m -l" 查看逃逸详情。加 -l 禁用内联，让分析更清晰。目标是让高频路径上的小结构体（如 type Point struct{X,Y int}）全程驻留栈中。
预分配容量，避免 slice 自动扩容
slice 的 append 在容量不足时会重新分配底层数组，产生额外 allocs/op。基准测试里尤其明显。例如构建固定长度结果：
- ❌ 错误：
res := []int{}→ 后续循环append(res, x) - ✅ 正确：
res := make([]int, 0, n)，其中n是已知最终长度 - 若长度不确定但有上限，也建议
make([]T, 0, maxEstimate)，比默认 0 容量更稳
对 map 也同理：make(map[K]V, n) 预分配桶，减少 rehash 次数。
基本上就这些。内存优化不是一味追求零分配，而是聚焦高频路径、压低 allocs/op、控制对象生命周期。跑一遍 -benchmem，再结合逃逸分析，问题通常一眼可见。
