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 解析和渲染。浏览器遇到 <script></script> 标签，默认会暂停 HTML 解析，下载、编译、执行脚本，再继续。这就是为什么把大脚本放 底部，或加 async/defer 属性。
区别：
-
async：下载不阻塞 HTML，但下载完立即执行（可能打断渲染） -
defer：下载不阻塞 HTML，执行延迟到 DOM 解析完成、DOMContentLoaded触发前，且按顺序执行 - 动态创建的
script元素默认表现类似async
更隐蔽的问题：在 JS 中频繁读写 offsetHeight、getComputedStyle 等会强制触发回流（reflow），如果在长循环中调用，性能雪崩。现代做法是用 requestAnimationFrame 批量读写，或改用 ResizeObserver、IntersectionObserver。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
