const object = { a, b } 有时不逃逸，因为v8在turbofan编译阶段通过静态分析确认该对象仅在函数内使用、未被返回、未被闭包或全局变量捕获，从而判定其未逃逸，进而跳过堆分配，将a、b优化为栈上局部变量甚至寄存器值。
为什么 const object = { a, b } 有时不逃逸
当 V8 静态分析出一个对象只在当前函数作用域内使用，且其引用未被返回、未被闭包捕获、未被赋值给全局/实例变量时，就判定它“未逃逸”。这时 V8 可能跳过堆分配，直接把 a 和 b 当作独立局部变量处理，甚至优化进寄存器。这种优化不是靠运行时判断，而是在 TurboFan 编译阶段基于 feedback 和控制流图（CFG）完成的。
常见误判点：
- 哪怕只写一句
console.log(object)，V8 也可能因无法完全证明该对象不会被调试器或 DevTools 捕获而放弃栈优化 - 对
object做Object.keys(object)或JSON.stringify(object)会强制触发堆分配——这些 API 内部需要访问对象的完整结构，无法拆解为标量 - 使用
for...in遍历对象也会导致逃逸，因为 V8 无法静态确定属性名集合是否稳定
function foo() { return { x: 1 } } 一定逃逸吗
是的，几乎总是。只要函数返回一个对象字面量，它的引用就脱离了当前函数栈帧生命周期，必须存活到调用方使用完毕。V8 不会对这种显式返回做栈上分配，即使对象极小（如 {x: 1}）。
但注意两个例外场景：
- 如果该函数被内联（inlined），且返回值立即被解构（如
const {x} = foo()），TurboFan 可能在内联后消除临时对象，等效于栈上标量处理 - 若整个函数被常量折叠（constant folding），比如
foo()被替换成字面量{x: 1}，且后续无引用，则对象可能根本不会被构造
验证方式：打开 Chrome DevTools → Performance 面板 → 录制一段含该函数调用的脚本，查看内存分配火焰图中是否出现 Object 构造记录。
如何用 --trace-escape 观察逃逸决策
V8 提供实验性 flag --trace-escape，可输出逃逸分析过程中的关键判断。它不会告诉你“分配在哪”，但会说明“为什么没优化”。
实操步骤：
- 启动 Node.js 时加参数：
node --trace-escape script.js - 在代码中插入明显逃逸模式，例如：
let globalRef; function f() { const o = {a: 1}; globalRef = o; } - 输出中会出现类似
[escape] o escapes to globalRef (store)的日志，明确指出逃逸路径
注意：--trace-escape 在 V8 10.9+ 才稳定支持，旧版可能无输出或崩溃；且它只对 TurboFan 编译后的函数生效，首次执行 Ignition 字节码时不会触发。
栈优化失效的真实代价有多大
不是“快一点”或“慢一点”的问题。一次堆分配 + 后续 GC 清理的开销，可能比栈上创建 100 个同尺寸对象还高。尤其在高频循环中：
- 每秒创建 10 万个
{x:1,y:2}对象 → 堆压力激增，可能触发 Minor GC 频率从 1s/次升至 100ms/次 - GC 的 Stop-the-world 时间虽短（
- 更隐蔽的是内存碎片：大量短命小对象让新生代半空间（semispace）快速填满，Scavenge 算法复制成本上升
真正容易被忽略的，是逃逸分析的“全有或全无”特性：它不支持部分字段栈分配。哪怕你只多传了一个 onComplete 回调函数，整个对象就会整体逃逸——这时候不如手动拆成多个参数，或改用池化对象。
