上周在优化一个高频接口的性能，发现一个奇怪的现象：明明代码改动很小，但内存分配数量从 10 次直接飙到 50 次。当时直接懵了——改的就是改了一个函数返回值的形式，怎么就改出问题来了？
后来才明白，这就是变量逃逸搞的鬼。
栈和堆，一个快一个慢
在 Go 里，对象分配的位置对性能影响巨大。
栈分配：超快，函数返回就自动释放，没有 GC 压力。想象一下工人领工具，用完直接放回工具架，啥都不用干。
堆分配：相对慢，需要 GC 管理，会产生 GC 停顿。工具用完了以后，还要有人来收拾，最后送到回收站。
对比一下性能差异：
// 栈分配，飞快
func stackAlloc() {
x := 10
y := 20
z := x + y // 都在栈上，BOOM，函数返回就没了
}
// 堆分配，相对慢
func heapAlloc() {
p := new(int) // 指向堆上的 int
*p = 10
// 函数返回后，p 还在堆上晃荡，GC 要处理
}
所以 Go 编译器的一个重要优化就是：尽可能把东西放在栈上，只有必要的时候才分配到堆。这个决策过程叫逃逸分析。
什么时候变量会"逃逸"到堆
"逃逸"的意思就是：变量原本可以在栈上活着，但因为某些原因，必须跑到堆上去。
常见的逃逸情况：
1. 被指针返回
func badExample() *int {
x := 10
return &x // x 的地址被返回了
// x 原本想在栈上活着，但调用者拿着 &x 的指针
// 函数返回后栈帧消失，指针会悬空
// 所以编译器把 x 提升到堆上，保证指针永远有效
}
func goodExample() int {
x := 10
return x // 直接返回值，不返回指针
// x 就能老老实实在栈上呆着
}
2. 被接口类型变量引用
type Reader interface {
Read(p []byte) (n int, err error)
}
func badExample(v interface{}) {
// 即使 v 里装的是个值类型，一旦装进 interface{}
// 也得在堆上分配，因为 interface{} 内部需要存指针
x := 10
var i interface{} = x // x 被提升到堆上
}
3. Slice/Map 容量动态增长
func badExample() {
var s []int // 空 slice，这没事
s = append(s, 1) // 第一次 append，分配堆内存
s = append(s, 2) // 可能继续在堆上扩容
}
4. 被闭包捕获
func outer() func() {
x := 10
return func() { // 闭包
println(x) // 闭包引用了 x
// x 需要在 outer 返回后还活着，所以逃逸到堆上
}
}
5. 因为大小不确定
func badExample(size int) {
x := make([]int, size) // 动态大小的 slice
// 编译时不知道 size 多大，无法在栈上预分配空间
// 必须在堆上分配
}
怎么看变量有没有逃逸
这是我踩坑最深的地方。有时候写的代码，自己觉得在栈上，但其实早就跑到堆上了，还完全不知道。
后来发现了一个神器：go build -gcflags="-m"
# 编译时打印逃逸分析信息
go build -gcflags="-m" ./main.go
# 想要更详细的（包括内联分析等）
go build -gcflags="-m -l" ./main.go
试试看效果：
// escape_demo.go
package main
type User struct {
name string
age int
}
// 函数 1：返回指针，变量逃逸
func createUser1(name string) *User {
u := User{name: name, age: 25}
return &u // 逃逸！
}
// 函数 2：直接返回值，栈分配
func createUser2(name string) User {
u := User{name: name, age: 25}
return u // 不逃逸
}
// 函数 3：接收接口，逃逸
func printUser(v interface{}) {
println(v)
}
func main() {
u1 := createUser1("Alice")
u2 := createUser2("Bob")
printUser(u2)
}
运行编译命令：
$ go build -gcflags="-m" escape_demo.go 2>&1 | grep -E "escape|move"
输出（大概是这样）：
# createUser1 里的 u，标记为 "escapes to heap"
./escape_demo.go:9:5: moved to heap: u
./escape_demo.go:10:8: &u escapes to heap
# createUser2 里的 u，没有逃逸标记，说明在栈上
# main 里的 u2 被 printUser(interface{}) 接收
./escape_demo.go:21:12: u2 escapes to heap
关键信息：看
escapes to heap或者moved to heap这样的提示，就知道哪些变量逃逸了。
我踩过的坑
坑 1：无意中用了接口，变量全部逃逸
// 我的日志库，接收 interface{}
func Log(v interface{}) {
fmt.Println(v)
}
// 主代码
func handleRequest(data *bytes.Buffer) {
// 这里 data 被当成 interface{} 传给 Log
Log(data) // 逃逸了！
// 原本 data 可以在栈上，但被装进 interface{} 以后堆分配
}
当时测试的时候，发现这个函数的内存分配数特别高。一开始以为是
bytes.Buffer 本身的问题，折腾了半天才明白——是接口调用惹的祸。
修复方案：避免不必要的接口转换
// 方案 1：改成有具体类型的函数
func LogBuffer(buf *bytes.Buffer) {
fmt.Println(buf)
}
// 方案 2：如果一定要用 interface{}，把转换推后
func Log(v interface{}) {
fmt.Println(v)
}
func handleRequest(data *bytes.Buffer) {
// 直接用 data，不传给 Log
// 或者在必要时才调用 Log
}
坑 2：闭包引起的逃逸链反应
// 异步任务处理
func processAsync(id int) func() {
userData := getUserData(id) // 假设这是个大结构体
return func() {
// 闭包引用 userData
process(userData)
}
}
func main() {
for i := 0; i < 1000; i++ {
callback := processAsync(i)
go callback() // 在 goroutine 中执行
}
}
这段代码的问题：每次循环，userData
都会逃逸到堆上（因为闭包引用），然后创建一个 goroutine 去执行闭包。结果就是堆上到处都是
userData 的副本。
当时线上监控显示内存增长特别快，查了半天代码才发现——这 1000 个回调函数都捕获了
userData，全部堆分配。
修复方案：避免闭包捕获大对象，或者显式传参
// 方案：闭包不捕获，用函数参数传递
func processAsync(id int) func() {
// 不在这里读取 userData，等到真正执行时再读
return func() {
userData := getUserData(id) // 在闭包内部读取
process(userData)
}
}
坑 3：Slice append 导致的堆分配
func buildList() []int {
var result []int
for i := 0; i < 1000000; i++ {
result = append(result, i) // 每次可能导致堆重新分配
}
return result
}
这是经典的问题。append
每次都可能触发底层数组扩容，每次扩容都是一次堆分配。堆分配 N 次，GC 压力就大 N 倍。
修复方案：提前分配足够的容量
func buildListOptimized() []int {
result := make([]int, 0, 1000000) // 预分配容量
for i := 0; i < 1000000; i++ {
result = append(result, i) // 一次内存分配，后续没有扩容
}
return result
}
差别有多大？我测过：
// 性能对比
// buildList：内存分配次数 ~40
// buildListOptimized：内存分配次数 1
// 执行时间也快了 10 倍以上
逃逸分析的尽头是什么
说了这么多，有个问题你可能在想：是不是所有东西都应该在栈上分配？
答案是：不完全是。
有时候逃逸其实是编译器的"保险起见"。比如：
func maybe(shouldReturn bool) *int {
x := 10
if shouldReturn {
return &x
}
return nil
}
编译器看到有可能返回 &x，就把 x
提升到堆上。即使实际运行中这个分支从不执行，也会产生堆分配。
这种情况下，最好的办法就是避免不必要的指针返回。改成返回值：
func maybe(shouldReturn bool) int {
x := 10
if shouldReturn {
return x
}
return 0
}
另一个问题：不是所有堆分配都坏。如果你的对象确实需要活得很久，或者需要在多个 goroutine 间共享，那么堆分配是必要的。关键是不要无意中产生堆分配。
实战建议
写代码时别过度优化。大多数情况下，逻辑清晰比性能微调更重要。
性能瓶颈出现时再用
-m排查。不要一开始就纠结每个变量的分配位置。避免接口转换在 hot path。如果一个函数在紧密循环中被调用，尽量用具体类型而不是
interface{}。Slice/Map 预分配。如果你知道最终大小，就提前分配容量，别让 append 不断扩容。
Goroutine 闭包要小心。如果闭包捕获大对象，考虑用参数传递替代。
用 pprof 验证。不要只看代码猜测，
go tool pprof会告诉你实际内存使用情况。
折腾了这么久才把逃逸分析搞明白。现在遇到内存问题，我的第一反应就是
go build -gcflags="-m"
一把梭，直接看变量逃逸情况，往往能快速定位问题。