Go编译器在build阶段静态分析变量生命周期，若无法证明其严格限定于函数内则逃逸到堆；用go build -gcflags="-m -m"查看escapes to heap等提示，return &x、传interface{}、goroutine捕获、sync.Pool.Put、赋值全局变量等必逃逸。
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 就能预判，改一行代码就可能翻盘：
-
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 }）永远在栈上，但它的底层数组内存由逃逸分析单独决定：
立即学习“go语言免费学习笔记（深入）”；
-
make([]byte, 32)在函数内纯本地使用，不返回、不传interface{}、不进goroutine→ 底层数组通常栈上 - 一旦
append导致扩容，或赋值给全局变量、或传给fmt→ 底层数组逃逸 - 结构体是否逃逸，不看大小，而看字段是否含指针且被外部引用；比如
type S struct{ name string; data *[]byte }，即使name很小，只要data被外部读取，整个S就可能逃逸 - 真正难调试的是链式逃逸：一个局部变量没逃逸，但它被赋给另一个变量，那个变量又被闭包捕获，最后进
goroutine—— 中间哪一环松动，整条链就上堆
逃逸不是 bug，是 Go 的正常机制；但高频小对象逃逸会显著抬高 GC 压力，尤其在微服务高并发场景下。最易被忽略的是：内联状态会彻底改变逃逸结果——NewFoo() 单独编译时逃逸，被调用方内联后可能完全不逃逸。别只看单个函数，得结合实际调用链看最终生效的分配决策。
