go中值类型是否逃逸由逃逸分析决定，非语法本身；用go build -gcflags="-m"可查看变量是否“escapes to heap”；指针返回、闭包捕获、赋值给interface{}等语义操作导致逃逸。
值类型不一定分配在栈上，Go 编译器通过逃逸分析决定它最终落在栈还是堆——这是由使用方式决定的，不是语法或类型本身决定的。
怎么一眼看出变量有没有逃逸到堆上
最直接的办法是用 go build -gcflags="-m" 编译并观察输出。只要看到某变量后跟着 escapes to heap，就说明它被分配到了堆上。
- 局部变量没取地址、没传给 goroutine、没赋值给全局 map/slice/interface{} → 通常留在栈上
- 写了
return &x或go f(&x)→x必然逃逸 - 把结构体赋给
interface{}（尤其含方法时）→ 很可能逃逸，因为编译器无法静态确认类型行为 - 用
go tool compile -S main.go查汇编，搜CALL runtime.newobject可确认是否真做了堆分配
为什么 return &T{} 一定逃逸，而 return T{} 通常不逃逸
本质是生命周期问题：T{} 是值返回，调用方拿到的是副本，原函数栈帧销毁不影响它；&T{} 是指针返回，外部要持有对“这个内存”的引用，但栈帧马上弹出，编译器只能把它挪到堆上保活。
- 哪怕
x := 42; return &x，x也会逃逸——大小无关，语义才关键 -
make([]int, 10)或new(int)创建的对象，底层数据一定在堆上，哪怕变量本身（如 slice header）在栈上 - 闭包捕获了局部变量，且该闭包被返回或传入 goroutine → 捕获的变量逃逸
大结构体传参时，用值还是用指针
不能一概而论。传值会拷贝整个结构体，传指针只传 8 字节地址，但若指针指向的对象本身逃逸，反而增加 GC 压力。
立即学习“go语言免费学习笔记（深入）”；
- 小结构体（比如
struct{a int; b string}）传值开销小，且更易留在栈上 - 大结构体（如含
[1024]byte或嵌套 map）传值拷贝成本高，优先用*T传参 - 字段顺序影响实际大小：用
unsafe.Sizeof检查，把小字段（bool、int8）集中放前面，减少填充字节 - 向
[]interface{}append 值 → 每个元素都会装箱逃逸，尽量避免
sync.Pool 存值还是存指针
存 *T 更合理。Pool 的 Get 返回的是 interface{}，底层会做一次值拷贝；如果存的是 T，每次 Get 都要复制整个结构体，反而放大开销。
-
pool := sync.Pool{New: func() interface{} { return &MyStruct{} }}是推荐写法 - 取出对象后必须重置状态（如
b.Reset()），不能依赖 Pool 自动清空 - Pool 不保证复用，也不控制生命周期，不适合存带外部资源（如文件句柄）的对象
真正难的不是记住规则，而是理解“逃逸”背后是编译器对变量生命周期的保守推断——你写的每一行取地址、赋接口、起 goroutine，都在悄悄改写它的内存命运。
