Go编译器通过逃逸分析静态决定变量分配栈或堆，依据是生命周期是否超出函数作用域；返回指针、闭包捕获、赋值全局变量或大对象动态分配等必触发逃逸，可用go build -gcflags="-m -l"验证。
Go函数里的变量不是你想放栈就放栈、想放堆就放堆——编译器说了算，而它判断的依据就是逃逸分析。你写的代码只要出现返回指针、闭包捕获、存入全局结构体或动态切片扩容等行为，s、numbers、sum 就大概率被挪到堆上。
怎么一眼看出变量会不会逃逸？看这三条铁律
逃逸分析不是玄学，它有可验证的静态规则：
- 函数返回了某个局部变量的地址（比如
&c、new(Student)），该变量必然逃逸 - 变量被闭包捕获且闭包被返回（如
Add()返回的匿名函数持续持有sum），该变量逃逸 - 变量被赋值给全局变量、
map、slice、channel或结构体字段（哪怕只是临时塞进globalCache = append(globalCache, &item)），也逃逸
注意：不是“用了 make 就一定逃逸”。make([]int, 0, 20) 在函数内不返回，通常栈分配；但 make([]int, 0, 20000) 因为超出了栈帧容量上限（默认约 2KB），即使不返回也会被强制扔到堆上。
用 go build -gcflags=-m 看真实逃逸日志
别猜，直接让编译器告诉你：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
go build -gcflags="-m -l" main.go
-l 关闭内联，避免干扰判断；输出里看到 ... escapes to heap 就是逃逸证据。常见误判点：
- 接口类型参数（如
fmt.Println(x)）会触发x逃逸，因为要装箱成interface{} - 结构体字段含指针（如
type Cache struct { data *[]byte }），即使结构体本身栈分配，data指向的内容仍可能在堆上 - 循环中新建小对象（如
for i := range items { tmp := &Item{i} }），每个tmp都逃逸，不是复用同一块堆内存
为什么传指针不一定省事？小心“假优化”陷阱
新手常以为“传指针比传 struct 快”，但实际可能更慢：
- 小结构体（比如
struct{a,b int}）传值开销远小于一次堆分配+GC扫描成本 - 传指针导致接收方必须在堆上分配，而调用方原本的栈变量反而无法复用
- 如果指针指向的对象后续被写入 map 或 channel，还可能引发二次逃逸（比如先传指针，再把指针存进全局
sync.Map）
实操建议：对 ≤ 16 字节的结构体，优先传值；超过 64 字节且生命周期明确短于调用方时，再考虑指针——但务必用 -gcflags=-m 验证是否真逃逸。
逃逸不是 bug，但高频逃逸会拖垮 GC
真正要警惕的不是单次逃逸，而是热路径上反复触发的小对象堆分配。比如 HTTP handler 里每次请求都 json.Unmarshal 到新 *User，或循环里不断 append 切片却不预估容量。这些行为不会立刻崩溃，但会导致：
- 堆内存 RSS 持续上涨，GC 频次升高（
gctrace=1可观察） - mcache 耗尽后 fallback 到 mcentral，锁竞争加剧
- 三色标记阶段扫描对象数暴增，STW 时间变长
最隐蔽的坑是：你以为自己没 new，但标准库函数（strings.Split、regexp.Compile、time.Now()）内部可能悄悄逃逸。查不到原因时，先跑一遍 -gcflags=-m，别跳过中间那层调用。
