JavaScript引擎采用边解析、边优化、边执行的动态模型；var声明提升并初始化为undefined，let/const仅扫描进入TDZ而不初始化，访问未初始化绑定抛ReferenceError；V8中Ignition负责字节码解释，TurboFan对高频稳定函数优化为机器码，类型不稳定则去优化；setTimeout回调入宏任务队列，需等待当前调用栈清空及微任务执行完毕，且受浏览器最小延迟限制。
JavaScript 引擎不是“先编译再执行”的传统模型，它在运行时边解析、边优化、边执行——这个动态过程才是理解 JS 行为的关键。
JS 引擎如何处理 var 和 let 的声明提升？
引擎在进入作用域时会扫描所有声明，但处理方式完全不同：
-
var声明被“提升”到作用域顶部并初始化为undefined，所以能访问但值是undefined -
let和const也会被扫描（TDZ 阶段），但不初始化；在声明前访问会抛出ReferenceError，不是undefined - 引擎在解析阶段就标记了 TDZ 起始位置，运行时检查访问时机，这和“是否提升”无关，而是“是否初始化”
console.log(a); // undefined var a = 1; console.log(b); // ReferenceError let b = 2;
V8 的 Ignition + TurboFan 流水线怎么影响实际代码？
你写的代码可能被不同阶段的引擎组件处理，行为差异藏在细节里：
- 短生命周期函数（如事件回调）大概率只走 Ignition 字节码解释执行，不触发 TurboFan 优化
- 高频调用函数（如循环内
map回调）会被监控，满足条件后触发 TurboFan 编译为机器码，但若出现类型不稳定（比如x + y有时是数字、有时是字符串），会去优化（bailout）回字节码 -
console.log、debugger、eval会阻止某些优化，尤其是内联和逃逸分析
function sum(a, b) {
return a + b;
}
// 若反复传入 number 类型，TurboFan 会生成 int32 版本；
// 一旦传入 '1' 和 2，触发去优化，下次可能走慢路径
为什么 setTimeout(() => {}, 0) 不是立刻执行？
这不是引擎解析问题，而是事件循环与任务队列的协作机制：
立即学习“Java免费学习笔记（深入）”；
- 引擎解析完脚本后，把
setTimeout的回调注册进 Timer Queue，即使延迟为 0，也要等当前调用栈清空、且宏任务队列轮到它 - 微任务（如
Promise.then）优先级更高：它们在每次宏任务结束后立即批量执行，不等下一轮事件循环 -
浏览器还可能对
setTimeout做最小延迟限制（通常 ≥ 4ms），尤其在后台标签页中
console.log(1); setTimeout(() => console.log(2), 0); Promise.resolve().then(() => console.log(3)); console.log(4); // 输出：1 → 4 → 3 → 2
真正难调试的，往往不是语法错误，而是你以为“引擎该知道”的事，其实被优化掉了、被队列拦住了、或被 TDZ 卡住了。盯住控制台报错的具体位置，再查对应阶段的行为边界，比背概念更管用。
