Go代码性能瓶颈八成源于内存分配不当，需用go build -gcflags="-m=2"精准定位逃逸点，避免无谓堆分配、善用sync.Pool、预分配切片、strings.Builder及合理选择传值/传指针。
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"。
