逃逸分析是go编译器在编译期静态决定变量堆栈分配的唯一依据，通过扫描变量是否逃出函数作用域来判定：逃逸则堆分配，否则栈分配；典型场景包括返回局部变量地址、interface{}赋值、闭包捕获及大对象创建。
逃逸分析是判断堆栈分配的唯一依据
Go 不会在语法层面强制你写 new 或 make 来决定堆分配，真正起作用的是编译器的逃逸分析。它静态扫描代码，看变量是否“逃出”当前函数作用域。一旦逃逸，就上堆；否则默认栈上分配。
常见逃逸场景包括：
• 返回局部变量的指针（如 return &x）
• 将局部变量赋值给空接口（如 fmt.Println(x) 中的 x）
• 作为 map/slice 的元素被取地址（如 &s[0]）
• 闭包捕获了外部局部变量且该闭包被返回或传到函数外
用 go build -gcflags="-m" main.go 可直接看到每行是否逃逸。注意：加 -m -m 会显示更详细原因，比如 “moved to heap: x”。不要依赖直觉判断——哪怕是个 int，只要被取地址并传出，就一定上堆。
栈分配不是性能银弹，堆也不等于慢
栈分配快，但不意味着“越栈越好”。栈空间有限（初始 2KB，最大约 1GB），大结构体（比如含大数组或嵌套 map 的 struct）强行栈分配反而触发频繁栈扩容，带来拷贝开销和延迟抖动。
堆分配虽经 GC 管理，但 Go 的分级分配器（mcache → mcentral → mheap）对小对象（
• 频繁小对象分配 → GC 压力上升
• 大对象（>32KB）直接走系统调用，延迟高
• 指针密集结构 → GC 标记时间变长
所以优化方向不是“把所有东西拉回栈”，而是减少逃逸必要性：传指针而非值、避免无意义的 interface{}、用 sync.Pool 复用临时对象。
struct 字段顺序直接影响内存布局和逃逸行为
Go 的 struct 内存对齐规则会让字段顺序改变实际占用大小，进而影响逃逸判定。例如：
type A struct {
b bool // 1 byte
f float64 // 8 bytes
i int32 // 4 bytes
s string // 16 bytes
}
这个结构体因对齐填充，实际大小可能达 40 字节；但如果把 bool 放最后，填充会减少。更重要的是：如果某个字段导致整个 struct 超过栈帧安全阈值（编译器内部估算），整个 struct 就可能被整体抬到堆上，哪怕只有其中一个字段需要逃逸。
建议：
• 把小字段（bool, int8, byte）集中放前面
• 避免在 struct 里混用大小悬殊的字段（如 [1024]byte 和 int）
• 用 unsafe.Sizeof 和 unsafe.Offsetof 验证布局
goroutine 栈是独立的，但底层仍在堆上管理
每个 goroutine 的栈看似“独立”，但它的内存块本身是从堆（mheap）申请来的，只是由 runtime 单独维护其伸缩逻辑。这意味着：
• 栈扩容（如递归过深）本质是堆内存再分配 + 数据拷贝
• 栈缩容（使用率
• runtime.Stack 打印的栈地址是虚拟地址，不能反推是否“真栈”
所以别以为“没逃逸 = 完全不碰堆”。goroutine 生命周期内，栈本身的管理始终依赖堆分配器。真正零堆操作的场景极少，比如纯计算循环中只用寄存器和栈帧内的固定偏移变量。
最易被忽略的一点：逃逸分析只发生在编译期，运行时无法干预。写代码时若依赖“这个应该在栈上”，却没验证 -gcflags="-m" 输出，大概率掉坑里——尤其是加了中间层封装、用了泛型或 interface{} 之后，逃逸路径会悄然变化。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
