用 go build -gcflags="-m -l" 看逃逸分析结果
Go 编译器默认会做逃逸分析，但不输出；加 -m 才能看见，加 -l 是为了禁用内联（否则函数被内联后，变量归属会被掩盖，逃逸判断失真）。常见错误是只写 -m，结果看到“moved to heap”却找不到对应变量——大概率是内联干扰了分析路径。
-
-m输出一级逃逸信息（比如某变量逃逸） -
-m -m（两个-m）输出更详细原因，例如“referenced by pointer passed to function” - 必须配合
-l关闭内联，否则foo(x)被内联后，x的生命周期看起来像在调用方栈上，实际可能已逃逸 - 如果项目用
go run，得写成go run -gcflags="-m -l" main.go，直接go run -m无效
interface{} 和 reflect 是逃逸高发区
只要值被装进 interface{} 或传给 reflect.ValueOf()，几乎必然逃逸——因为编译器无法在编译期确定其具体类型和大小，只能分配到堆上。这不是 bug，是设计使然。
-
fmt.Println(x)里x会转成interface{}，逃逸；换成fmt.Printf("%d", x)可避免（前提是x是基础类型且格式符匹配） -
json.Marshal(x)中x若是局部 struct，通常逃逸；但如果x是指针（&x），逃逸程度可能反而更低（避免复制） -
append([]int{}, x...)如果x是切片，底层数组可能逃逸；而make([]int, 0, len(x))+ 循环赋值，有时能留在栈上（取决于循环是否被优化）
返回局部变量地址一定会逃逸
这是最直观也最容易验证的逃逸场景：函数返回了某个局部变量的指针，那它肯定不能放在栈上（栈帧返回即销毁），只能分配到堆。
- 例如：
func newInt() *int { v := 42; return &v }→v必然逃逸 - 但注意：
func getVal() int { v := 42; return v }不逃逸，返回的是值拷贝 - 陷阱：闭包捕获局部变量也会导致逃逸，比如
func() { return &v }，即使没显式返回，该变量也逃逸 - 有些情况看似返回地址，实则没逃逸：如返回字符串字面量的指针（
&"hello"[0]），底层指向只读数据段，不涉及堆分配
小结构体不一定栈分配，大数组不一定堆分配
逃逸判断不只看大小，更看“是否可能被长期持有”。一个 16 字节的 struct，如果被赋给全局变量或传入 goroutine，照样逃逸；而一个 2KB 的数组，若只在函数内用且不取地址、不传 interface，仍可能栈分配。
立即学习“go语言免费学习笔记（深入）”；
- 栈分配上限不是硬编码值，而是编译器基于逃逸分析结果的综合判断
-
[1024]int在函数内直接声明并使用，无取地址、无传参，大概率栈上；但一旦return &arr或fmt.Println(arr)（触发 interface{} 转换），就逃逸 - 用
unsafe.Sizeof看大小没用，关键看变量的“生命周期可见性”——编译器能否证明它不会活过当前栈帧
真正难的不是看出逃逸，而是理解为什么某个看似安全的操作（比如传个切片进工具函数）触发了逃逸；这时候必须结合 -m -m 输出，逐层看“referenced by”链条，找到那个打破栈封闭性的引用点。
