V8 不做传统逃逸分析，所有 JS 对象默认堆分配；闭包变量进堆是因语言模型决定，而非“逃逸”，其性能代价在于内存局部性差、缓存命中率低及易晋升老生代。
V8 根本不做传统逃逸分析，闭包变量进堆不是因为“逃逸”，而是因为 JS 语言模型决定的——所有对象默认堆分配，闭包只是让变量无法被及时回收。
为什么 V8 不会把闭包里的 {x: 1} 放在栈上
V8 没有像 Go 或 JVM 那样的全路径逃逸分析机制。它不追踪“这个对象会不会被外部访问”，而是基于简单启发式：只要对象被闭包捕获、被赋值给全局/属性/回调、或类型不稳定，就直接进堆。哪怕你写的是 const obj = {x: 1}; (() => obj.x)()，obj 依然进堆——不是因为它“逃”了，而是 V8 默认如此，且没有栈变量生命周期语义可依。
- JS 中没有“栈变量作用域结束即销毁”的保证，引擎必须确保闭包执行时能安全访问被捕获的值
- V8 的所谓“栈上分配试探”只适用于极少数 C++ 内部小对象（如某些内部描述符），完全不暴露给 JS 层
- Chrome DevTools 的堆快照里能看到所有闭包捕获的对象，但看不到任何“栈分配对象”——它们根本不出现在快照中
闭包导致堆分配的真实性能代价在哪
代价不只在 GC 压力，更在内存局部性和间接访问开销：
- 堆对象地址分散，CPU 缓存命中率低；频繁读取闭包变量（如计时器回调里反复访问
count）比读栈变量多 2–3 个 cache line 跳转 - 闭包形成闭包环境（
[[Environment]]）对象，即使只捕获一个number，V8 也会为整个词法环境分配堆内存，包含未使用的变量槽位 - 若闭包被长期持有（如事件监听器、定时器未清理），对象无法进入新生代 Scavenge 快速回收，大概率晋升老生代，触发更耗时的 Mark-Sweep
怎么验证某个闭包变量是否进了堆
别猜，用实证工具看：
- 启动 Node.js：
node --trace-gc --trace-gc-verbose script.js，观察 GC 日志里是否有该对象参与 Scavenge 或 Mark-Sweep - 在 Chrome 中打开
chrome://tracing，录制 JS 堆快照，筛选闭包引用的对象，检查其内存地址是否随多次快照变化（栈对象不会出现） - 用
--allow-natives-syntax运行后调%HasFastProperties(obj)只说明结构快，和内存位置无关——这是常见误判点
真正影响性能的不是“闭包有没有逃逸”，而是“这个闭包是否被高频调用 + 捕获了哪些数据 + 是否长期存活”。控制闭包体积、避免捕获大对象、及时移除监听器，比纠结 V8 有没有做逃逸分析实在得多。
