只有被判定为“不逃逸”的对象才可能栈上分配；实际是否发生取决于语言实现、JIT策略和运行时条件，需通过-XX:+PrintEscapeAnalysis（Java）或-gcflags="-m"（Go）等工具验证逃逸分析结果。
只有被判定为“不逃逸”的对象，才可能栈上分配；但实际是否发生，取决于语言实现、JIT 编译器策略和运行时条件，不是写个 &MyStruct{} 就自动栈分配。
怎么判断变量是否逃逸
逃逸分析本质是编译期静态分析：追踪对象引用是否“出界”。关键看三点——是否被返回、是否赋值给包级/全局变量、是否传入可能跨线程的函数（如 go f() 或写入 sync.Map）。Go 用 -gcflags="-m" 查看，Java 用 -XX:+PrintEscapeAnalysis（需配合 -XX:+DoEscapeAnalysis）。
常见逃逸现象包括：
-
return &T{}—— 方法逃逸，几乎必上堆 -
var global *T; global = &T{}—— 线程逃逸，强制堆分配 -
append(s, T{})中的T{}若s是参数传入且长度未知，常被保守判为逃逸 - 闭包捕获局部变量，且该闭包被返回或传入 goroutine，变量即逃逸
为什么 &T{} 有时栈分配、有时堆分配
Go 编译器对 &T{} 做逃逸分析更友好，因为它能明确看到构造和取址在同一条语句；而 new(T) 总是返回堆地址，不参与逃逸判定。但即使写 &T{}，只要引用被传出作用域，仍会逃逸。
影响栈分配落地的硬性限制有：
- 对象大小超过编译器阈值（Go 默认约 64KB，HotSpot 约几 KB）→ 退堆 存在虚方法调用（Java）或接口转换（Go）→ JIT 无法保证调用目标，保守判逃逸
- 对象字段含指针且指向不确定生命周期的数据 → 逃逸风险升高
- 函数内联被禁用（如含
//go:noinline）→ 分析上下文丢失，易误判逃逸
标量替换比栈分配更激进，但条件更苛刻
标量替换不是把对象放栈上，而是彻底拆掉对象头和字段布局，把每个字段当独立局部变量处理。它要求对象：
- 不逃逸（前提）
- 字段全为基本类型或可递归分解的标量（如
struct {x, y int}可拆，struct {name string}不可拆，因string是结构体+指针） - JVM 需开启
-XX:+EliminateAllocations（HotSpot 默认开启） - 无同步块（
synchronized）或反射访问（破坏字段独立性）
示例中 Point p = new Point(1,2); return p.x + p.y; 经标量替换后等价于 int px=1, py=2; return px+py;，连栈帧局部变量槽都不占。
别迷信“栈分配=性能提升”，先看 GC 压力源在哪
真正拖慢 GC 的，往往不是单个对象分配，而是高频小对象触发 Young GC 频率上升，或大数组/切片底层数组反复分配导致内存碎片。栈分配只解决“不逃逸对象”的生命周期问题，对以下场景无效：
- 切片扩容（
append触发底层数组重分配）→ 无论切片头是否栈分配，底层数组必堆分配 - 字符串拼接生成新字符串 → 底层字节数组堆分配
- map/slice 作为参数传入并被修改 → 编译器常因别名分析不确定而判逃逸
最易被忽略的一点：逃逸分析是跨函数的，但仅限于已知调用目标。若函数被接口调用或反射调用，分析链中断，所有参数默认逃逸。所以性能敏感路径尽量避免接口抽象和反射。
