Go编译器对return &x等场景强制逃逸到堆，因变量生命周期超出函数作用域，与大小无关；interface{}赋值、闭包捕获、chan/map/切片存指针均触发逃逸。
Go 编译器只要看到 return &x，且 x 是函数内声明的局部变量，就一定会把它挪到堆上——不是“可能”，是确定行为。这不是 bug，但会带来 GC 开销，尤其在高频调用路径里。
为什么 return &x 必然逃逸
栈帧在函数返回后立即销毁，而指针还活着，内存就不能跟着一起回收。编译器没得选，只能把 x 分配到堆。哪怕 x 是 int、struct{a,b int} 这种 16 字节的小东西，也逃不掉。
-
func getPtr() *int { x := 42; return &x }→ 编译时加-gcflags '-m'会明确输出：&x escapes to heap - 逃逸和值大小无关，只和“生命周期是否超出函数作用域”有关
- 即使中间套了一层结构体，比如
return &struct{p *int}{&x}，依然逃逸
interface{} 赋值隐式触发逃逸
把非接口类型赋给 interface{}，会发生“装箱”（boxing），编译器必须在堆上分配一块内存来存这个值——因为 interface 的底层是 iface 结构，需要动态存放具体类型和数据指针。
-
var i interface{} = 42→42逃逸到堆 -
fmt.Println("hello")内部做了类似操作，字符串字面量本身不逃逸，但传参过程会触发 interface{} 装箱 - 如果变量已经是接口类型（比如
var i io.Reader），再赋给另一个interface{}就不会额外逃逸
闭包捕获局部变量导致逃逸
匿名函数引用了外层函数的局部变量，并把这个匿名函数返回或传出去，被捕获的变量就无法留在栈上。
立即学习“go语言免费学习笔记（深入）”；
-
func makeAdder(base int) func(int) int { return func(delta int) int { return base + delta } }→base逃逸 - 关键不是有没有取地址，而是“该变量是否可能被闭包长期持有”；编译器保守判断：只要闭包暴露到函数外，就逃逸
- 如果闭包只在函数内部调用（没返回、没传参、没塞进 map/channel），
base通常不逃逸
发送指针到 chan 或存入 map/[]*T
Go 的 chan、map、切片底层都是引用类型，一旦你把指针塞进去，编译器无法静态确认它何时被读取或释放，只能分配到堆。
ch → <code>User实例逃逸-
m["key"] = &v或slice = append(slice, &v)→v逃逸 - 即使
v是小 struct，只要进了集合且集合本身逃逸（比如被返回、存全局），v就跟着逃
真正难处理的不是单个逃逸点，而是逃逸链：一个变量逃逸，导致它所引用的其他变量也逃逸；interface{} 装箱后又传进 channel，再被 goroutine 持有——这种嵌套引用会让 GC 扫描范围扩大，且很难靠 nil 断开。手动清空 slice 元素、及时 delete map 键、避免长期持有 channel 缓冲区里的指针，这些细节比“要不要用指针”更关键。
