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 可禁用内联，让分析更贴近你写的原始结构。
基本上就这些。栈堆之分不是语法约定，而是编译器对生命周期和可见性的理性判断。理解逃逸逻辑，比死记“什么该放哪”更有价值。
