V8并不真正做传统逃逸分析，几乎所有JS对象默认堆分配；其所谓“逃逸分析”仅为TurboFan中极少数场景下的启发式栈分配试探，对象需满足字面量、类型稳定、不暴露JS层等严苛条件。
V8 并不真正做传统意义上的逃逸分析，所以“在特定作用域下分配对象就能规避堆开销”这个说法容易误导——几乎所有 JS 对象默认都在堆上分配，无论它是否只在函数内使用、有没有 return、有没有被闭包捕获。
V8 的“逃逸分析”不是分析，而是试探性优化
V8 官方文档和源码明确说明：它没有像 JVM 或 Go 那样对变量作用域做全路径追踪，也不会输出“escapes to heap”这类结论。它的所谓“逃逸分析”实际是 TurboFan 编译器中一个启发式阶段（EscapeAnalysisPhase），只在极少数确定场景下尝试栈上分配：
- 对象必须是小而简单的字面量（如
{x: 1}、[1,2]），且类型稳定 - 对象不能暴露给 JS 层：不传入任何回调、不赋值给全局/外层变量、不进入闭包环境
- 对象不参与任何可能触发去优化的操作（如动态属性增删、原型链修改）
- 该优化发生在 C++ 栈帧内，不是 JS 开发者能感知或控制的“栈变量”
你以为的“没逃逸”，其实早进了堆
下面这些写法，全部堆分配，V8 不会因为“看起来没逃逸”就改用栈：
-
function f() { const obj = {}; console.log(obj); }—— obj 仍在 New Space -
const arr = []; arr.push(1);—— 数组扩容、方法调用都会阻止栈试探 -
setTimeout(() => {}, 0)中哪怕只读取局部对象，也足以让 V8 放弃栈优化
验证很简单：启动 Node.js 加 --trace-gc --trace-gc-verbose，你会看到每次 Scavenge 都在清理这些“局部对象”。它们出现在堆快照里，地址可追踪——栈分配的对象根本不会出现。
真正影响堆开销的关键，是生命周期与晋升策略
与其纠结“能不能栈分配”，不如关注：对象是否快速可回收、是否避免晋升到老生代：
- 用字面量
{}/[]替代new Object()/new Array()：提升内联概率，减少隐藏类切换 - 避免把局部对象传给异步上下文（Promise、事件监听器、定时器）：防止被长期持有，卡在 Old Space
- 拆分大对象为原始参数（
draw(x, y, width, height)胜过draw({x,y,width,height})）：减少引用层级，降低 GC 扫描压力 - 对高频创建的小对象（如坐标点、临时状态），考虑对象池复用：比依赖“栈优化”更可控
别被术语带偏：JS 没有栈变量语义
JavaScript 规范里没有“栈变量”概念。let 和 const 声明的只是绑定，背后存储位置由引擎决定。V8 的优化目标从来不是“把对象放栈上”，而是“让新生代 GC 更快回收”。Scavenge 算法本身已足够轻量（通常
所以，优化方向很实在：减少长生命周期引用、保持对象轻量、避免意外闭包捕获——这些比幻想“逃逸分析让对象上栈”靠谱得多。
