v8 不做传统逃逸分析，而是基于启发式的栈上分配试探，仅在极少数确定场景下将小对象置于c++栈帧；所有js对象默认堆分配，是否晋升老生代才影响性能。
为什么 V8 的逃逸分析不等于 Go 或 JVM 的逃逸分析
V8 官方文档和源码中明确说明：V8 并不做传统意义上的逃逸分析。它没有像 JVM 那样在 JIT 编译阶段对对象的动态作用域做全路径分析，也不像 Go 编译器那样通过 -gcflags="-m" 输出“escapes to heap”这类明确结论。V8 的优化逻辑更偏向“基于观测的启发式内联 + 栈上分配试探”，只在极少数确定场景下（如函数内创建且未被闭包捕获、未暴露给 JS 层、类型稳定）才把小对象放在栈帧里——而且这个“栈”是 V8 自己管理的 C++ 栈帧，不是 JS 引擎暴露给开发者的抽象概念。
V8 中变量到底分配在哪儿？看实际 GC 日志比猜更可靠
真正决定一个 JS 对象是否在堆上，取决于它是否进入 V8 的 New Space 或 Old Space。只要对象被 new 出来、赋值给全局变量、传入回调、或被闭包引用，它就必然进堆。V8 不会因为你“没 return 这个对象”就把它栈分配——JS 没有栈变量生命周期语义，所有对象都默认堆分配。
验证方式很简单：
- 启动 Node.js 时加
--trace-gc --trace-gc-verbose，观察每次Scavenge或Mark-Sweep是否处理该对象 - 用
chrome://tracing录制 JS 堆快照，对比前后对象地址是否变化（栈分配的对象根本不会出现在快照里） - 写一个只在函数内使用的
const obj = {x: 1}，再用--allow-natives-syntax跑%HasFastProperties(obj)—— 返回true只说明结构快，不说明内存位置
哪些写法会让 V8 更可能复用栈空间（而非堆）
V8 确实会在底层复用栈帧空间，但这是编译器对局部 C++ 变量的优化，和 JS 开发者写的 let / const 无关。你唯一能间接影响的，是避免触发堆分配的条件：
- 不用
new Object()或new Array()，改用字面量{}/[]（V8 对字面量有更多内联机会） - 避免把局部对象传给
setTimeout、Promise.resolve、事件监听器等异步上下文 - 函数参数尽量用原始类型（
number,string），少传大对象——传了也没用，V8 仍要堆分配引用 - 不要依赖“没被 return 就一定栈分配”的直觉；
function f() { const a = {}; console.log(a); }中的a依然在堆上
真正该关心的不是“栈 or 堆”，而是“是否可被 GC 快速回收”
V8 的新生代（New Space）GC 是 Scavenge 算法，耗时通常在 1ms 内；而老生代 GC（Mark-Sweep-Compact）可能卡主线程几毫秒甚至更久。所以关键不是阻止堆分配，而是避免对象晋升到老生代：
- 让对象生命周期短于一次 Scavenge（默认约 1–2MB 新生代满即触发）
- 避免长引用链：比如
obj.a.b.c = largeArray，哪怕obj本身很快丢弃，largeArray也会因被引用而滞留 - 注意
console.log(obj)会隐式延长对象生命周期（DevTools 保持引用），调试时别信它
所谓“栈 vs 堆”的差异，在 V8 场景下是个误导性问题——它没有提供 JS 层可控的栈分配语义。真正在意性能，就盯住 GC 日志里的 scavenge 频率和 old space size 增长速度，而不是纠结某个 let x = {} 到底落在哪块物理内存上。
