值类型不一定在栈上分配，其内存位置由逃逸分析决定：若地址逃逸出函数作用域（如返回指针、传入goroutine、存入接口等），则分配到堆上。
值类型默认在栈上分配，但逃逸分析可能让它上堆
Go 编译器会通过逃逸分析（escape analysis）决定变量是否分配在堆上。即使你声明的是 int、struct 这类值类型，只要它的地址被“逃逸”出当前函数作用域（比如返回指针、传给 goroutine、赋值给全局变量），它就会被分配到堆上。
常见误判是认为“值类型一定在栈”，实际中很多小结构体在闭包或 channel 传递时悄悄上堆了。
- 用
go build -gcflags="-m -l"查看逃逸分析结果，例如./main.go:12:6: &x escapes to heap - 避免不必要的取地址：返回结构体本身比返回
*T更可能留在栈上 - goroutine 中直接使用局部值类型变量没问题；但若传入
go func() { ... }()并在其中取其地址，就容易触发逃逸
哪些值类型操作一定会导致堆分配
不是类型决定堆栈，而是使用方式。以下场景几乎必然让值类型上堆：
- 对局部变量取地址并返回：
return &MyStruct{} - 把局部值类型变量的地址存入切片/映射/接口（如
interface{}）中 - 作为参数传给形参为
...interface{}的函数（如fmt.Println(x)中的x若是大结构体，可能逃逸） - 在闭包中捕获并修改局部值类型变量的地址（如
func() *int { p := &i; return p }）
struct 大小影响栈分配的稳定性
Go 对栈空间有保守限制（通常初始 2KB，可增长），但编译器不会因为 struct “太大”就直接扔去堆——它仍优先尝试栈分配，除非逃逸分析判定必须堆分配。
立即学习“go语言免费学习笔记（深入）”；
不过，超大 struct（如几 MB）即使没逃逸，也可能因栈空间不足触发运行时栈扩容，带来开销；更现实的风险是：大 struct 值拷贝成本高，易被编译器“劝退”而转为指针传递。
- 用
unsafe.Sizeof(T{})检查结构体大小，超过几百字节就要警惕 - 字段排列影响实际大小（考虑内存对齐），紧凑布局（如把
bool放一起）能减少浪费 - 如果 struct 频繁作为函数参数或返回值，且 > 128 字节，编译器可能隐式优化为按指针传递（但语义仍是值类型）
如何验证某个变量到底分配在栈还是堆
不能靠猜，也不能只看类型。最可靠的方式是结合逃逸分析 + 运行时观测：
- 加编译标志：
go build -gcflags="-m -m" main.go（双-m显示更详细逃逸信息） - 观察输出是否含
escapes to heap或moved to heap - 用
runtime.ReadMemStats对比前后HeapAlloc变化，辅以 pprof 分析堆对象来源 - 注意：goroutine 栈本身是堆上分配的，所以“栈上变量”指的是该 goroutine 栈帧内的局部存储，不是物理内存位置
真正难的不是判断单个变量，而是理解整个调用链中地址的生命周期——一个看似简单的 &v 可能在五层函数调用后才真正逃逸。
