go逃逸分析看变量是否逃逸出函数作用域，而非类型或取地址操作；典型场景包括返回指针、传入goroutine、赋值给interface{}或大对象分配；用go build -gcflags=”-m -l”可查看逃逸提示。
Go 逃逸分析到底看什么变量
Go 编译器决定一个变量分配在栈还是堆，不看它是值类型还是指针类型，而看它是否「逃逸」——也就是生命周期是否超出当前函数作用域。常见误判是认为 &x 一定上堆、x 一定在栈，其实 x 如果被返回、传给 goroutine、赋给全局变量，哪怕没取地址，也会逃逸到堆。
- 逃逸典型场景：
return &x、go f(x)、chan 、赋值给 <code>Interface{}或切片底层数组扩容时原数据被引用 - 值类型如
Struct{a [1024]int}即便没取地址，也可能因体积过大被编译器主动挪到堆（避免栈溢出） -
fmt.Println(x)可能触发逃逸：因为内部会把x转成interface{}，若x是大对象或非接口安全类型，就逃了
怎么快速判断某个变量是否逃逸
用 go build -gcflags="-m -l" 看编译器提示，-l 禁用内联能让逃逸更明显。关键信息是类似 ... escapes to heap 或 ... does not escape 的输出。
- 只对当前包生效：跨包调用（比如调用标准库函数）的逃逸行为可能被隐藏，需结合源码或加
-m -m多级提示 - 注意编译器优化：开启 -O2（默认）后，某些本该逃逸的变量可能被优化掉；调试时建议保持默认构建参数
- 常见干扰项：
make([]int, 0, 10)的底层数组一定在堆，但长度为 0 的切片头（header）本身在栈——别把 header 和 data 混为一谈
值类型传参时取地址的代价不是“多一次拷贝”
很多人以为 func f(x T) 比 func f(x *T) 更省，其实如果 T 大且 x 逃逸了，前者反而更重：栈上先拷一份，再整体搬去堆；后者直接传指针，堆上只存一份。
- 小结构体（如
struct{a, b int}）按值传通常更快，CPU 缓存友好，且不触发逃逸 - 大结构体（如含
[1024]byte）按值传大概率逃逸，且拷贝开销显著；此时明确用*T更可控 - 接口方法调用（
var i io.Reader; i.Read(...)）隐式取地址：即使i是值类型变量，方法接收者是*T时，实际传的是指针——这点常被忽略
goroutine 启动时捕获变量的陷阱
闭包里直接用循环变量，几乎必然逃逸，而且容易引发数据竞争。不是因为「用了指针」，而是变量生命周期被延长到了 goroutine 执行完。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
for _, v := range s { go func() { use(v) }() }→ 所有 goroutine 共享同一个v地址，且v必须堆分配 - 正确写法：
for _, v := range s { v := v; go func() { use(v) }() }→ 每次迭代新建栈变量v，不逃逸（除非use自身导致） - 如果
s是指针切片（[]*T），v是指针，那v本身不逃逸，但指向的*T对象可能早已在堆上——逃逸分析只管变量头，不管它指向哪
逃逸分析不是黑盒，但它依赖编译器对控制流和类型的静态推断，一旦涉及反射、unsafe 或 interface{} 类型转换，结论就容易失效。真要压性能，得实测 + pprof，而不是光看 -m 输出。