返回局部变量指针必然触发逃逸，因栈帧销毁后指针不能指向无效内存；interface{}装箱、闭包捕获变量、切片/map/channel存储局部变量指针均导致逃逸。
返回局部变量指针必然触发逃逸
只要函数返回了局部变量的地址，&x 或 new(T) 创建的对象指针被直接返回，编译器就会把它挪到堆上。这不是 bug，是保障内存安全的必要行为——栈帧销毁后，指针不能指向无效内存。
常见写法：
-
func NewUser(name string) *User { u := User{Name: name}; return &u }→u逃逸 -
func foo() *int { x := 42; return &x }→ 编译输出./main.go:3:2: moved to heap: x
注意：哪怕结构体只有几个字段、体积很小，只要指针被传出，就逃逸。别指望“小结构体传指针更省”，它可能反而更重——因为堆分配 + GC 跟踪成本压过了拷贝开销。
interface{} 装箱是静默逃逸高发区
任何值赋给 interface{} 类型变量，基本都会逃逸。编译器在静态分析阶段无法确定运行时具体类型和大小，只能保守地分配到堆。
立即学习“go语言免费学习笔记（深入）”；
典型场景：
-
var i interface{} = 42→42逃逸 -
fmt.Println("hello")→ 字符串字面量、整数参数全逃逸（fmt函数参数全是interface{}） -
log.Printf("%d", n)同样逃逸，哪怕n是int
这不是设计缺陷，而是 interface 的实现机制决定的：底层需要 runtime._type 和 data 指针，必须动态分配。想规避？优先用具体类型函数（如 fmt.Print 替代 fmt.Println），或避免在 hot path 上频繁打日志/格式化。
闭包捕获变量导致隐式逃逸
当匿名函数引用了外层函数的局部变量，并且该闭包被返回或传到函数外，被捕获的变量就逃逸了——它要活到闭包被调用时，远超原函数生命周期。
示例：
func makeAdder(x int) func(int) int {
return func(y int) int {
return x + y // x 被闭包捕获
}
}
这里 x 会逃逸到堆。即使 x 是个 int，也逃逸。更隐蔽的是：
- 闭包里只读取
x，但闭包本身被存入全局 map 或 channel → 仍逃逸 - 闭包未返回，但作为 goroutine 参数启动：
go func() { ... }()→ 若捕获了局部变量，也逃逸
闭包逃逸容易被忽略，因为它不显式返回指针，也不涉及 interface{}，但逃逸分析结果一样明确：./main.go:3:10: x escapes to heap。
切片、map、channel 存储指针也会连带逃逸
不是容器本身逃逸，而是它持有的元素如果是指针，且该指针指向局部变量，那被指向的变量就逃逸。编译器追踪指针流向，一旦发现可能被长期持有，就提前搬走。
常见组合：
-
s := make([]*int, 0); x := 42; s = append(s, &x)→x逃逸（哪怕s是局部变量） -
m := map[string]*User{"a": &u}，其中u是局部 struct →u逃逸 ch := make(chan *int); go func() { ch → <code>x逃逸
关键点在于「谁持有指针」：只要指针被存进一个可能存活时间远超当前函数的结构里（比如可增长的 slice、可并发访问的 channel），编译器就认为变量生命周期失控，必须堆分配。
真正难调试的是嵌套场景：比如函数返回一个包含指针字段的 struct，而该 struct 被塞进 slice，再传给另一个函数——逃逸链路变长，但根源仍是那个最初被取地址的局部变量。
