v8的“逃逸分析”实为turbofan的启发式优化，核心是判断能否省略分配或栈上试探分配；闭包变量必然堆分配，非闭包小对象才可能栈分配；真正影响性能的是gc压力而非分配位置。
V8 并不执行传统意义上的逃逸分析，它不会像 JVM 或 Go 那样对变量作用域做全路径推演，也不输出“escapes to heap”这类明确结论。所谓“逃逸分析”在 V8 中实际是 TurboFan 编译器在优化阶段进行的一套启发式判断，核心目标不是决定“是否逃逸”，而是识别“能否安全省略分配”或“能否栈上试探分配”——而后者仅限极少数确定场景，且所谓“栈”是 V8 自己管理的 C++ 栈帧，不是 JS 可感知的语义栈。
闭包变量几乎必然进堆
只要一个局部变量被内部函数引用，且该函数作为返回值暴露到外层（例如被赋值给全局变量、传入事件监听器、作为 Promise 回调等），V8 就会将该变量提升至堆中，存入一个不可见的 Context 对象。这不是“分析后决定逃逸”，而是编译期静态扫描就确定的行为：
- 函数体里出现 内部函数引用了外层 let/const/var 变量 → 触发闭包标记
- 该内部函数被 返回、赋值、传参 → 外层变量失去作用域边界保障 → 必须堆分配
- 未被任何内部函数引用的变量（如示例中的 const test2 = 2）仍保留在原函数栈帧中，随函数退出自动释放
所谓“栈上分配”只适用于非闭包小对象
V8 确实存在栈上分配（stack allocation）机制，但它与闭包无关，只适用于满足全部条件的小对象：
- 对象在函数内创建，且 未被任何闭包捕获
- 对象未暴露给 JS 层（不 return、不赋值给全局、不传入回调）
- 对象大小稳定、类型单一（如 {x: 1, y: 2} 这类小结构）
- TurboFan 能证明其生命周期完全局限在当前函数内
这种分配发生在 V8 的 C++ 栈帧中，JS 层无法观测；一旦对象被闭包捕获，这条路径就彻底关闭。
验证方式比猜测更可靠
别依赖代码写法猜内存位置，直接看运行时行为：
- 启动 Node.js 加 --trace-gc --trace-gc-verbose，观察对象是否出现在 Scavenge 或 Mark-Sweep 日志中 → 出现即说明已进堆
- 用 chrome://tracing 录制堆快照，对比前后对象地址 → 栈分配对象根本不会出现在快照里
- 对疑似闭包变量调用 %HasFastProperties(obj) → 返回 true 只反映属性结构快，和内存位置无关
真正影响性能的关键不在“栈 or 堆”，而在 GC 压力
闭包导致变量堆分配本身不慢，慢的是高频创建带来的 GC 开销：
- 每次生成新闭包，都可能新建 Context 对象 + 捕获变量副本
- 若闭包持有大数组、大对象或 DOM 引用，会延长存活时间，阻碍新生代回收
- 循环中用 var i 创建闭包会共享同一变量，引发意料外的值覆盖；改用 let i 可让 V8 为每次迭代生成独立词法环境，更利于 GC 回收
