V8 中所有 JS 对象均在堆上分配，局部变量的原始值存于栈帧，对象引用是栈上指针但指向堆中实体；所谓“栈上分配”实为启发式试探，且不改变 JS 语义。
V8 并不真正执行传统意义上的逃逸分析，所以不能用 Java 或 Go 的逻辑去理解它的“栈上分配”。它不追踪对象是否逃出作用域，也不基于数据流分析判定生命周期。所谓“V8 的逃逸分析”，其实是社区误传；官方文档和源码中明确指出：V8 没有实现逃逸分析。
真正起作用的是另一套机制：启发式栈上分配试探（heuristic stack allocation attempt），仅在极少数确定场景下，把非常小、结构稳定、且完全未暴露给 JS 层的对象，临时放在 V8 自身 C++ 栈帧里——但这和 JS 开发者感知的“栈变量”无关，也无法通过代码行为可靠触发。
V8 中局部变量的内存位置由什么决定？
- 所有 JS 对象（包括
{}、[]、new Date()）默认都在堆上分配，无论是否const、是否只在函数内使用、是否没被return。 -
let/const声明的原始值（如let x = 42）确实存于栈帧局部变量槽，但这是 JS 引擎对基本类型的直接存储，不涉及“逃逸”判断。 - 对象引用（如
const obj = {}）本身是栈上的指针，但其所指向的对象实体，100% 在堆中 —— 这是 JS 语言语义决定的，V8 不会改变。
哪些写法容易让人误以为“栈分配发生了”？
- 使用字面量而非
new：{}比new Object()更可能被优化（如内联、隐藏类快路径），但仍是堆分配。 - 避免异步暴露：不传给
setTimeout、Promise.resolve、事件监听器，能减少对象被长期持有，加快新生代 GC 回收，不是避免堆分配，而是让堆对象更快消失。 - 不捕获进闭包：若函数返回一个闭包，且该闭包引用了局部对象，那对象必然存活更久，进入老生代 —— 这影响的是 GC 压力，不是分配位置。
如何验证一个对象到底在哪？
- 启动 Node.js 加参数：
node --trace-gc --trace-gc-verbose script.js，观察 GC 日志中是否有该对象参与 Scavenge 或 Mark-Sweep； - 在 Chrome DevTools 中录制 Heap Snapshot，搜索该对象，看它是否出现在堆快照里（栈分配的对象根本不会出现）；
- 不要用
%HasFastProperties(obj)或console.log(obj)判断 —— 这些只反映对象结构或打印行为，和内存布局无关。
真正该关注的不是“栈 or 堆”，而是“能否快速回收”
- 新生代（New Space）GC 是 Scavenge 算法，耗时通常
- 老生代（Old Space）GC 是 Mark-Sweep-Compact，可能卡主线程几毫秒；
- 让对象保持短命、不晋升老生代，比幻想“栈分配”实际得多。
不复杂但容易忽略。
