逃逸分析是Go编译器在build阶段静态判定变量分配位置的机制，依据是变量生命周期能否被严格限定在当前函数内；若存在函数返回后仍可能被访问的路径，则变量逃逸至堆。
逃逸分析不是运行时行为，而是编译期静态判断
Go 编译器在 go build 阶段就决定了每个变量该放在栈还是堆，不依赖运行时、也不看 new 或 make 关键字。它只看变量的“生命周期能否被静态证明严格限定在当前函数内”。只要存在任何一条路径，让这个变量可能在函数返回后还被访问，它就被标记为逃逸——然后分配到堆上。
这意味着：你改一行代码（比如加个 fmt.Println(x)），逃逸结果就可能翻盘；但程序跑起来之前，答案已经写死在编译输出里了。
怎么一眼看出变量大概率逃逸
有些模式几乎 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：作用域直接跨出函数边界
用 go build -gcflags="-m -m" 看真实结果
单个 -m 只显示内联决策，基本不提变量去向；必须用两个 -m（即 -m -m）才能看到关键判断：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
./main.go:12:6: x escapes to heap → 确实逃逸./main.go:15:9: y does not escape → 栈上分配
实操建议：
- 在目标包目录下执行，比如
cd ./cmd/myapp && go build -gcflags="-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直接作为返回值传出，逃逸成立
切片和结构体的逃逸容易被误解
切片本身（struct{ ptr, len, cap }）永远在栈上，但它的底层数组内存由逃逸分析单独决定：
-
make([]byte, 32)在函数内纯本地使用，不返回、不传接口、不进 goroutine → 底层数组通常栈上 - 一旦
append导致扩容，或赋值给全局变量、或传给fmt→ 底层数组逃逸 - 结构体是否逃逸，不看大小，而看字段是否含指针且被外部引用；比如
type S struct{ name string; data *[]byte }，即使name很小，只要data被外部读取，整个S就可能逃逸
真正难调试的，往往是链式逃逸：一个局部变量没逃逸，但它被赋给另一个变量，那个变量又被闭包捕获，最后进 goroutine —— 中间哪一环松动，整条链就上堆。这种得靠 -m -m 加 //go:noinline 拆开看，否则内联会把路径“吞掉”。
