JavaScript引擎采用解释+JIT混合策略：Ignition生成字节码快速执行，TurboFan对热点函数优化为机器码，去优化机制应对类型变化；代码按需解析执行，未调用函数不编译。
JavaScript 在浏览器中运行，靠的是浏览器内置的 JavaScript 引擎（比如 Chrome 的 V8、Firefox 的 SpiderMonkey、Safari 的 JavaScriptCore）。它不是直接“翻译成机器码”再执行，而是一套边解析、边优化、边执行的动态过程。
代码怎么进引擎：从 HTML 到可执行
当你在网页中写 或引入外部 JS 文件时，浏览器的 HTML 解析器会识别 script 标签，暂停 HTML 解析，把 JS 代码文本交给 JS 引擎处理。此时引擎做的第一件事是：词法分析 + 语法分析 → 生成抽象语法树（AST）。
例如 const a = 1 + 2; 会被拆成 token（const、a、=、1、+、2、;），再组织成树状结构，明确变量声明、赋值、二元运算等语义。
V8 引擎的典型执行流程（以 Chrome 为例）
V8 不是纯解释器，也不是纯编译器，而是采用 解释 + 即时编译（JIT） 的混合策略：
立即学习“Java免费学习笔记（深入）”；
- Ignition（解释器）：快速将 AST 编译成轻量级字节码，立即执行。启动快、内存省，适合冷代码。
-
TurboFan（优化编译器）：监控字节码执行时的热点函数（比如被调用超 100 次、循环多次），收集类型信息（如
x总是 number），生成高度优化的机器码替代原字节码。 - Deoptimization（去优化）：如果运行时发现假设错误（比如某变量突然变成 string），TurboFan 会“回退”，切回 Ignition 字节码执行，再重新收集数据、尝试优化。
你写的代码，其实没被“全量编译”
JS 引擎按需工作：
- 函数只有被调用时，才会被解析、生成 AST、编译字节码（甚至触发优化）；未调用的函数只是存着文本或简单解析，不消耗执行资源。
-
eval()、new Function()这类动态代码，会在运行时重新走完整流程（解析→AST→字节码），性能代价大，且无法被 TurboFan 优化。 - 顶层代码（不在函数内）属于“脚本代码”，会立即解析执行，但通常不会被 TurboFan 优化（因为只运行一次）。
几个关键事实帮你理解行为差异
为什么有些代码快、有些慢？为什么 console.log 放哪儿会影响性能？底层逻辑就在这里：
- 变量提升（hoisting）发生在 AST 构建阶段，不是运行时“移动代码”，而是引擎在解析时已知声明位置。
-
let/const的暂时性死区（TDZ）由引擎在字节码执行阶段检查，不是语法错误，而是运行时报错。 - 异步操作（如
setTimeout、fetch）不归 JS 引擎管——它们由浏览器的 Web API 处理，完成后把回调推入任务队列，再由 JS 引擎的事件循环（Event Loop）调度执行。
基本上就这些。JS 引擎不是黑箱，它用工程化手段在启动速度、内存占用、执行性能之间做精细权衡。写代码时少点 eval、避免过深嵌套闭包、让类型稳定些，就是在配合引擎工作。
