如何通过 V8 的逃逸分析理解变量在栈与堆分配中的执行效率差异

V8不进行传统逃逸分析，所有JS对象默认堆分配；性能关键在于控制对象生命周期以减少老生代晋升，而非追求栈分配。

V8 并不真正做传统意义上的逃逸分析，所谓“V8 的逃逸分析”其实是开发者对优化行为的误读。它不会像 Go 或 JVM 那样在编译期全路径追踪对象作用域，也不输出类似 “escapes to heap” 的明确结论。真正影响执行效率的，不是变量“在栈还是堆”，而是对象是否能被快速回收——这取决于它是否留在新生代（New Space）并经由 Scavenge 算法处理。

别被“栈分配”误导：JS 中几乎没有真正的栈对象

V8 官方文档和源码反复强调：所有 JS 对象默认堆分配。即使写 const obj = {} 且只在函数内使用，该对象仍进入 New Space（堆的一部分），而非 C++ 栈帧。V8 底层虽有极少数启发式栈上分配试探（仅限类型稳定、未闭包捕获、未暴露给 JS 层的小对象），但这是 V8 自己管理的 C++ 栈帧空间，与 JS 开发者无关，也不会出现在堆快照中。

你无法通过代码写法“保证”某个对象栈分配，更不能靠它提升性能。试图模仿 Go 的指针逃逸逻辑去“避免返回对象”或“不用闭包”，对 JS 没有意义。

真正拖慢执行效率的，是老生代晋升

执行效率差异的核心在于 GC 延迟：

• 新生代对象走 Scavenge（复制算法），单次耗时通常 < 1ms，几乎无感
• 一旦对象活过一次 GC，就会被晋升到老生代（Old Space），触发 Mark-Sweep-Compact，可能卡主线程几毫秒甚至更久
• 频繁晋升 → 更多老生代 GC → 更高 STW（Stop-the-World）风险 → 执行卡顿

所以，与其纠结“栈 or 堆”，不如关注“是否容易晋升”。一个对象只要被全局变量引用、传入 Promise/事件监听器、被闭包长期持有，就大概率晋升——它早晚会进老生代。

可落地的效率优化建议

这些做法不改变内存位置，但能显著降低晋升概率和 GC 压力：

• 用字面量 {}、[] 替代 new Object()、new Array() —— V8 对字面量有更多内联机会，利于后续优化
• 避免把局部对象传给异步上下文：比如 setTimeout(() => console.log(obj), 0) 或 Promise.resolve(obj)，会延长对象生命周期
• 函数参数尽量传原始值（number、string），少传大对象 —— 即使传了，V8 仍要堆分配引用，还可能触发隐藏的闭包捕获
• 用 --trace-gc --trace-gc-verbose 启动 Node.js，观察对象是否频繁出现在 Mark-Sweep 日志里；或用 chrome://tracing 录制堆快照比对地址变化，验证实际生命周期

小结：效率优化的关键不在内存位置，而在生命周期控制

V8 的设计哲学是“默认堆分配 + 快速新生代回收”。你写的每个 let、const 对象都进堆，但这不可怕；可怕的是让它们活太久、进老生代。优化方向很明确：减少跨函数/跨异步的引用，保持对象短命、轻量、结构稳定。不复杂，但容易忽略。