JavaScript由引擎先编译再执行，解析即生成AST并完成作用域绑定与优化；V8采用Ignition字节码+TurboFan优化，类型突变触发去优化；闭包、this绑定等均在解析期固化。
JavaScript 不是“被解释执行”的脚本语言，而是由引擎（如 V8、SpiderMonkey）先编译成字节码或机器码再执行——所谓“解析”，实际是词法分析 + 语法分析 + 作用域绑定 + 编译优化的组合过程。
JavaScript 引擎真正解析的是 AST，不是文本
你写的 const x = 1 + 2; 进入引擎后，第一关不是执行，而是被拆解为抽象语法树（AST）。引擎不关心空格、换行、注释，只识别 token 类型（Keyword、Identifier、NumericLiteral 等）和结构关系（比如 BinaryExpression 表示加法）。
- 可用 AST Explorer 粘贴代码，实时看 V8 或 Babel 如何生成 AST
-
eval()和Function()构造函数会触发**运行时重新解析+编译**，性能差且有安全风险，避免在循环或用户输入中使用 - 模板字符串中的表达式（
`${x + 1}`）会在解析阶段被识别为嵌套的TemplateLiteral节点，不是字符串拼接时才计算
V8 的 Ignition + TurboFan 流程决定“怎么跑”，不是“是否编译”
V8 并不全量生成机器码。它用 Ignition 先产出轻量字节码（快启动），再对热点函数用 TurboFan 做激进优化（内联、去虚拟化、类型推测）。一旦类型假设失败（比如 add(1, 2) 后又调用 add('a', 'b')），就会去优化（deopt），切回字节码执行。
需要创建、读取、编辑或处理 Word 文档（.docx / .dotx）时使用。触发词：'Word'、'word 文档'、'.docx'、'生成报告'、'制作合同/简历/方案/说明书'、'提取 word 内容'、'在文档里查找替换'、'给文档加页眉页脚/目录/表格'。也用于把任意内容排版成一份正式的 Word 文件。不要用它处理 PDF、Excel 或无关编程任务。中文创作场景尤其适合：小说大纲稿、投稿文档、合同、简历、工作总结。
- 用 Chrome DevTools 的
chrome://tracing可捕获 deopt 事件，定位“意外降级”的函数 -
console.time()测不出真实优化效果——首次执行走 Ignition，第 2–10 次才可能进 TurboFan，建议用--allow-natives-syntax加%OptimizeFunctionOnNextCall(fn)手动触发 - 对象属性访问（
obj.x）若出现属性动态增删（delete obj.x或混用不同形状对象），V8 会放弃隐藏类优化，退化为字典查找
作用域与闭包在解析期就固化，不是运行时“找外层”
引擎在语法分析阶段就确定每个变量属于哪个词法作用域，并记录在 ScopeInfo 中。闭包不是运行时“向上搜索”，而是函数对象内部持有一个指向其创建时词法环境的引用（[[Environment]] 内部槽）。
立即学习“Java免费学习笔记（深入）”；
-
var声明会被提升（hoisted），但只是声明，不包括初始化；let/const有 TDZ（暂时性死区），解析期已标记该变量在初始化前不可访问 -
with和eval会禁用大多数静态优化，因为它们让作用域链在运行时才可确定，现代引擎直接拒绝内联或提前编译含with的函数 - 箭头函数没有自己的
this，这个绑定规则在解析阶段就写入函数定义，不依赖调用位置
真正难调试的从来不是“JS 怎么跑”，而是“引擎基于哪些静态信息做了什么优化假设”。一旦运行时行为违背这些假设（比如类型突变、原型篡改、动态作用域干扰），性能断崖或语义偏差就出现了——而这些细节，不会出现在源码里，只藏在 AST、字节码和优化日志中。
