怎么判断一个变量是在栈上还是堆上
Go 编译器在编译期做逃逸分析，决定变量分配位置——不是靠 new 或 make，也不是靠是否是指针，而是看变量的生命周期是否**超出当前函数作用域**。
常见错误现象：go tool compile -gcflags "-m -l" 输出里反复出现 ... escapes to heap，但你没改代码，只是加了个日志或返回了某个结构体字段，就突然堆分配了。
- 如果变量被返回（如函数返回
&v、v是局部 struct 但字段含指针且被外部引用），它大概率逃逸到堆 - 闭包捕获局部变量时，该变量逃逸（哪怕只读）；
for循环中用:=声明的变量，每次迭代复用同一地址，但若被闭包捕获，会为每次迭代单独堆分配 - 接口类型（如
fmt.Stringer）接收值时，如果底层类型未实现内联方法（比如大 struct），传参可能触发堆分配
为什么 make([]int, 10) 有时在栈上，有时在堆上
切片本身是三字长结构（ptr, len, cap），永远在栈上；但它的底层数组内存，由逃逸分析决定分配位置。
使用场景：小切片（如 make([]byte, 32)）在函数内纯本地使用，不返回、不传入 goroutine、不转成接口，通常底层数组也留在栈上；一旦赋值给全局变量、作为返回值、或传给 fmt.Printf 这类接受 interface{} 的函数，底层数组就逃逸。
立即学习“go语言免费学习笔记（深入）”；
-
make不是堆分配的开关，append才常是隐式逃逸点——扩容时新数组无法在原栈帧分配，必须堆上新建 - 显式指定容量可减少逃逸：比如
make([]int, 0, 16)比make([]int, 16)更易保留在栈上（前者只分配 header，后者立即分配 16 个 int 的数组空间） - Go 1.21+ 对小切片做了栈上分配优化，但仅限于长度 ≤ 64 字节且无跨函数逃逸路径的情况
sync.Pool 能避免堆分配吗
不能。它不改变分配位置，只复用已分配的堆内存块，减少 GC 压力和 malloc 系统调用开销。
性能影响明显：频繁创建销毁小对象（如 bytes.Buffer、临时 []byte）时，sync.Pool 可降低 20%~50% 的 GC 时间，但首次 Get 仍要堆分配；而且 Pool 中的对象可能被 GC 清理，不能依赖其存在性。
- 对象放入 Pool 前必须清零（尤其含指针字段的 struct），否则残留引用会阻止 GC 回收关联内存
- Pool 不适合生命周期长的对象（比如连接池），它设计目标是“短命、高频、同构”对象
- 别在 defer 中 Put：goroutine 退出后 Put 失效，对象直接泄漏
逃逸分析结果为什么本地跑和 CI 上不一样
逃逸分析受编译器优化等级影响。默认 go build 开启优化（-gcflags="-l" 关闭内联），而 go test 默认关闭内联（-gcflags="-l"），导致同一段代码在测试中更易逃逸。
兼容性影响：Go 版本升级（如 1.20 → 1.22）可能调整逃逸规则，某些旧代码在新版里突然堆分配变多，尤其涉及泛型推导或接口转换时。
- 检查真实行为，不要只信
-m输出：用pprof的allocsprofile 实际观测堆分配量 - 交叉验证用
go run -gcflags="-m -m"（双 -m 显示更详细原因），注意最后一行才是最终决策 - 第三方工具如
go/analysis包写的 linter 无法替代编译器自身分析，它们只是模拟，精度有限
逃逸不是 bug，是 Go 在安全与性能间做的权衡；真正该警惕的，是那些你以为在栈上、其实每毫秒都在 malloc 的小对象——它们藏得深，压测时才露馅。
