Golang 里的逃逸分析（Escape Analysis）到底是怎么回事？-Golang-PHP中文网

go编译器在build阶段静态分析变量生命周期，若无法证明其严格限定于函数内则逃逸到堆；用go build -gcflags="-m -m"查看escapes to heap等提示，return &x、传interface{}、goroutine捕获、sync.pool.put、赋值全局变量等必逃逸。

golang 里的逃逸分析（escape analysis）到底是怎么回事？

Go 编译器在 go build 阶段就决定了每个变量分配在栈还是堆，不看 new 或 make，也不依赖运行时——只看变量的生命周期能否被静态证明严格限定在当前函数内。一旦存在任何路径让变量在函数返回后仍可能被访问，它就被标记为逃逸，强制分配到堆。

怎么一眼看出变量是不是逃逸了

用 go build -gcflags="-m -m" 查真实结果，关键线索是输出里有没有 escapes to heap 或 does not escape：

-m 单个只显示内联决策，基本不提变量去向；必须加两个 -m（即 -m -m）才能看到分配判断
想查某个函数，加 -m=2 并管道过滤：go build -gcflags="-m=2 -m" main.go 2>&1 | grep "MyHandler"
看到 leaking param: s to result ~r0 level=0，基本等于参数 s 直接作为返回值传出，逃逸成立
避免误编译依赖包：在目标包目录下执行，比如 cd ./cmd/myapp && go build -gcflags="-m -m" .

哪些写法几乎 100% 触发逃逸

这些模式不用跑 -m 就能预判，改一行代码就可能翻盘：

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

return &x：哪怕 x 是 int，取地址并返回就逃逸
传给接受 interface{} 的函数：如 fmt.Printf("%v", x)、json.Marshal(x)、errors.New(fmt.Sprintf())
闭包捕获后又被 goroutine 使用：go func() { use(x) }()，编译器无法保证 goroutine 执行完前函数已返回
sync.Pool.Put(x)：因为 Put 参数是 interface{}，装箱即逃逸
赋值给包级变量或全局 map/slice：作用域直接跨出函数边界

切片和结构体的逃逸容易被误解

切片本身（struct{ ptr, len, cap }）永远在栈上，但它的底层数组内存由逃逸分析单独决定：

make([]byte, 32) 在函数内纯本地使用，不返回、不传 interface{}、不进 goroutine → 底层数组通常栈上
一旦 append 导致扩容，或赋值给全局变量、或传给 fmt → 底层数组逃逸
结构体是否逃逸，不看大小，而看字段是否含指针且被外部引用；比如 type S struct{ name string; data *[]byte }，即使 name 很小，只要 data 被外部读取，整个 S 就可能逃逸
真正难调试的是链式逃逸：一个局部变量没逃逸，但它被赋给另一个变量，那个变量又被闭包捕获，最后进 goroutine —— 中间哪一环松动，整条链就上堆