凡是写过 JavaScript 的人多半都遇到过这种“薛定谔的变量”代码里明明是先使用、后声明结果它不报错反而返回一个 undefined函数表达式赋值给变量之后想提前调用却被抛出一个 TypeError。这些乍看很“迷”的行为底层其实都指向同一个机制——作用域提升Hoisting。而真正把这个机制落地的是 JavaScript 引擎。日常开发里我们打交道最多的就是 V8。这篇文章不打算拽太深的内核源码而是把 V8 从拿到一段源码、到真正把代码跑起来这条流水线上跟“作用域提升”有关的几个关键节点讲清楚解析器究竟在什么时候干完了哪些事、变量和函数是怎么被提前登记的、作用域链在运行时如何被检索以及我们如何通过字节码和调试工具亲眼看到提升留下的痕迹。适合刚准备碰 V8 源码的同学也适合写了好几年 JavaScript 却没认真捋过“编译时”与“运行时”边界的工程师。1. 从源码到可执行结构V8 是怎么“读”代码的1.1 第一步不是“执行”而是把字符串变成数据结构任何一段 JavaScript 代码对 V8 来说最初都只是一串字符。它首先要经过 Scanner分词器把这串字符切成一个一个的 Token。Token 就是带类型的词法单元比如关键字function、标识符foo、运算符、数字、字符串等等。这个过程叫 Tokenize它做得非常机械碰到字母就尽量拼成标识符碰到数字就尽量读成数值碰到引号就解析字符串。Token 流接下来会交给 Parser解析器。Parser 按照 JavaScript 的语法规则把 Token 组合成一棵抽象语法树AST。这棵树才是 V8 真正“理解”的代码结构每个节点代表一个语法成分比如VariableDeclaration、FunctionDeclaration、BinaryExpression、IfStatement。很多人以为代码执行从“逐行读”开始其实 V8 从来不逐行读它先把整段代码变成一棵结构化的树再去处理这棵树。这一步非常关键因为作用域提升并不是“运行时突然想到把变量挪个位置”而是在构建 AST 的过程中就已经定好了哪些名字属于哪个作用域、这个变量是 var 还是 let、那个函数声明挂在哪个层次。可以说提升的本质是编译期的名字登记不是运行时的魔法搬家。1.2 预解析与懒解析V8 故意“偷懒”的地方V8 解析器有一个很反直觉的设计它不会把脚本里的每一个函数都立刻完整解析。对于暂时没有被调用的嵌套函数它只会做一次“预解析”PreParse只检查语法错误、收集必要的作用域信息但不生成完整的 AST也不展开函数内部细节。等到函数真正被调用前再去完成完整解析。为什么要这样因为实际项目里大量函数是定义了但很少被调用的甚至有些是库代码里永远跑不到的路径。如果一上来就把全部函数解析成完整 AST内存和启动时间都会爆炸。V8 选择把成本推迟到“可能需要”的那一刻这个机制叫惰性解析Lazy Parsing。作用域提升和懒解析之间的关系很有意思当一个函数被整体提升时V8 可以提前知道这个函数的存在但不会急着把它内部也解析完。也就是说外层作用域在编译期就能看到“这里有函数 foo”但 foo 内部有哪些变量、有哪些提升是等 foo 真正执行前才去“补课”的。1.3 提正在“哪个工序”里发生再往下去V8 拿到 AST 之后会交给 Ignition 解释器生成字节码然后字节码再由解释器逐条执行当某段代码被多次执行、成为热点后TurboFan 优化编译器会把字节码编译成更高效的机器码。这也是 V8 著名的“解释执行 JIT 编译”双轨制。但作用域提升并不发生在“执行字节码”这一步发生在更早的解析和 AST 处理阶段。更准确地说是在作用域分析Scope Analysis时V8 会把当前函数内部声明的变量、函数、参数整理成一张“作用域成员表”。这张表会记录每个名字的存储位置有些变量放在栈上有些变量放在上下文对象里有些只能通过全局对象访问。接下来生成字节码的时候就直接依据这张表去给变量分配槽位、生成初始化指令。所以如果你问我“提升到底是怎么实现的”我的回答是八个字编译期登记运行时初始化。变量和函数并不是真的被“移动”到了文件开头而是当作用域被创建时V8 就在内存里把该出现的名字先占好了位置然后再逐条执行代码、逐个把值填进去。2. 三种提升形态V8 在编译期记的“账本”2.1 var 声明先到账一个 undefined在作用域入口处V8 会给 var 声明的变量分配一个存储位置并且立刻放进一个默认值undefined。这就是“var 提升”的全部真相。比如这段代码function demo() { console.log(a); // undefined var a 42; }按直觉console.log(a)应该报ReferenceError因为a还没定义。但 V8 在解析demo函数时已经知道了var a的存在并在函数执行上下文创建时把a这个槽位初始化成了undefined。等到执行console.log(a)时顺着作用域链找到的a就是一个已经存在但值为undefined的变量。值得强调的是V8 会把var a 42这条语句拆成两件事声明a这件事发生在进入作用域时而赋值a 42这件事仍然留在原来的代码位置。你可以把 var 声明理解成“提前签收了一个空包裹”包裹里的东西要等到快递单上写的那个时间点才真正放进去。2.2 函数声明连人带能力一起提前报到函数声明的提升比 var 更彻底。它在作用域创建时不光分配名字槽位还会直接创建出完整的函数对象并把名字绑定到这个函数对象上。所以在声明之前调用一个函数声明形式的函数不仅不会报错还能正常工作console.log(add(2, 3)); // 5 function add(a, b) { return a b; }从 V8 的视角看它在解析阶段发现了function add这个函数声明于是分配了一个函数字面量并且在生成字节码时在函数入口处安排了一条CreateClosure指令。这条指令会基于当前上下文和内部函数信息创建出可调用的闭包对象把它存到add这个槽位中。整个过程先于任何业务代码执行完毕因此后面的add(2, 3)自然拿得到函数。这里面还有个细节函数声明在提升时已经捕获了当时所在的作用域链所以闭包也一并形成了。即便函数内部没用到外部变量V8 也会把上下文关系记录下来因为引擎无法静态预知函数内部将来会不会访问外部变量——毕竟惰性解析还没展开内部代码。2.3 let 和 const登记了但没有值let 和 const 其实也会提升。很多人误以为“let 不提升”是因为它在声明之前访问时会抛出ReferenceError看起来像是“没有这个变量”。但这恰恰说明它是提升了的如果一个变量完全没有被登记访问时应该报“变量未定义”而现在报的是“初始化之前不能访问”这正说明 V8 知道这个变量存在只是不允许你现在碰它。V8 内部用一个特殊标记来表示“这个变量已经登记但尚未初始化”。这个标记在 V8 的术语里被称为“空洞”The Hole。当代码访问一个 let/const 变量时V8 会检查它对应的槽位里是不是空洞如果是就抛出我们熟悉的ReferenceError: Cannot access x before initialization。所以 let/const 提升的状态可以理解成“签收了空包裹但包裹上贴着‘未初始化’的封条”。封条要到声明语句真正执行时才会被撕掉在声明语句之前任何读取、赋值、作为参数传递等行为都会被引擎拒之门外。这个时间段就是常说的“暂时性死区”Temporal Dead ZoneTDZ。3. 提升之后怎么被找到执行上下文与作用域链3.1 VariableEnvironment 与 LexicalEnvironmentECMAScript 规范里每个执行上下文都包含两个环境变量环境VariableEnvironment和词法环境LexicalEnvironment。最初这俩指向同一个环境对象但随着 ES6 块级作用域的出现它们开始分道扬镳。简单说变量环境主要管 var 声明的变量和函数声明词法环境则叠加管 let、const、class 这类块级绑定。每当 V8 进入一个块比如if块、for循环体、try块它会基于当前词法环境创建一个新的词法环境作为外层环境的“子层”。块里的 let/const 声明就登记在这个新环境里等代码离开这个块这个环境也随之销毁。这也是为什么var能“穿透” if 块、for 循环而let不能。var 的登记目标始终是当前函数或全局的变量环境与块级词法环境无关。eslint 为什么老劝你别用 var除了风格原因背后其实也有引擎作用域模型的因素var 的归属范围太大容易造成变量污染。3.2 名字查找作用域链不“查”还好一查就是一条链当代码里出现一个变量名xV8 在生成字节码时通常不是“运行时从最外层一层层找”而是尽可能在编译期就把x解析成确定的槽位索引。这个静态解析过程基于解析阶段建立起来的作用域层级。举个例子const globalMsg hello; function outer() { const outerMsg world; function inner() { console.log(globalMsg outerMsg); } return inner; }解析inner函数时V8 会建立一张“作用域信息表”记录inner当前看到的作用域链有函数自身作用域 → outer 函数作用域 → 全局作用域。等访问outerMsg时解析器发现它不在 inner 自身作用域里而是在上一层 outer 作用域里于是会把它标记为一个“上下文槽位”的访问。运行时字节码直接通过当前上下文的父级指针逐级找到outerMsg所在的上下文命中的是具体的槽位索引并不需要真的遍历整个作用域链做字符串比较。这正是 V8 执行 JavaScript 比很多解释型语言快的原因之一作用域提升已经把名字的归属问题提前定死了运行时只剩下“按索引取数”这个极快的操作。我们把“作用域链查找”理解成一条链是没错的但实际在 V8 中链上的每一级都会在编译期被尽可能固化成索引偏移。3.3 块级作用域让“提升”变得更立体ES6 之前理解提升基本是“函数级”的一个 var 声明在最内层 for 循环里也会被提升到整个函数顶部。ES6 之后加入 let/const作用域单位细化到了块导致“提升”这件事出现了一个全新的维度。比如 for 循环头部的let i它既不提升到函数作用域也不是简单地提升到循环体外层。更有意思的是每次迭代都会生成一个独立的词法环境里面保存着当前迭代的i值。否则下面的经典代码就不会输出 0、1、2而会输出三次 3for (let i 0; i 3; i) { setTimeout(() console.log(i)); }V8 是如何做到“每轮都有一个新 i”的答案是在循环体的执行过程中作用域不是创建一次而是每迭代一次就复制一份词法环境把i的值拷进去再让闭包捕获这份新环境。这个机制极大依赖解析阶段对块级作用域的精细划分也可以说是“提升 块作用域 闭包”三者交织出的脑洞设计。4. 用字节码亲眼看看提升Ignition 的底层小动作4.1 构造一个能“暴露”提升的实验场景空谈概念容易飘我们直接请出 V8 的字节码输出。如果你有一个基于 V8 的运行时环境比如浏览器内核或 Node可以加上打印字节码的参数去运行一小段代码。我用下面这个例子来演示function testHoisting() { console.log(value); console.log(add(1, 2)); console.log(count); var value 10; function add(a, b) { return a b; } let count 99; } testHoisting();预期表现是console.log(value)输出 undefinedadd(1, 2)正常输出 3console.log(count)抛出 TDZ 错误。这三分支分别对应 var、函数声明、let 三种提升形态。把这段代码交给带字节码打印参数的运行时会看到与本文描述高度一致的指令序列。4.2 CreateClosure 与上下文槽的初始化指令在打印出的字节码中函数入口附近最先出现的通常包括CreateClosure指令。它接收一个内部函数索引和一个反馈向量槽位作用就是把add这个函数对象创建出来并绑定到对应槽位。紧接着会看到给value赋初始值的操作加载一个小整数 undefined然后写入某个栈槽或上下文槽。这对应的正是 var 提升时代的“先到账一个 undefined”。字节码里还会出现类似StaCurrentContextSlot或StaContextSlot这样的指令表示把值写入当前上下文的指定槽位。当你看到这些指令出现在函数体内、但源代码里明明还没写赋值语句时就知道 V8 正在执行“提升后的初始化动作”。反过来你在源代码里写的value 10对应的是字节码中更靠后的另一条存储指令。声明和赋值被拆成了两条指令分布在不同的执行时点——这就是提升在字节码层次留下的最直观证据。顺带说一句如果你尝试把var value去掉编译器就不会生成那一条 undefined 预初始化指令。这也是为什么我们用“声明提前”而不是“赋值提前”来解释提升真正被提前的是绑定行为赋值永远待在原处。4.3 TDZ 是怎么被“拦”下来的let 变量声明之前的访问在字节码里能看到一个专门指令ThrowReferenceErrorIfHole。它的语义是检查当前变量槽位的值是不是“空洞”标记如果是立刻抛出 ReferenceError。在let count 99这条声明执行之前count的槽位里存放的是空洞值。任何对它的读取指令前解析器都会插入一条ThrowReferenceErrorIfHole来把关。这条指令存在等于把 TDZ 变成了一道物理闸门你进不了门不是因为门不存在而是门锁着钥匙是那条声明语句。等到let count 99执行V8 把 99 写入槽位、清掉空洞标记之后后续访问才畅通无阻。这也能解释一个很多人踩过的坑typeof 一个未声明的变量不会报错返回 “undefined”但 typeof 一个处于 TDZ 的 let 变量会直接抛错。因为 typeof 对未登记名字走的是一套宽松检查路径而 TDZ 变量已经被登记了它走的是“先检查空洞、再读值”的严格路径所以直接撞上了ThrowReferenceErrorIfHole。5. 提升的常见误判与实战排查技巧5.1 “提升到函数顶部”不等于“定义了”我面试过不少候选人能熟练背诵“var 提升、函数提升、let 不提升”可一到实际排查就翻车。最典型的误解是把“提升”等同于“声明已定义”。实际上提升只完成了“绑定名字”这一步值的初始化是另一回事。var 绑定后的初始值是 undefinedlet/const 绑定后的初始值是“禁止访问”的空洞状态只有函数声明会立刻绑定为可调用的函数对象。另一个相关误解是认为提升会把变量“搬到文件顶部”。如果真按字面搬家那文件最顶部引用一个变量应该等于引用“搬家后的变量”。但对 var 来说文件最顶部其实仍然在函数作用域内所以结果依然是 undefined而对 let 来说文件最顶部同样处于 TDZ。所谓“搬到顶部”只是为了方便初学者理解“先声明后使用”的假象真正重要的是“绑定发生在作用域创建时”。5.2 函数声明与函数表达式的分岔路这段代码非常经典console.log(foo); // undefined console.log(bar); // ReferenceError: bar is not defined var foo function bar() {};foo是 var 声明的变量提升后初始值是 undefinedfunction bar() {}作为表达式的一部分并不会触发函数声明的提升。函数表达式必须等执行到赋值语句时才会把函数对象赋给foo。如果写var foo function bar() {}再提前调用foo()会得到TypeError: foo is not a function。理解这两条路径对排查“为什么这里调用报错、那里调用正常”非常有用。遇到类似问题先判断目标名字的绑定形式是函数声明、var 声明还是 let/const 声明。然后再看访问点在声明语句之前还是之后。一个简单口诀var 提前给 undefined函数声明提前给函数let/const 提前给异常。5.3 提升会影响性能吗经常有同学担心变量提升是不是会让作用域变得很复杂从而拖慢性能答案在 V8 的实际实现中是否定的。提升反而帮助了性能优化。因为提升意味着变量绑定信息在编译期就已经确定V8 不需要在运行时动态扫描作用域里有哪些变量。TurboFan 做优化编译时可以基于这套静态信息把变量直接映射到寄存器或栈固定偏移上免去每次访问都做哈希查找。甚至对于未被闭包捕获的变量V8 可以直接分配在栈上作用域一结束就释放成本极低。真正需要留神的不是提升本身而是闭包对变量生命周期的影响。一个变量如果被内部函数引用就无法放在栈上简单释放必须进入上下文堆对象。过度使用闭包或者在大循环里反复创建闭包才会给引擎带来真实的分配压力。这个锅不应该甩给提升。5.4 在调试器里直接查看 Scope实战排查提升问题时最好用的工具是调试器的 Scope 面板。在浏览器开发者工具里任何断点处都能看到当前作用域链上每一层的变量列表通常分为 Local、Block、Closure、Global 这几类。其中 Block 就是块级词法环境的体现Closure 则是闭包捕获的上下文。我曾经排查过一个很隐蔽的问题一个 for 循环里声明的 let 变量循环结束后在外面还能访问到。后来用调试器一看发现那根本不在循环的块作用域里而是我误把 let 写在了函数体顶层。Scope 面板把每一层环境里的绑定一览无余地列了出来结合断点往前推很快定位到问题。一个建议多利用“Scope”面板去读作用域层级。比如在 var 声明语句之前打断点看该变量出现在哪个 Scope 层级、值是不是 undefined在 let 声明之前打断点看对应变量是否显示uninitialized或unavailable。亲眼见过这些状态之后你对提升的理解会从“背概念”变成“有手感”。5.5 从一个生产环境的经典报错说起最后分享一个很常见的线上场景。某段代码在条件分支里声明了一个 var 变量并尝试在分支外读取。开发者觉得“分支没进就不应该存在这个变量”结果读出来是 undefined而不是报错。这不是引擎出 bug而是 var 被提升到了整个函数顶部与是否进入分支毫无关系。更隐蔽的是另一个场景代码在 try 块里const data parse(x)catch 块里想访问data。结果编辑器直接标红运行时也报Cannot access data before initialization。这是因为 const 绑定到了 try 块的词法环境try 块之后根本不处于这个环境的作用域内。想要跨块共享就必须把声明放到外层作用域。这个例子跟提升无关但它提醒我们块级作用域和提升机制混在一起时出问题的概率远高于单独理解一个概念。我的实际体会是遇到作用域相关的诡异行为先别急着怀疑引擎先在纸面上画出“声明语句在哪一层、访问语句在哪一层、绑定类型是什么”三条信息。90% 的问题都能在这一张图上现出原形。提升这件事说到底就是引擎在告诉你一句话名字可以先占位但占位不代表有值有空位、有 undefined、有禁入区三种状态对应三种不同的“先使用后声明”。把这三种状态的边界吃透JavaScript 作用域这块基本就稳了。