★ FEATURED ARTICLE 1. 从一段小代码说起V8到底在背后做了些什么先丢一段大家天天见面的代码console.log(myName); // 输出undefined var myName 小明; sayHello(); // 输出Hello, 小明 function sayHello() { console.log(Hello, myName); }第一次看到这个结果时很多人的反应是“JavaScript 不是解释执行的语言吗怎么还能先调用后声明”如果你也被这个问题困扰过那恭喜你你已经摸到了 V8 内部机制的门槛。这个现象的正式名字叫做“变量提升”和“函数提升”而它的根源其实不在“运行时”而是在“编译阶段”。我这些年调试过不少诡异的前端Bug什么“明明赋值了却读出来undefined”“函数声明位置写错了结果被覆盖”“const声明的变量被误认为是全局污染”最后排查到根上十有八九都绕不开 V8 在解析和执行这段代码之前所做的那一堆“看不见”的动作。如果你只是把JavaScript当作一门“写出来就能跑”的语言那很多坑你是踩不完的。因为JavaScript跟传统编译型语言最大的区别在于它不是提前把整个源文件一次性编译成机器码而是由引擎在浏览器和Node.js里绝大多数时候是V8在运行时先把代码“过一遍”——解析、生成字节码、再解释或编译执行。这个过程里藏着作用域提升、词法作用域、闭包判断等一大串内容理解了它们你写代码的时候心里会非常踏实。这篇文章就从“V8解析执行代码”这条主线切入把作用域提升也叫变量提升、声明提升这件事彻底讲透。不管你是刚入门的前端新人还是写了好几年JavaScript的老手只要你还对“引擎内部发生了什么”有一点点好奇这篇文章都值得你花十分钟读完。我会把引擎的解析流程、作用域分析的原理、几个我实际踩过的坑、以及怎么通过V8字节码去“看到”引擎的行为全部揉在一起讲清楚。2. V8解析执行流程先“看懂”代码再“跑”代码想理解作用域提升你得先知道V8拿到JavaScript源码之后走的是一条什么样的流水线。整条链路可以简化为四个阶段源码字符串 - 分词/词法分析 - 语法分析生成AST - 生成字节码并执行必要时再编译为优化机器码。2.1 从源码到Token词法分析在做什么V8第一步做的是“拆词”。我打个比方就像你收到一封手写信要读懂它得先把一句话拆成一个个字和词再去理解每个词的意思。词法分析Scanner/Lexer就是干这个的。它把源代码字符串拆成一个个最小的语法单位叫Token。比如这段代码var x 1;会被拆成这些TokenToken类型内容说明Keywordvar声明关键字Identifierx变量名Operator赋值运算符Number1数字字面量Punctuator;分号这一步本身还没有“作用域提升”的影子它只是机械地把字符流变成一串有类型的Token流。但它的作用很重要只有把代码拆得足够干净下一步语法分析才能正确构建出代码的“骨架”。2.2 作用域提升的真正起点语法分析与AST构建V8第二步是语法分析Parser。这个词听起来很学术其实做的就是“组句”把Token流按照JavaScript的语法规则组合成一棵结构化的抽象语法树AST。你可能觉得AST只是一棵“语法树”跟作用域提升有什么关系关系大了。V8在构建AST的过程中并不只是看看语法对不对它还顺手做了一件事把当前作用域里所有通过var声明的变量、通过function声明的函数、以及通过let/const声明的变量提前登记到一个“作用域对象”里去。这个过程就是作用域提升的根基。我举一个更容易理解的类比这就像公司开年会前HR先提前统计各部门会到场的人数哪怕人还没到名单已经列好了。JS代码在真正“跑”之前V8已经全局扫了一遍声明把变量名和函数名写进了当前作用域的“名册”。等到执行阶段变量名已经在名册里了只不过还没有值所以读出来是undefined。V8解析AST时具体做了这么几件事识别var声明给变量分配“位置”但不赋值默认值是undefined。识别function声明把整个函数体存入内存所以函数不但“名字提升”连“内容”也一起提升。识别let/const声明把名字登记进作用域但做上“未初始化”的标记在赋值前访问会触发运行时错误后面详细说。所以“作用域提升”最准确的理解是它是在代码执行之前、由解析阶段完成的一种声明登记行为。它不是运行时把变量“搬”到了顶部而是在引擎的“准备阶段”就已经把声明信息挂到了作用域上。2.3 忽视解析与执行分离是很多bug的根源我经常看到有人把“解析”和“执行”混为一谈这会导致对代码行为的误判。举个例子foo(); // 可以正常输出 function foo() { console.log(我是函数); }这行代码之所以能正常工作不是JS引擎“边翻译边执行”时碰巧看到了后面的函数声明而是因为V8在正式执行之前已经把整个脚本的AST构建完毕函数声明已经被完整地注册到了当前作用域。等执行到foo()这一行时foo这个名字早就存在于内存里了。如果JS是“读到一行解释一行”的模式那么执行到第一行时后面的function foo根本还没被看到必然报ReferenceError。所以“解释执行”这个说法严格来说是片面的。V8是一个“先解析、后执行”的引擎只是解析和执行都在运行时完成让你感觉不到边界。理解了这条流水线你就能明白为什么“变量提升”是一个编译期行为而不是运行期技巧。也正因为它是编译期行为才会有一系列看起来“违反直觉”的细节比如函数提升优先级高于变量提升、let/const会形成暂时性死区、块级作用域内声明不会被提升到外层等等。这些都是解析阶段作用域登记规则的具体体现。3. 作用域提升的完整拆解变量提升、函数提升与TDZ作用域提升要分两类看一类是var和function带来的真正“提升”另一类是let/const带来的“登记但不初始化”。这两类的行为完全不同弄混了很容易写出隐蔽Bug。3.1 var变量提升名册上有名但值未到var声明是历史最悠久的声明方式。它的行为可以总结成一句话声明被提升到当前作用域顶部赋值留在原地。console.log(a); // undefined var a 10;这段代码在V8的执行视角里等价于var a; // 提升声明 console.log(a); // undefined a 10; // 赋值留在原地注意这里的“提升”不是字面意义上把代码行搬上去而是在解析阶段V8已经给a分配好了“变量槽”初始值为undefined。等执行到赋值语句时a才真正有了值。var的作用域规则是以函数为边界。在函数内部声明的var变量不会被提升到函数外面但会被提升到函数作用域的顶部。还要注意如果是全局作用域下用var声明变量它会成为全局对象window的属性。var globalVar 我可以挂到window上; console.log(window.globalVar); // 我可以挂到window上这一点在模块化开发或者严格模式下影响不大但在老代码里很容易引发全局污染问题。我当年排查过一个线上bug就是因为某个公共脚本里用var声明了一个通用变量名结果跟页面里另一个脚本的同名变量互相覆盖查了半天。从那以后我在新代码里基本不用var。3.2 function声明提升既提升名字也提升函数体function声明的提升跟var有一个重要区别var只提升声明不提升赋值而函数声明是把整个函数体都“完整”放到内存里的。所以在函数声明之前调用它可以正常执行。greet(张三); // 输出你好张三 function greet(name) { console.log(你好 name); }这背后的原因是V8在解析阶段遇到function声明的节点后会直接创建一个函数对象并绑定到当前作用域这个函数体是完整的、可调用的。所以函数提升不仅仅是“名字提升”是“实体提升”。这里有一个经典考点当var声明的变量名和function声明的函数名同名时谁说了算console.log(typeof duplicateName); // function var duplicateName 值; function duplicateName() {}这个输出是function。原因在于解析阶段函数声明的绑定先被放入作用域随后var声明发现同名变量已存在就不再重复创建绑定赋值操作在运行时也不会影响函数体的存在。到了执行阶段第一行打印时duplicateName还是函数。但如果执行顺序再往后一点var duplicateName 值; function duplicateName() {} console.log(typeof duplicateName); // string这一次输出的就是string了。因为赋值语句在运行时覆盖了函数引用。所以函数提升优先级高但不代表函数比赋值“更持久”只是“提升优先级高”而已。这跟作用域链条、执行顺序叠加在一起容易产生非常难判断的结果。实际写代码时尽量避免同名声明才是正道。3.3 let/const的暂时性死区TDZ为了“更好”付出的代价let和const是ES6引入的块级作用域声明。它们的提升行为跟var完全不是一回事——严格来说let/const也有“声明登记”行为但没有“初始化默认值”。V8在解析阶段遇到let/const声明时同样会把名字登记到作用域内但这个绑定处于一个特殊的内部状态可以理解为“未初始化、不可访问”。ES规范给这个状态起了个名字叫暂时性死区Temporal Dead ZoneTDZ。console.log(tdzTest); // 报错ReferenceError: Cannot access tdzTest before initialization let tdzTest hello;报错不是因为它“不存在”而是因为它处于TDZ状态禁止在赋值前访问。用代码冒烟测试你甚至能typeof一个TDZ状态的变量都会报错typeof tdzTest; // ReferenceError为什么typeof一个未声明变量都不报错反而typeof一个TDZ变量会报错因为V8区分了两种状态真不存在和“存在但未初始化”。typeof undeclaredVar时作用域里没有这个名字引擎会宽容地返回undefined但typeof tdzTest时作用域里已经有这个名字了只是标记为“未初始化”引擎会严格报错。这个设计初衷是为了抓出“顺序错误”的代码。var因为默认初始化为undefined所以可以在声明前访问但这实际上掩盖了很多逻辑错误。let/const把这块遮羞布扯掉了强制你“先声明再使用”。我在写代码时确实因为TDZ踩过一次坑。当时在一个类里面某个实例字段的初始化依赖于另一个字段class Order { constructor() { this.total this.price * this.count; // 如果count先未初始化会报错 } price 10; count 2; }类字段是按声明顺序初始化的跟TDZ的原理一致。如果我把total放在price和count之前访问this.price时就会报TDZ错误。理解了引擎的登记逻辑这类问题定位起来就非常快。3.4 块级作用域let/const不只是“var的替代品”let/const之所以跟var产生行为差异核心在于块级作用域边界。var以函数为边界而let/const以“最近的块”为边界——什么算块{}、if、for、while、switch都算。if (true) { let blockVar 只在块内有效; } console.log(blockVar); // ReferenceError: blockVar is not defined在V8的解析阶段遇到let/const时它会把绑定挂到当前的“块作用域”上去而不是函数作用域。这也是为什么在for循环里用let声明循环变量每次迭代都会创建新的绑定闭包可以正确捕获到每一次迭代的值for (let i 0; i 3; i) { setTimeout(() console.log(i), 100); // 输出 0 1 2 }如果这里把let换成var输出会变成3 3 3。原因很简单var i被提升到了函数作用域整个循环共用同一个i变量等定时器到期执行时i已经是最后的3了。而let i在每次迭代时由解析阶段建立新的词法环境3个闭包各自绑定不同的i值。4. 作用域提升的找位置机制词法作用域与作用域链理解了“提升把声明登记到哪里”之后下一个关键问题就是执行代码时一个变量名是怎么被找到的这就涉及词法作用域Lexical Scoping和作用域链Scope Chain了。4.1 作用域不是“调用位置”决定的是“写代码位置”决定的“词法作用域”的意思是一个变量属于哪个作用域在代码书写的时候就决定了而不是在运行时根据调用栈动态变化。换句话说作用域是由源代码的结构决定的跟函数的调用方无关。let globalName 外部名字; function outer() { let innerName 内部名字; function inner() { console.log(globalName); // 能访问到全局 console.log(innerName); // 能访问到outer作用域 } inner(); }inner函数里访问globalName能往上找到全局作用域访问innerName能找到outer函数作用域。这些都是代码写出来就定死的。不管从哪个函数调用inner它都只能看到这条静态的嵌套关系链。很多初学者会把作用域链误认为跟调用栈有关实际上它们是不同的东西。调用栈是动态的记录函数执行顺序作用域链是静态的由函数定义时的嵌套关系决定。V8执行引擎在解析阶段构造函数时会同时记录下它的“外层作用域引用”这就是闭包形成的根基。4.2 作用域链查找从内往外一层一层看作用域链的查找逻辑很简单先在当前作用域里找变量名找不到就去外层作用域找一路找到全局作用域。全部找不到就报ReferenceError: xxx is not defined。这里的“外层作用域”指的不是调用者而是定义层级的词法嵌套。比如let a 1; function foo() { let b 2; function bar() { let c 3; console.log(a b c); // 能访问到所有 } bar(); }bar内部查找a时当前作用域没有接着去foo作用域找还没有再去全局作用域找找到了。这条链条是bar作用域 - foo作用域 - 全局作用域。V8在运行时为了加速作用域链查找会为当前函数作用域生成Context上下文结构里面保存了对外层变量的引用。这也是闭包能“记住”外层变量的底层原因函数对象内部带着一个隐藏的[[Scope]]属性指向定义它的作用域链。4.3 作用域提升与作用域链的关联为什么“提升”的位置那么重要有一个我蛮想强调的点作用域提升并不是“提升到全局”而是“提升到声明所在的那个作用域”。很多人把“提升”误解成“变量跑到文件顶部了”其实不是。看这个例子function test() { console.log(a); // undefined var a 1; } test(); console.log(typeof a); // undefined在外层访问不到avar a在函数内部被提升到test函数的顶部但它不会跑到全局作用域。所以函数外访问a依然是undefinedtypeof安全返回undefined。这说明提升的范围被严格限定在“声明所在的作用域边界内”。理解这条规则对避坑非常有帮助你在一个函数里用var声明的变量无论嵌套多少层都只会在函数作用域里找得到不会污染全局但你如果在全局作用域用var声明那它确实会挂到全局对象上。5. 用代码现场观察V8的行为从字节码到调试技巧前面讲的都是原理下面我分享一些实际“观察”V8行为的方法。在我看来理解作用域提升最快的方式不是背规则而是亲手看V8到底产出了什么。5.1 使用Node.js打印V8字节码V8生成字节码之后会通过解释器执行。如果你用的是Node.js环境有一种非常简单的方式可以直接看到字节码用--print-bytecode参数运行脚本。我建一个测试文件test.jsfunction demo() { var x 1; let y 2; return x y; } demo();然后在命令行执行node --print-bytecode test.jsV8会打印出大量的编译信息。重点看跟demo函数相关的内容核心字节码大致长这样[generated bytecode for function: demo] Parameter count 0 Register count 4 0x... 0 LdaSmi [1] // 加载常量1到累加器 2 Star r0 // 存到寄存器r0 3 LdaSmi [2] // 加载常量2到累加器 5 Star r1 // 存到寄存器r1 6 Ldar r0 // 把r0读入累加器 8 Add r1 // 与r1相加 9 Return // 返回字节码层面能看到什么可以看到var x和let y都没有生成额外的“赋值前检查”字节码因为在解析阶段绑定的创建已经被处理掉了。let的TDZ检查在字节码里会表现为一个ThrowReferenceErrorIfHole指令当访问未初始化的let绑定时会触发。比如你故意在声明前访问function tdzDemo() { console.log(tdz); let tdz 1; } tdzDemo();字节码里会出现类似LdaTheHole LdaNamedProperty [tdz] ThrowReferenceErrorIfHole这个TheHole是V8内部用来标记“未初始化绑定”的特殊值。看到这段字节码你就明白TDZ不是语法层面的魔术而是引擎在运行时用一个内部哨兵值判断“你到底初始化了没有”。自己跑一次字节码打印比死背十遍规范都管用。强烈建议对引擎好奇的人试试。5.2 利用调试工具实时观察作用域变化除了字节码日常调试还有一个更轻量的方式利用Chrome DevTools或Node.js的调试器在断点位置查看作用域面板。打开DevTools的Sources面板在函数内部打断点右侧的Scope栏会列出当前可见的作用域链比如Local-Block-Global。这能直接帮你验证“作用域提升之后变量处于什么状态”。举个例子function debugScope() { console.log(m); // 断点打在这里 var m 1; } debugScope();在console.log(m)这行打上断点右侧Scope栏的Local里就能看到m: undefined。这就用事实证明了执行到这一行时m已经被登记为undefined并没有报“未定义”。如果把代码改成let m 1在断点处你会看到m显示为一个异常状态有的版本显示uninitialized有的干脆不显示。不管哪种展示本质上都是在告诉你这个绑定还在TDZ里不能碰。我平时写复杂组件时遇到“看似应该能访问却报错”的情况第一反应就是打两个断点对比Scope面板里变量的状态。一旦看到undefined或uninitialized问题根源基本就锁定在声明提升相关的逻辑上。5.3 副作用与性能作用域分析如何影响优化在V8的优化编译管线里作用域分析还直接影响最终生成的机器码质量。TurboFanV8的优化编译器在把字节码编译成机器码时会依据作用域链信息决定怎么分配寄存器、怎么消除冗余检查。如果函数里根本没有闭包V8会尽量把变量分配到寄存器上性能非常接近手写汇编。一旦出现闭包变量可能就得“装箱”到堆上分配的上下文对象里访问速度会慢一个档次。我实测过一个简单基准一个不含闭包的循环累加函数和一个用闭包捕获外层变量的等价函数后者耗时大约多30%~50%。原因就在于作用域链多了一层间接寻址。这不是说不能写闭包而是提醒你如果某段热路径代码性能极其敏感尽量把内部状态的访问限制在函数自己的参数和局部变量里避免不必要的上下文嵌套。这条经验算是从“解析执行机制”延伸出来的实战收益了。6. 常见问题排查与避坑指南下面是这几年我处理过的、跟作用域提升直接相关的高频问题。整理成速查表方便大家对照排查。6.1 “undefined”但不是“is not defined”很多人在控制台看到undefined时会下意识以为是“变量不存在”其实两者有天壤之别现象含义可能原因undefined变量存在但没赋值var声明被提升赋值还没执行或对象属性不存在ReferenceError: xxx is not defined变量真的不存在作用域链里根本没有这个名字ReferenceError: Cannot access x before initialization变量存在但处于TDZlet/const声明前被访问排查时要先分清这三种情况。undefined大概率是“提升后未赋值”或“逻辑执行顺序问题”is not defined则是作用域链或拼写问题TDZ报错几乎都是“代码顺序错了”。6.2 循环闭包老问题var还是let再写一次那个经典示例因为到现在依然有人在踩for (var i 0; i 5; i) { setTimeout(() console.log(i), 100); // 输出 5 5 5 5 5 }解决方案有几个将var换成let利用每次迭代创建独立绑定。使用函数包一层传参进去。使用forEach/map回调让每次迭代生成独立函数作用域。我自己的习惯是闭包捕获循环变量时默认用let如果必须兼容老环境则用IIFE传参。这种问题一旦出现对业务的影响往往很隐蔽因为日志打印出来全是同一个值一时半会儿找不到头绪。6.3 同名声明覆盖问题函数名和变量名同名时函数优先绑定但运行时的赋值会覆盖函数引用这一点很容易让人迷惑。我建议在代码规范里就杜绝同名声明而不是靠记忆去判断“到底谁覆盖谁”。ESLint里也有一条no-redeclare规则会直接报错。平时开发随手开着这条规则能省下不少脑细胞。6.4typeof的安全性与TDZ的例外typeof undeclaredVar是安全的返回undefinedtypeof tdzVar是危险的会抛异常。这一点看起来很不对称但逻辑其实是自洽的undeclaredVar在作用域里完全没有记录引擎认为“你可能只是没声明给你个undefined得了”虽然这也掩盖了不少拼写错误tdzVar在作用域里有记录引擎知道它只是还没初始化因此严格报错。实际排查代码时如果怀疑“是不是被其他变量覆盖了”可以用typeof安全探测外层变量但如果代码明确使用了let/const且顺序可能不对就别指望typeof兜底了。6.5 严格模式带来的差异ES5的严格模式对作用域规则也有一些细化。最直观的一点非严格模式下给未声明的变量赋值会隐式创建一个全局变量严格模式下这会直接抛ReferenceError。use strict; counter 1; // ReferenceError: counter is not defined我见过不少老代码依赖隐式全局变量“跑得动”一旦切到严格模式就各种崩。理解了作用域提升的规则也就能理解为什么隐式全局变量是种坏味道——它跳过了解析阶段的声明登记流程完全靠运行时动态创建极易引发命名冲突和不可预测的覆盖。6.6 避坑心得汇总新代码一律使用let/const让“声明顺序”真正有意义。函数声明避免放在条件分支里严格模式已不允许防止被引擎按规则提升到意想不到的作用域。类字段初始化顺序遵循TDZ逻辑访问前确保前置字段已初始化。如果你在维护老代码遇到奇怪的undefined先搜索一下作用域内所有同名声明。热路径函数尽量少包闭包减少上下文访问开销。复杂问题时直接看作用域链条和字节码输出别靠猜。7. 从引擎层面重新理解JavaScript的执行模型最后多聊一点扩展内容。理解了V8的解析流程和作用域提升之后你会发现JavaScript的执行模型其实跟很多“脚本语言”的印象不太一样。它有一套清晰的阶段化流程扫描 - 解析 - 字节码 - 解释执行 - 优化编译。作用域提升只是这流水线里“解析阶段”的副产品但正是这个副产品决定了我们日常编写代码时的各种行为边界。还有一个值得玩味的点为什么JavaScript要设计出变量提升这种“看起来不合常理”的机制历史原因大概是为了兼容早期的函数声明和var风格让同一个作用域内部的声明能互相引用不用强求书写顺序。到了ES6语言设计者意识到这种宽松机制带来的隐性问题太多于是引入let/const和TDZ在保留兼容性的同时给开发者提供了“更严格、更防错”的选择。所以理解V8的既有行为不只是为了应付面试更是为了在使用现代特性时知道它在底层是怎么构成的。如果你也想深入研究我建议自己动手跑一遍node --print-bytecode用几个不同案例对比观察。比如对比var、let、function声明的字节码差异观察TDZ报错对应的字节码指令甚至打印闭包函数的字节码看看它为什么能记住外层变量。这些实验做下来你对JavaScript执行机制的理解会超过绝大多数只背规则的开发者。我个人在实际操作中最有感触的一点是大部分作用域相关的Bug不是“看不懂代码”而是“看不到引擎做了什么”。一旦你学会了用调试器的作用域面板、用字节码打印这些“透视工具”那些看似玄学的问题全都会变成有迹可循的确定行为。所以遇到诡异问题别急着改代码先停下来看看V8怎么说。
阅读完成 · 觉得有帮助？
)
