17370845950

Go变量分配在栈还是堆取决于编译器逃逸分析，而非语法形式；若变量可能活过当前函数则堆分配，否则栈分配。

Go变量分配在栈还是堆，不取决于你写 var 还是 new，而取决于编译器做的逃逸分析——它看的是变量“会不会活过当前函数”。只要可能被外部继续使用，就只能放堆上。

栈分配：快、自动、有边界

栈是每个 goroutine 私有的连续内存块，初始仅约 2KB，按需动态扩缩。它的核心特点是：

• 函数一进入，局部变量（如 int、struct{} 等值类型）默认进栈
• 函数一返回，整个栈帧自动清空，无需 GC 干预
• 访问极快——CPU 缓存友好，指针移动即完成分配/释放
• 但空间有限：单个变量过大（比如 >几 KB 的数组）、或嵌套调用太深，可能触发栈扩容甚至溢出

堆分配：慢、共享、生命周期由 GC 决定

堆是进程级共享的非连续内存区域，所有 goroutine 都可访问。变量落到堆上，通常因为：

• 被返回指针，如 func() *int { x := 42; return &x } → x 必须逃逸到堆
• 被闭包捕获，如 func() func() { x := 100; return func() { println(x) } }
• 底层数组需动态增长，如 make([]byte, 0, 1024) 或 append 触发扩容
• 类型含指针字段，或实现 interface 后调用方法（因运行时才确定具体类型）
• 对象太大，编译器主动判定“栈放不下”，直接扔堆上

Pointer 是逃逸的关键信号，但不是唯一原因

很多人误以为“用了指针就一定上堆”，其实不然。关键看指针是否“逃出作用域”：

• func f() { p := &struct{}{}; *p = ... } → 指针没传出，p 和它指向的结构体仍可栈分配
• func f() *struct{} { s := struct{}{}; return &s } → s 地址被返回，必须堆分配
• func f() { s := struct{ name *string }{}; s.name = new(string) } → new(string) 显式堆分配，但 s 本身仍可能栈上（除非它也被传出）

真正起决定作用的是编译器的静态分析：它追踪每个变量的“存活范围”，一旦发现可能被函数外引用，就标记为逃逸。

怎么验证变量是否逃逸？

用编译器自带的逃逸分析报告：

• go build -gcflags="-m" main.go → 输出基础逃逸信息
• go build -gcflags="-m -m" main.go → 更详细，含逐行分析
• 常见提示如 ... escapes to heap 或 ... does not escape

注意：内联（inlining）会改变逃逸结果。加 //go:noinline 可禁用内联，让分析更贴近你写的原始结构。

基本上就这些。栈堆之分不是语法约定，而是编译器对生命周期和可见性的理性判断。理解逃逸逻辑，比死记“什么该放哪”更有价值。