逃逸分析不分配内存，仅判断对象引用是否“逃逸”，不逃逸是栈分配的前提；JIT编译器结合大小、构造方式等决策是否栈分配；三大逃逸边界：返回地址、赋值全局变量、传入跨线程上下文。
逃逸分析本身不分配内存，它只是判断一个对象的引用会不会“跑出去”。只有被判定为不逃逸的对象，才具备栈上分配的前提条件。真正决定是否栈分配的，是JIT编译器结合对象大小、构造方式、调用链等运行时信息做的综合决策。
明确“不逃逸”的三个硬性边界
逃逸分析的核心是静态追踪引用传播路径。只要出现以下任一行为，变量大概率逃逸到堆：
- 作为函数返回值直接返回（如
return &T{}或return obj） - 赋值给包级变量、全局变量或静态字段（如
var global *T; global = &T{}） - 被传入可能跨线程的上下文（如写入
sync.Map、启动 goroutine 时传入、作为参数调用go f()）
缩小作用域：从写法上引导编译器判为不逃逸
很多看似无害的写法，会因语义模糊导致编译器保守判逃逸。主动收窄作用域能显著提升栈分配成功率：
- 避免把局部对象地址存入切片或 map —— 即使切片是局部变量，若其底层数组长度不确定，
append(s, &x)中的&x常被误判逃逸 - 不用
new(T)，改用&T{}：Go 编译器对后者更友好，能识别“构造+取址”在同一条语句中，降低逃逸概率 - 闭包中只捕获真正需要的字段，而非整个结构体；若仅读
user.Name，就别捕获user整体 - 函数内联未被禁用（避免
//go:noinline），否则逃逸分析丢失调用上下文，易误判
栈分配落地的现实限制
即使变量被判定为不逃逸，也不等于一定栈分配。JVM 或 Go 编译器还有几道硬门槛：
- 对象过大：HotSpot 默认阈值约几千字节，Go 约 64KB；超过则强制退堆
- 含虚方法调用（Java）或接口转换（Go）：JIT 无法确定目标，放弃优化
- 字段含指针且指向生命周期不确定的数据（如嵌套 slice、map）
- 调用了
getClass()、System.identityHashCode()、synchronized块等破坏对象独立性的操作
验证是否真的栈分配了
不能靠猜测，得用工具看编译器实际决策：
- Go：加
-gcflags="-m -l"编译，输出中出现move to heap表示逃逸，无此提示且无警告，大概率栈分配 - Java：启用
-XX:+PrintEscapeAnalysis -XX:+DoEscapeAnalysis，配合-XX:+PrintGC观察对应对象是否从 GC 日志中消失 - 注意：标量替换（字段拆成局部变量）比栈分配更激进，也更难触发，但一旦成功，连栈帧空间都省了
