Go指针逃逸本质是编译器判断变量存放位置：若局部变量地址被带出函数作用域（如返回指针、赋给全局变量、发送到channel），则必须逃逸至堆上，避免栈帧销毁后野指针。
Go里的指针逃逸，本质是编译器在编译阶段做的一个“位置判断”：这个变量，到底该放在栈上，还是堆上？关键不在于你写了*，而在于它的地址会不会被函数外继续使用。
什么情况算指针逃逸
只要局部变量的地址被“带出函数作用域”，它就必须逃到堆上——因为栈帧一退，栈上的内容就没了，再访问就是野指针。
- 函数返回局部变量的指针（最典型）
func f() *int { x := 42; return &x } → x 逃逸 - 把局部变量地址赋给全局变量或包级变量
var global *int; func g() { x := 100; global = &x } → x 逃逸 - 把指针发到 channel 里
ch := make(chan *int); go func() { x := 200; ch - 闭包捕获并返回内部变量
func() int { x := 300; return func() int { return x } } → x 逃逸 - 把指针传给 goroutine（哪怕没显式返回）
go func(p *int) { ... }(&local)
为什么不能只看“有没有星号”
指针本身不导致逃逸，逃逸的是“被取地址的那个值”。比如：
- 不逃逸：func f(x *int) { *x = 1 } —— x 是入参指针，指向的可能是堆也可能是栈，但 f 内部没把它“留”下来
- 逃逸：func f() *int { y := 42; return &y } —— y 是本地变量，&y 被返回，y 必须活过 f 结束
区别在于：编译器能静态证明 y 的生命周期是否“超出函数边界”。能证明超出，就逃逸；否则默认栈分配。
怎么验证是否逃逸
用编译器自带的逃逸分析开关：
-
go build -gcflags="-m" main.go—— 显示每行是否逃逸 -
go build -gcflags="-m -l" main.go—— 关闭内联后更准确（避免内联干扰判断） - 输出中看到
... escapes to heap就是逃逸了
例如：./main.go:5:9: &x escapes to heap 表示第5行第9列的 &x 导致 x 逃逸。
逃逸了会怎样
不是错误，是 Go 的正常机制。但它有实际影响：
- 堆分配比栈慢，尤其高频小对象
- 堆上对象要等 GC 回收，增加 STW 时间和 CPU 开销（GC 占用约 25% CPU）
- 频繁逃逸可能掩盖真实性能瓶颈，比如本可栈分配的 struct 却因 interface{} 或指针传递被迫堆化
所以优化方向不是“消灭所有指针”，而是避免“不必要的逃逸”——比如小结构体传值比传指针更轻量，不必强求指针。
基本上就这些。逃逸分析不是玄学，它是编译器基于作用域和引用关系做的确定性决策，看清变量“去哪、谁用、用多久”，就能理解它为何逃、该不该逃。
