如何在 Go 中编写内存友好的高性能代码

先说个判断：八成 Go 代码的性能瓶颈，根源就在内存分配上。这不是说 GC 不够快，而是你让太多对象逃逸到堆上、反复申请又丢弃、没复用还乱扩容。今天直接聊怎么做。

怎样快速定位逃逸点？用 go build -gcflags="-m=2"

编译器的逃逸分析是唯一可信的依据，靠猜是行不通的。加上 -m=2 这个参数，每一行变量是否逃逸、为什么逃逸，都一目了然。

• 当某行出现 escapes to heap，意味着该变量一定被分配到堆上，必须重点排查
• 常见触发场景：&struct{} 取地址、传指针进函数、闭包捕获局部变量、返回局部变量地址、切片/映射底层数据被外部引用
• 一个容易被忽略的细节：make([]int, 0, N) 在 N ≤ 8192 时通常不逃逸；超过这个数大概率会逃逸（Go 1.22 默认栈上限约 64KB）

结构体传值还是传指针？别无脑传 *T

传指针不等于更快，它常常是逃逸的元凶。只有当结构体较大时——比如超过 64 字节——且函数内部不取地址、不返回指针，才需要考虑传值。

• 小结构体（如 type User {ID int64; Name string}）直接传值，编译器可以内联加栈分配
• 一旦函数签名写成 func f(*User)，哪怕函数内部只读字段，&User{} 也会立刻逃逸到堆上
• 真实场景中，把接收者从 *User 改成 User，配合 -gcflags="-m" 验证，往往能砍掉 30% 以上的堆分配

高频临时对象必须走 sync.Pool

sync.Pool 不是锦上添花的优化，而是高并发服务的内存安全带。Buffer、JSON 解析器、proto 消息实例这些高频对象都适合用它来管理。

• 池中的对象可能被 GC 回收，所以每次 Get() 之后必须 Reset() 或显式初始化，否则脏数据会引发隐蔽的 bug
• 不要池化长期存活的对象，比如 DB 连接、全局配置——那反而会阻碍 GC 正常工作
• 参考用法：var bufPool = sync.Pool{New: func() interface{} { return new(bytes.Buffer) }}，获取后调 buf.Reset()，用完 bufPool.Put(buf)

切片和字符串拼接：预分配 + strings.Builder

动态扩容和字符串拼接是隐形的内存杀手，尤其藏在循环里时杀伤力巨大。

• 已知长度就预先 make([]T, 0, N)，避免 append 触发多次底层数组拷贝
• result += s 在循环中每轮都做一次 malloc 新字符串；换成 strings.Builder，内部用切片预扩容，分配次数趋近于 1
• 注意：builder.String() 返回的是新字符串，builder 本身可以复用；不要在 builder 上直接判断 len()，它不反映最终字符串长度

最容易忽略的一点：逃逸分析结果受 Go 版本和构建环境影响很大。同一段代码在本地 go run 和 go build -ldflags="-s -w" 下表现可能完全不同。上线之前，务必用生产级构建参数跑一次 -gcflags="-m=2"，这才能看到真正的内存分配图景。