Go 局部变量到底分配在栈上还是堆上？
Go 编译器会自动决定局部变量的分配位置——不是你写了 var x int 就一定在栈上，也不是用了指针就一定逃逸到堆。关键看编译器是否能证明该变量的生命周期严格限定在当前函数内。
常见错误现象：go tool compile -gcflags "-m" main.go 输出里反复看到 ... escapes to heap，但变量看起来“没传出去”，实际是因为返回了它的地址、存入全局 map、或被闭包捕获。
- 函数返回局部变量的地址 → 必然逃逸（栈帧销毁后地址失效）
- 把局部变量赋值给
interface{}或反射类型（如reflect.ValueOf）→ 大概率逃逸 - 切片字面量长度超阈值（如
[]int{1,2,3,...1000}）→ 可能触发逃逸，因编译器保守估计栈空间不足 - 闭包中引用外部局部变量 → 该变量逃逸（闭包可能比函数调用活得久）
怎么快速判断一个变量会不会逃逸？
最直接的方式是加编译标志看提示，但要注意层级：-m 只显示一级逃逸原因，-m -m 才会展开深层原因。
使用场景：写高性能服务（如 HTTP handler）、频繁分配小对象的循环、或调试 GC 压力大时。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 用
go build -gcflags "-m -m"编译单个文件，关注每行末尾的escapes to heap提示 - 避免在 hot path 上构造大结构体再取地址，比如不要写
&LargeStruct{...}，改用预分配池或传值 - 注意
fmt.Sprintf、strings.Builder.String()这类函数内部会做堆分配，不是变量本身逃逸，但效果类似 - 数组 vs 切片：
[1024]byte在栈上，[]byte（哪怕底层数组很小）只要被返回或存储，通常逃逸
逃逸分析对性能和 GC 的真实影响有多大？
不是所有逃逸都糟糕，但高频逃逸的小对象（如每次 HTTP 请求都 new 一个 map[string]string）会显著抬高 GC 压力，表现为 STW 时间变长、分配速率监控指标突增。
性能影响主要在两处：
- 分配开销：堆分配比栈分配慢一个数量级（需原子操作、内存池查找）
- GC 负担：每个堆对象都要被扫描、标记、可能移动；栈对象函数返回即回收，零成本
- 缓存友好性：栈内存局部性好，堆内存碎片化，访问延迟更高
兼容性无影响——逃逸分析是纯编译期行为，不改变语义，也不依赖运行时版本。
哪些写法看似安全却悄悄逃逸？
最容易被忽略的是隐式取址和接口转换。比如你没写 &x，但语言机制替你做了。
典型例子：
-
log.Printf("%v", x)→x被装箱进interface{}，若x是非接口类型且不可寻址（如字面量），编译器会先分配堆内存再取址 -
select {}中的 channel 操作变量：如果 chan 元素类型含指针或 interface，其底层数据常逃逸 - 方法接收者为指针且方法被接口调用（如
io.Writer.Write）→ 即使你传的是栈变量，也得取址满足接口契约 -
sync.Pool.Put(&T{})→ 明确要求指针，必然逃逸；应改为pool.Put(new(T))或复用已有实例
真正复杂的地方不在规则本身，而在于逃逸是跨函数传播的：一个 helper 函数里简单的 return &s，会让所有调用它的上层函数里对应变量一起逃逸。查问题得从最外层往里追。
