所有 JavaScript 对象默认且几乎总是分配在堆上（New Space），V8 的“栈分配”仅是编译器对极少数确定场景下的优化，不改变 JS 层对象的堆语义。
不能理解为“V8 在栈上分配原本属于堆的对象”——这个前提本身不成立。
V8 并不把 JS 对象从堆“挪到栈”
V8 中所有 JavaScript 对象默认且几乎总是分配在堆上（New Space），无论它是否只在函数内使用、有没有被 return、有没有闭包捕获。所谓“栈上分配”，不是对已有堆对象的迁移，而是编译器在极少数确定场景下，跳过堆分配流程，直接在底层 C++ 栈帧中构造一个轻量结构。这个结构不暴露给 JS 层，不出现在堆快照里，也不是开发者能声明或控制的“JS 栈变量”。
- 你写的
const obj = {x: 1}，哪怕只在函数内 console.log 一次，它仍进入 New Space，参与 Scavenge 回收 - V8 的“栈分配试探”仅适用于类型稳定、无属性动态增删、未传入任何回调、未被闭包捕获的小字面量
- 这种优化由 TurboFan 编译器在生成机器码前决定，JS 开发者无法通过写法“触发”或“保证”
为什么 JS 没有真正的栈对象语义
JavaScript 规范没有“栈变量”概念。let/const 声明的是绑定（binding），其底层存储位置由引擎根据运行时观测和启发式规则决定。V8 的目标从来不是模拟 C 或 Java 的栈分配，而是让新生代 GC 更快回收：Scavenge 算法处理 New Space 中短命对象，耗时通常低于 1ms；一旦对象晋升到 Old Space，就会面临 Mark-Sweep-Compact，带来明显卡顿。
- 闭包捕获一个 number，V8 仍会为整个词法环境分配堆内存，包含未使用的槽位
- 传对象给
setTimeout、Promise.resolve或事件监听器，哪怕只读取一个字段，也足以让 V8 放弃任何栈试探 - 用
new Object()而非{}，不仅没机会栈分配，还会降低内联概率、增加隐藏类切换开销
真正影响性能的关键是晋升行为，不是分配位置
执行效率差异不来自“栈 vs 堆”的物理位置，而来自对象是否长期存活、是否进入老生代。一个对象只要被全局变量引用、被异步上下文持有、或活过一次 GC，就大概率晋升——它会在 Old Space 中零散分布，加重 GC 整理负担，甚至导致堆碎片。
- 高频创建的小对象（如坐标点、临时状态）建议用对象池复用，比依赖“栈优化”更可控
- 拆分大对象为原始参数：
draw(x, y, w, h)比draw({x,y,w,h})减少引用层级，降低 GC 扫描压力 - 避免在循环中反复生成新闭包：
arr.map(i => () => i)会产生大量分散小对象，加剧碎片风险
怎么验证你的对象在哪？别猜，看日志和快照
启动 Node.js 时加 --trace-gc --trace-gc-verbose，观察该对象是否出现在 Scavenge 或 Mark-Sweep 日志中；在 Chrome 中用 chrome://tracing 录制堆分配轨迹，或通过堆快照筛选闭包引用的对象——如果它出现了，那它一定在堆上。栈分配的对象根本不会出现在这些工具中。
-
--trace-escape可输出 TurboFan 的逃逸分析决策过程，但仅用于调试，不反映 JS 层可见行为 -
%HasFastProperties(obj)只说明对象结构快，和内存位置无关，是常见误判点 - 所有 JS 对象默认堆分配，这是 V8 的设计事实，不是待优化的缺陷
