对象不一定在堆上，逃逸分析可判定其是否逃逸：未逃逸时JVM可栈上分配或标量替换；方法逃逸或线程逃逸则必须堆分配。
核心思路很直接：让对象不“跑出去”，编译器才可能把它留在栈上；栈上对象一出作用域就自动消失，GC 完全不用管它。
识别逃逸的三个关键信号
只要代码中出现以下任一写法，变量大概率被判定为逃逸，强制分配到堆：
-
返回局部变量的地址或引用，比如
return &User{}或return ptr（哪怕 ptr 是函数内 new 出来的） -
赋值给包级变量、全局变量或结构体字段，例如
var globalCache *Config; globalCache = &Config{} -
传入跨线程上下文，包括启动 goroutine 时作为参数传入、写入
sync.Map、发往 channel（尤其是无缓冲或已满 channel）、或作为接口类型参数调用可能并发执行的函数
主动收窄作用域，引导编译器判为不逃逸
很多逃逸不是因为逻辑必须，而是写法太“松散”。改几个细节，就能大幅提升栈分配成功率：
- 用
&T{}替代new(T)：Go 编译器对前者更敏感，能识别“构造+取址”是原子动作，降低误判概率 - 闭包中只捕获真正需要的字段，比如只需
user.Name，就别写func() { fmt.Println(user) }，而应写name := user.Name; func() { fmt.Println(name) } - 避免在切片操作中对局部变量取址，如
append(s, &x)易被保守判逃逸；若 x 很小，可考虑直接复制值或重构逻辑 - 保持函数内联可用：不要加
//go:noinline，否则逃逸分析丢失调用链上下文，容易把本可栈分配的对象判为逃逸
验证是否真走栈分配了
不能靠猜，得看编译器实际输出：
- Go 项目：运行
go build -gcflags="-m -l" main.go，如果某变量没有出现... escapes to heap提示，且无其他警告，基本可确认未逃逸、具备栈分配条件 - Java 项目：启用
-XX:+PrintEscapeAnalysis -XX:+DoEscapeAnalysis，再配合 GC 日志观察对应对象是否从 Young GC 记录中消失；消失即说明已栈分配或标量替换 - 注意：不逃逸 ≠ 一定栈分配。JIT 或 Go 编译器还会检查对象大小（Go 默认约 64KB 上限）、是否含不确定生命周期的指针（如嵌套 map/slice）、是否涉及接口动态调用等硬限制
配合其他手段巩固效果
栈分配是起点，不是终点。要真正压低 GC 压力，还需组合落地：
- 对高频临时对象（如 HTTP 请求缓冲区、序列化中间结构），用
sync.Pool复用，避免反复堆分配 - 预分配 slice 容量，避免 append 触发多次底层数组扩容和拷贝（每次扩容都可能产生新堆对象）
- 字符串拼接优先用
strings.Builder或bytes.Buffer，避免+运算符隐式生成多个临时字符串对象 - 用
pprof的allocsprofile 定位内存分配热点，再结合逃逸分析逐个优化
