go中变量分配在栈或堆由编译期逃逸分析决定，可通过go build -gcflags="-m"查看；&x不必然导致堆分配，关键看x生命周期是否超出作用域；new总分配在堆，make底层数组/哈希表在堆，但变量header可能栈分配。
怎么看变量到底分配在栈还是堆上
Go 编译器在编译期就通过逃逸分析决定变量位置，不依赖运行时。最直接的方法是加 -gcflags="-m" 查看输出：
-
go build -gcflags="-m" main.go显示基础逃逸信息（如... moves to heap） -
go build -gcflags="-m -m"显示更详细路径（比如哪一行触发了逃逸） - 注意：只要看到
escapes to heap或moved to heap，说明该变量一定分配在堆上
典型触发点包括：函数返回局部变量地址、赋值给全局变量、传入可能逃逸的参数（如 interface{}、any、goroutine 参数）。
为什么 &x 不一定导致堆分配
&x 本身只是取地址操作，是否逃逸取决于 x 的生命周期是否超出当前作用域。编译器会判断“这个地址会不会被函数外使用”——不是语法上写了 & 就强制堆分配。
- 如果
x是小结构体且只在函数内用：&x可能仍保留在栈上，指针也存栈中 - 如果
return &x：x 必然逃逸到堆，否则返回后指针失效 - 如果
fmt.Println(&x)：x 通常不逃逸，因为fmt接收的是interface{}，但编译器能优化掉部分逃逸（取决于具体调用链）
别凭直觉猜，一定要用 -m 验证。常见误判是把“用了指针”等同于“分配在堆”，其实指针变量本身（8 字节）和它指向的数据是两回事。
new 和 make 对内存位置的影响差异
new(T) 和 make(T, ...) 都会分配内存，但它们的语义和逃逸行为不同：
-
new(int)总是在堆上分配零值内存并返回*int；它不关心作用域，也不做逃逸分析——这是它的设计契约 -
make([]int, 10)初始化 slice header 并分配底层数组，底层数组一定在堆上（因为 slice 可增长、可传递、生命周期不可控） -
make(map[string]int)同理，哈希表结构必须在堆上；但 map 变量本身（header）可能栈分配，只要没逃逸 - 对比：
var s [10]int是纯栈分配，s := [10]int{}也是；但一旦你写&s并返回，整个数组就逃逸到堆
指针接收者如何悄悄抬升结构体到堆
结构体方法用指针接收者（func (t *T) Foo()）本身不强制逃逸，但容易引发连锁逃逸：
- 如果某个方法用了指针接收者，而你又把该结构体实例赋给全局变量或传进 goroutine，那它大概率逃逸
- 更隐蔽的是：一个大结构体（比如含
[]byte字段）即使只用值接收者，也可能因字段太大而被编译器主动抬升到堆（避免栈帧过大） - sync.Mutex 等不可拷贝类型必须用指针接收者，但它的零值是合法状态——这不是为了逃逸，而是语言约束
真正危险的是无意识的“指针泛滥”：小结构体一律加 *、字段全用指针、到处返回 &T{}。这些看似“统一风格”的做法，会让本可栈分配的对象批量逃逸，加重 GC 压力。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
