可通过go build -gcflags="-m"查看逃逸分析结果，加两次-m显示详细依据；变量逃逸指其地址被返回、传入goroutine、存入全局容器或闭包捕获等，导致必须堆分配。
怎么快速知道一个变量在 Go 里是堆分配还是栈分配
Go 编译器自动决定变量分配位置，你没法用代码“强制指定”，但可以通过 go build -gcflags="-m" 看逃逸分析结果。加一次 -m 显示基础信息，加两次（-m -m）会显示更详细的决策依据，比如哪一行触发了逃逸。
常见错误现象：明明只在函数内用的变量，却看到输出里有 ... escapes to heap —— 这说明它被编译器判定为“可能活到函数返回后”，必须堆分配。
- 逃逸不等于“用了 new/make”：即使没显式调用
new或make，只要变量地址被返回、传给 goroutine、存入全局 map/slice/chan，就大概率逃逸 - 闭包捕获局部变量时，被捕获的变量通常逃逸（除非编译器能证明生命周期严格受限）
- 接口类型接收值时，底层数据若大小不确定或需动态调度，也容易触发逃逸
哪些写法会让变量一定逃逸
不是所有指针操作都逃逸，但以下场景基本稳逃：
- 函数返回局部变量的指针：
func bad() *int { x := 42; return &x }→x必须堆分配，否则返回悬垂指针 - 把局部变量地址存进全局
map[string]*T、[]*T或chan *T - 在 goroutine 中直接使用局部变量地址：
go func() { println(&x) }()（哪怕没显式取地址，闭包隐式捕获也会导致逃逸） - 调用接受
interface{}的函数，且传入的是非接口类型的变量（如fmt.Println(x)中的x是小 struct，也可能逃逸，取决于具体版本和上下文）
struct 字段大小和对齐如何影响逃逸判断
Go 不按字段个数或是否指针来简单判断，而是看整个 struct 是否“适合栈上管理”。关键点在于：是否可能被外部持有、是否过大、是否含指针且生命周期不可控。
立即学习“go语言免费学习笔记（深入）”；
- 小 struct（如
type Point struct{ x, y int }）通常不逃逸，但如果它作为字段嵌入到一个被返回的 interface 值中，底层数据仍可能逃逸 - 含指针字段的 struct 不一定逃逸，但如果该指针指向的数据来自局部变量（比如字段是
*int且赋值自&localVar），那整个 struct 很可能逃逸 - 编译器对栈空间预估保守：单个函数栈帧一般限制在几 KB 内，超大 struct（比如几 MB 的数组）会被直接推到堆上，和逃逸分析无关，属于“栈溢出规避”行为
为什么 go tool compile -S 看不到堆/栈分配痕迹
go tool compile -S 输出的是汇编，它不体现“堆 or 栈”的语义，只反映寄存器/栈帧偏移/内存加载指令。真正决定分配位置的是逃逸分析阶段（在 SSA 前），结果只体现在 -m 日志里。
容易踩的坑：有人以为看到 MOVQ ... SP 就代表栈分配，看到 CALL runtime.newobject 就代表堆分配 —— 实际上后者确实表示堆分配，但前者只是访问栈帧某偏移，并不能反推变量原始分配位置（因为逃逸后的变量也可能被拷贝进栈做临时操作）。
性能影响很实在：频繁逃逸会导致 GC 压力上升、内存碎片增多；但别为了“不逃逸”强行改写逻辑，比如把本该返回结构体指针的 API 改成返回多个字段，反而破坏可读性和维护性。逃逸分析是优化手段，不是设计约束。
