JavaScript有严格编译执行流程：先词法分析和语法解析生成AST，再初始化词法/变量环境形成作用域链，接着Ignition字节码与TurboFan JIT优化，最后由宿主事件循环调度宏微任务。
JavaScript 不是“边写边执行”的脚本语言，它有一套严格的编译与执行流程，理解这个流程能帮你解释 hoisting、ReferenceError、闭包生命周期等常见困惑。
引擎启动时先做词法分析和语法解析
V8（Chrome/Node）、SpiderMonkey（Firefox）等引擎一拿到 JS 代码，立刻进行两阶段静态处理：
- 词法分析（Lexing）：把源码切分成
token，比如function、const、{、myVar、123 - 语法解析（Parsing）：用 token 构建抽象语法树（AST），例如
const x = 1 + 2会生成含VariableDeclaration、BinaryExpression节点的树
如果这一步出错，你会看到 SyntaxError: Unexpected token '}' 这类错误 —— 它发生在任何代码执行前，连 console.log 都不会触发。
执行前必须完成变量环境与词法环境的初始化
函数调用时，引擎为该执行上下文创建两个关键结构：
-
LexicalEnvironment：存放let/const声明，初始值为uninitialized（访问即报ReferenceError） -
VariableEnvironment：存放var和函数声明，会被提前初始化为undefined（所以var有“变量提升”） - 二者都包含对父级环境的引用，构成作用域链
这就是为什么这段代码不报错但输出 undefined：
console.log(a); // undefined var a = 1;
而这段直接崩溃：
console.log(b); // ReferenceError: Cannot access 'b' before initialization let b = 2;
字节码与即时编译（JIT）不是可选优化，而是执行核心环节
V8 不直接解释 AST 或生成机器码，它走的是三段式路径：
- AST →
Ignition字节码（轻量、内存友好，用于快速启动） - 运行中统计热点函数（如被调用超 100 次）→ 触发
TurboFan编译为优化机器码 - 若后续发现类型不稳定（比如某参数从 number 变成 string），则去优化（
deoptimization），退回字节码执行
这意味着：typeof、instanceof、频繁的 try/catch 都可能阻碍 TurboFan 优化；而保持参数类型一致、避免在热函数里修改原型，能显著提升性能。
事件循环不是 JavaScript 引擎的一部分，而是宿主环境提供的调度机制
JS 引擎本身只管执行同步代码、管理调用栈与内存。真正决定“何时执行 setTimeout 回调”或“谁先拿到 Promise.then”的是宿主（浏览器或 Node.js）的事件循环实现：
- 宏任务（macrotask）：
setTimeout、setInterval、I/O、UI render - 微任务（microtask）：
Promise.then、MutationObserver、queueMicrotask - 每次宏任务执行完，引擎会清空全部微任务队列，再取下一个宏任务
所以这段代码输出顺序是 1 → 3 → 2：
console.log(1); setTimeout(() => console.log(2), 0); Promise.resolve().then(() => console.log(3));
注意：setTimeout(..., 0) 并不等于“立刻执行”，它只是尽快排进下一个宏任务队列 —— 实际延迟取决于当前调用栈是否为空、微任务是否已清空。
真正难调试的，往往不是语法错误，而是你误以为“代码按书写顺序执行”，却忽略了词法环境初始化时机、JIT 的去优化行为、或者事件循环中宏/微任务的嵌套层级。这些地方没日志、不报错，但逻辑就是不对。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
