返回局部变量指针必然逃逸，编译器将其分配到堆；闭包捕获外层局部变量并返回时逃逸；指针或含指针值发送到channel也逃逸。
返回局部变量的指针一定会逃逸
这是最典型、最确定的逃逸场景。Go 编译器只要看到函数返回了 &x，且 x 是函数内声明的局部变量，就会直接将 x 分配到堆上——因为栈帧在函数返回后就销毁了，指针不能指向已失效内存。
- 常见错误写法：
func getIntPtr() *int { x := 42 return &x // ⚠️ x escapes to heap } - 编译时加
-gcflags '-m'会明确输出：./main.go:3:9: &x escapes to heap - 即使
x是小整数（8 字节），也无法避免逃逸；逃逸与否和值大小无关，只和生命周期是否“逃出作用域”有关
闭包捕获局部变量导致逃逸
当匿名函数引用了外层函数的局部变量，并且该匿名函数被返回或传到函数外，被捕获的变量就无法留在栈上。
- 示例：
func makeAdder(base int) func(int) int { return func(delta int) int { return base + delta // base 被闭包捕获 → 逃逸到堆 } } - 注意：
base不是靠指针传递，而是被闭包隐式持有，编译器无法在函数返回后保证其栈空间仍有效 - 若闭包仅在函数内部调用（未返回/未传参出去），
base通常不逃逸；一旦暴露给外部作用域，即触发逃逸
指针或含指针的值发送到 channel
Go 的 chan 是并发安全的引用类型，发送操作意味着该值可能被其他 goroutine 访问，编译器无法静态判断其生命周期终点，因此保守地分配到堆。
- 以下全部逃逸：
ch := make(chan *string, 1) s := "hello" ch <- &s // s 逃逸
type User struct{ Name *string } u := User{&s} ch <- u // u 和 s 都逃逸
- 即使
ch是无缓冲 channel 或立即接收，逃逸仍会发生——逃逸分析发生在编译期，不感知运行时行为 - 规避方式：尽量传值（如
string本身）而非指针；或改用[]byte等不可寻址类型减少指针层级
接口赋值引发的隐式逃逸
把一个具体类型的变量赋给接口（尤其是导出接口如 io.Reader、error），如果该变量后续被返回或存储在长生命周期对象中，就可能逃逸。
- 典型场景：
func readIntoSlice(r io.Reader) []byte { buf := make([]byte, 1024) r.Read(buf) // r 是接口，buf 作为参数传入，可能被 r 内部保存（如某些自定义 Reader 实现） return buf // buf 未必逃逸，但 r.Read 调用本身常导致 buf 逃逸（见下条） } - 关键点：接口方法调用是动态分发，编译器无法确认
r.Read是否会保留buf的引用，所以保守逃逸 - 实测中，
io.ReadFull、json.Unmarshal等常用函数对切片参数的处理，往往触发底层数据逃逸，尤其当切片元素含指针（如[]*string）时更易发生
逃逸不是 bug，但高频发生会拖慢分配速度、加重 GC 压力。真正难察觉的是那些“看起来没返回指针、也没显式存全局”的情况——比如闭包、接口调用、channel 通信，它们的逃逸判定依赖编译器对数据流的深度推断，必须靠 go build -gcflags '-m -l' 实际验证，不能凭直觉判断。
