JavaScript由浏览器引擎（如V8）解析执行：先词法分析、语法分析生成AST，再JIT编译为机器码运行；script放body底部可避免阻塞DOM解析；defer确保DOM就绪后执行，async则执行时机不可控；函数调用创建执行上下文并入栈；eval和Function因动态编译、安全风险及导致JIT失效而应避免。
JavaScript 代码怎么被浏览器执行的
浏览器不是直接“运行” JavaScript，而是通过引擎把文本代码一步步解析、编译、执行。主流浏览器用的引擎不同：V8（Chrome、Edge、Node.js）、SpiderMonkey（Firefox）、JavaScriptCore（Safari），但流程高度一致。
简单说：你写的 console.log("hello") 会经历——读取 HTML 中的 <script></script> 标签 → 提取 JS 字符串 → 词法分析（拆成 console、.、log 等 token）→ 语法分析（生成抽象语法树 AST）→ 解释执行或即时编译（JIT）为机器码 → 调用 V8 的 Runtime 接口输出到控制台。
为什么 script 放在 body 底部更安全
因为浏览器解析 HTML 是自上而下流式进行的，遇到 <script src="..."></script> 会暂停 DOM 构建，去下载、解析、执行 JS —— 这期间页面渲染卡住，用户看到白屏。如果脚本里写了 document.getElementById("app")，而 #app 在它下面还没解析到，结果就是 null。
- 使用
defer：脚本并行下载，等 DOM 解析完、DOMContentLoaded前执行，保证 DOM 可访问 - 使用
async：下载不阻塞，但执行时机不可控，可能 DOM 还没就绪 - 手动监听
DOMContentLoaded事件，确保 DOM 已加载完成再操作节点
document.addEventListener('DOMContentLoaded', () => {
const el = document.getElementById('main');
if (el) el.innerHTML = 'Ready';
});
V8 引擎里函数调用实际发生了什么
每次调用函数，V8 都会创建一个执行上下文（Execution Context），压入调用栈（Call Stack）。这个上下文包含：VariableEnvironment（var 声明）、LexicalEnvironment（let/const）、this 绑定、outer environment reference（用于闭包）。
立即学习“Java免费学习笔记（深入）”；
常见误解是“函数定义时就确定了作用域”，其实没错，但关键点在于：闭包捕获的是变量的引用，不是值。比如循环中用 var 定义 i，所有回调共享同一个 i；换成 let 就每轮迭代生成独立绑定。
for (var i = 0; i < 3; i++) {
setTimeout(() => console.log(i), 0); // 输出 3, 3, 3
}
for (let j = 0; j < 3; j++) {
setTimeout(() => console.log(j), 0); // 输出 0, 1, 2
}
eval 和 Function 构造函数为什么危险又慢
eval() 和 new Function(...) 会触发完整的编译流程，且无法被 V8 的优化编译器（TurboFan）内联或优化。更重要的是，它们能访问当前作用域 —— 如果传入的字符串来自用户输入（比如表单、URL 参数），就等于开了远程代码执行后门。
-
eval("x + 1")必须重新解析、生成 AST、生成字节码，跳过所有缓存 -
new Function("return " + userInput)()不共享外层词法环境，相对安全一点，但仍绕过静态分析和 CSP（Content Security Policy） - 现代框架（如 React）用 Babel 编译 JSX，绝不用
eval动态执行模板字符串
真正难察觉的是 JIT 优化失效：一个高频函数如果内部用了 eval，V8 会直接标记为 “deoptimized”，降级回解释执行，性能可能跌一个数量级。
