JavaScript引擎通过解析、编译、执行三步处理代码，V8采用Ignition解释字节码+TurboFan对热点函数JIT编译；JS执行会阻塞DOM解析与渲染，async脚本下载后立即执行，defer则延迟至DOM解析完成前按序执行。

JavaScript 引擎如何解析和执行代码

浏览器不直接运行你写的 script 文本，而是交给 JavaScript 引擎（如 V8、SpiderMonkey）处理。这个过程分三步：解析（Parsing）、编译（Compilation）、执行（Execution）。V8 现在用的是“解释 + 即时编译（JIT）”混合策略：先用 Ignition 解释器快速生成字节码，再把热点函数交给 TurboFan 编译成高效机器码。

这意味着：写法相似的代码，执行速度可能差异很大——比如循环里反复读取 arr.length 而不是缓存它，V8 未必总能量化优化；而 for (let i = 0; i 在某些版本中会被优化，但换成 for (const item of arr) 可能触发不同路径。

执行上下文与调用栈怎么影响代码行为

每次函数调用都会创建一个执行上下文（Execution Context），压入调用栈（Call Stack）。全局代码对应全局上下文，函数调用对应函数上下文。变量提升（Hoisting）的本质，就是声明阶段（Creation Phase）把 var 声明和函数声明提前注册进当前上下文的词法环境，但赋值仍留在执行阶段（Execution Phase）。

常见误解是“let 和 const 不提升”，其实它们也提升，只是被放入“暂时性死区（TDZ）”，访问会抛出 ReferenceError：

console.log(a); // ReferenceError
let a = 1;

注意：typeof undefinedVariable 不报错，但 typeof undeclaredVariable 也不报错——因为未声明变量在全局作用域下是 ReferenceError，但在 typeof 中被特殊处理为 "undefined"。

事件循环（Event Loop）如何协调 JS 的单线程与异步

JavaScript 是单线程的，但浏览器是多线程的。JS 引擎只管执行同步代码，而 Web API（如 setTimeout、fetch、DOM 事件）由浏览器其他线程处理。它们完成任务后，把回调函数推入任务队列（Task Queue），等调用栈为空时，Event Loop 才把队列里的回调拉出来执行。

关键点：

• Promise.then() 回调属于 microtask，优先于 setTimeout 这类 macrotask 执行
• queueMicrotask() 可手动插入 microtask，比 Promise.resolve().then() 更轻量
• 一个宏任务执行完，会清空全部当前 microtask 队列，再取下一个宏任务

这解释了为什么下面代码输出顺序是 1 → 3 → 2：

console.log(1);
setTimeout(() => console.log(2), 0);
Promise.resolve().then(() => console.log(3));

DOM 渲染与 JS 执行如何互相阻塞

JS 执行会阻塞 DOM 解析和渲染。浏览器遇到 标签，默认会暂停 HTML 解析，下载、编译、执行脚本，再继续。这就是为什么把大脚本放 底部，或加 async/defer 属性。

区别：

• async：下载不阻塞 HTML，但下载完立即执行（可能打断渲染）
• defer：下载不阻塞 HTML，执行延迟到 DOM 解析完成、DOMContentLoaded 触发前，且按顺序执行
• 动态创建的 script 元素默认表现类似 async

更隐蔽的问题：在 JS 中频繁读写 offsetHeight、getComputedStyle 等会强制触发回流（reflow），如果在长循环中调用，性能雪崩。现代做法是用 requestAnimationFrame 批量读写，或改用 ResizeObserver、IntersectionObserver。