JavaScript执行上下文深度解析：作用域链、this绑定与调用栈机制

做了这么多年前端我越来越觉得JavaScript里最反直觉、最容易被忽略、却几乎决定了整个语言行为模式的东西就是“执行上下文”。很多人写了好几年代码能熟练使用闭包、this、变量提升但你要是突然问他一句“执行上下文到底是什么”他大概率会愣住。这个现象很普遍因为执行上下文不像API那样有明确的调用入口它更像是一个幕后机制在每一段代码运行前悄悄搭好台子。我打算用这个“复苏日记”系列把JS引擎里那些学了又忘、忘了又学的核心机制重新捋一遍。第一章就拿执行上下文开刀因为它是一切作用域、闭包、this问题的总根源。必须先说清楚这篇文章不是翻译ECMAScript规范而是用一个实战派前端能听懂的方式把执行上下文的创建、入栈、执行、销毁、以及它和词法环境、变量环境、作用域链、this的关系彻底讲透。看完之后你应该能准确回答这几类问题为什么var会变量提升而let不会为什么函数声明能整个提升为什么闭包能“记住”外层变量为什么箭头函数的this这么特殊这背后其实都是执行上下文在起作用。1. 执行上下文到底是什么先搞懂JS运行时的“后台调度”1.1 一个反直觉的起点为什么代码在“运行前”就已经被“处理”过先从一个最简单的例子说起console.log(a); // undefined var a 10;这段代码不会报错而是打印出 undefined。很多教程会告诉你这叫“变量提升”hoisting但几乎没有人解释“提升”具体是怎么发生的。它不是JS引擎把声明物理地搬到代码顶部而是在代码真正逐行执行之前引擎已经为这段代码创建了一个“运行环境”并且提前把a这个标识符登记在环境里此时a的值默认是 undefined。这个“运行环境”就是执行上下文Execution Context。更准确地说每当JavaScript引擎准备执行一段可执行代码全局代码、函数代码、eval代码时它都会创建一个全新的执行上下文用来记录这段代码运行时的所有状态有哪些变量、函数、参数this指向谁外层环境是哪个。1.2 执行上下文不是一个“抽象概念”它是有生命周期的对象很多人以为执行上下文只是教科书上的抽象名词实际上它在引擎内部就是一个结构体/对象里面装着环境记录、外部引用、this绑定这些字段。它的生命周期分两个阶段创建阶段进入上下文时确定this绑定、创建词法环境Lexical Environment、创建变量环境Variable Environment。执行阶段逐行执行代码时完成变量赋值、函数调用、表达式求值等操作。为什么说这个机制“奇怪”因为你写代码时以为代码是一行一行从上往下跑的但引擎的实际流程是先把整个代码块“过目”一遍把声明登记好然后再开始执行。这就是很多“反直觉”行为的来源。1.3 三种执行上下文全局、函数、eval执行上下文一共三类全局执行上下文整个脚本运行时最外层、最底部的上下文。浏览器环境下window就是全局对象var声明的全局变量和函数会成为window的属性。函数执行上下文每次调用函数时创建函数执行完就销毁除非闭包把它内部的词法环境保住了。eval执行上下文eval运行时的上下文性能差、作用域混乱日常开发中基本不碰。这里有个关键点执行上下文和调用栈Call Stack是强绑定的。JS是单线程语言同一时刻只能有一个执行上下文处于“执行中”其他上下文都挂在栈里排队。这就是后面要讲的执行上下文栈。2. 一个上下文的一生创建阶段里藏着的提升真相2.1 创建阶段的三个动作变环境变量环境加this绑定进入一个执行上下文时引擎会在极短的时间内做三件事确定this绑定。对于全局上下文this指向全局对象函数上下文则取决于函数的调用方式后面专门讲this的四种绑定。创建词法环境。这是存放let、const以及函数声明的地方。创建变量环境。这是存放var声明的地方。如果你觉得词法环境和变量环境太绕可以先这样理解词法环境是ES6之后为let/const单独划的“新抽屉”变量环境是var住的“老抽屉”。两个抽屉的登记时机相同但行为细节不同。2.2 var的提升是“登记占位”let/const的提升是“画地为牢”我一直觉得“变量提升”这个翻译有点误导它容易让人以为引擎做了物理移动。我更喜欢把var的机制理解为“提前占位登记”function demo() { console.log(b); // undefined var b 2; }在创建阶段引擎在变量环境中登记了标识符b初始值为 undefined。所以执行到console.log(b)时读到的就是那个undefined占位符。到了ES6的let/const情况就微妙了function demo2() { console.log(c); // ReferenceError: Cannot access c before initialization let c 3; }注意let也有“提升”——它同样在创建阶段就被登记在词法环境里了。但JS规范规定了访问规则let声明的变量在绑定初始化之前处于“暂时性死区”Temporal Dead ZoneTDZ此时读取会直接抛ReferenceError。本质上TDZ是“登记了但禁止访问”的状态而不是“没找到”。2.3 函数提升为什么比var更彻底函数声明在创建阶段会被整个“登记完成”包括函数体console.log(add(2, 3)); // 5 可以正常调用 function add(a, b) { return a b; }函数能在声明之前调用是因为创建阶段函数声明就完成了初始化函数对象已经准备就绪不像var只给了一个undefined占位符。如果换成函数表达式console.log(add2(2, 3)); // TypeError: add2 is not a function var add2 function(a, b) { return a b; };这里add2作为var声明提前登记但值为undefined所以调用时直接报类型错误。这个差别看起来简单但特别能说明执行上下文创建阶段的“登记逻辑”。2.4 一个经典例子为什么变量提升和函数提升纠缠在一起时结果诡异来看这个常被问到的例子var a 1; function foo() { console.log(a); // ? var a 2; } foo();结果是 undefined而不是1也不是2。为什么因为foo函数上下文创建时变量环境里登记了foo内部的var a这个局部变量遮蔽了全局的a。执行到console.log(a)时作用域链找到的a是foo内部那个还没赋值的a初始值undefined。栈里执行的是“找最近的作用域链上层”而不是“找全局的a”。执行上下文一创建局部变量遮蔽全局变量这件事就已经注定了。3. 词法环境与变量环境一对容易混淆的“双胞胎”3.1 词法环境的结构环境记录加外部引用ES6规范把环境设计成“词法环境”这个复合结构。一个词法环境由两部分组成环境记录Environment Record存储标识符和值的绑定关系。外部环境引用outer指向外层词法环境这就是作用域链的物理载体。环境记录又有两种类型声明式环境记录Declarative Environment Record存储变量、函数、let/const声明和对象式环境记录Object Environment Record用于with语句以及全局环境中绑定到某个对象上。3.2 为什么var和let在“块级作用域”上表现完全不同块级作用域{}包裹的区域对let/const生效对var不生效这是执行上下文里最容易被忽视的细节if (true) { var x 1; let y 2; } console.log(x); // 1 console.log(y); // ReferenceErrorvar声明在创建时会进入“当前函数上下文的变量环境”所以if块内那个var x实际上登记在全局/函数变量环境里块对它没有隔离作用。而let声明创建的是一个新的词法环境层级这个层级挂在当前执行上下文的词法环境的“最内层”一旦离开块这一层环境记录就被丢弃了自然访问不到。3.3 for循环里let的“每轮一环境”才是可靠闭包的真相这可能是let和var在实际开发中最有杀伤力的区别直接看例子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用执行上下文的视角来解释就特别清晰var模式下循环体不产生新的词法环境所有setTimeout回调共享同一个外层环境的i回调执行时i已经是3。let模式下每轮循环都会创建一个新的词法环境并且把当前j的值绑定到该环境中三个回调分别捕获了三个不同环境里的j。这里其实就是“为每一轮迭代创建独立执行环境”机制的体现。4. 执行上下文栈单线程世界里的LIFO调度4.1 调用栈的基本机制后进先出不是设计偏好而是唯一可能JS引擎一次只能执行一个执行上下文其余上下文必须排队这个队形就是执行上下文栈也叫调用栈。浏览器和Node里的“调用栈”面板你看到的就是它。它的工作方式极其简单初始化时先压入全局执行上下文。每调用一个函数就创建该函数的执行上下文并压入栈顶。函数执行完毕或抛出异常栈顶上下文弹出销毁。脚本所有代码执行完毕全局上下文也出栈。所以栈永远遵循后进先出LIFO。这不是设计者拍脑袋定的规则而是因为函数调用本身就是嵌套的foo调用barbar必须先执行完返回结果foo才能继续往下跑天然就是后进先出。4.2 递归爆栈现场Maximum call stack size exceeded递归没有出口时就会不断压栈直到超出栈容量function recursion() { return recursion(); } recursion(); // RangeError: Maximum call stack size exceeded这个过程可以用朴素的“入栈出栈”来解释每一步调用都创建新的执行上下文压栈栈底永远是全局上下文每一层都等着下一层返回值才能出栈。一旦超出容量引擎直接抛错。这里想提醒一句真正的项目里如果出现爆栈除了排查无限递归还要考虑“一个函数内部创建了超深的嵌套对象并递归遍历”“超大数组的reduce或递归tree遍历”这类场景它们本质上是同一类问题执行上下文压栈太深。4.3 异步回调是怎么“插队”的事件循环与调用栈的分工很多人刚开始学异步时想不通说好的单线程、说好的LIFO呢setTimeout的回调凭什么后来居上地执行其实异步回调根本不进当前调用栈。执行上下文栈里跑的是同步代码异步回调定时器、Promise回调、事件回调会进入任务队列等待当前调用栈清空后由事件循环把它们“移入”调用栈再执行。所以能看到这种顺序console.log(start); setTimeout(() { console.log(timeout); }, 0); console.log(end); // start // end // timeout这段代码里setTimeout的回调创建了一个新的函数执行上下文但它必须在当前栈清空之后才有机会压栈。执行上下文栈的LIFO特性只适用于同步世界异步世界的行为得结合事件循环来看。5. this绑定执行上下文里最“玄学”的部分5.1 this到底是什么它不是变量它是环境的“默认参数”this不是变量它不像var那样被登记在环境记录里。this更像是一个在进入执行上下文时被引擎自动确定并绑定的特殊值。所以同一个函数用不同方式调用进入的执行上下文不同this就可能完全不同function showThis() { console.log(this); } showThis(); // window非严格模式/ undefined严格模式 const obj { showThis }; obj.showThis(); // obj showThis.call({ name: x }); // { name: x }按照调用方式的不同规则可以归纳为四类优先级从低到高依次是默认绑定 隐式绑定 显式绑定 new绑定。5.2 四种绑定规则不能被“口诀”掩盖的细节默认绑定直接调用函数非严格模式下this取全局对象严格模式下是undefined。这里最容易忽略的是“严格模式是否开启”的影响尤其是ES6模块默认就是严格模式所以模块顶层函数直接调用时this是undefined这一点在写工具函数时经常踩坑。隐式绑定函数作为对象属性调用this指向该对象。但它有一个著名坑点把对象方法赋值给一个变量再调用会丢失thisconst obj { name: obj, fn() { console.log(this.name); } }; const fn obj.fn; fn(); // Cannot read properties of undefined严格模式或 window.name非严格赋值后fn的调用方式是默认绑定this丢掉了。这也是为什么React类组件里的方法需要bind或者为什么大家后来都用箭头函数。显式绑定通过call/apply/bind指定this。call和apply会立即调用函数区别只在传参方式bind会返回一个绑定了this的新函数不立即执行。new绑定new操作符会创建一个新的对象并把该对象作为this传给构造函数构造函数返回对象时this也随之确定。优先级其实很好记new 显式 隐式 默认。也就是说如果同时存在多种绑定new最高默认绑定几乎总是最后兜底。5.3 箭头函数的“词法this”不是没有this而是没有自己的执行上下文箭头函数没有自己的this绑定。它内部的this是在其词法作用域外层“继承”下来的。更准确地说箭头函数在被调用时并不会像普通函数那样在其执行上下文中创建自己的this绑定它会直接使用外层执行上下文的this值。这个设计带来的实际效果是箭头函数内的this跟它定义位置的this保持一致调用方式根本无法改变它。所以const obj { data: [1, 2, 3], loop() { return this.data.map(() this); } }; obj.loop(); // map回调里的箭头函数this始终是obj如果map里用普通functionthis就是全局/undefined要用that this或者bind处理。箭头函数把“this跟着环境走”这一点落实得很彻底副作用是在日常代码里回调嵌套的this问题大幅减少。5.4 实际项目里this最容易出的三个问题基于我的经验实际项目里this相关的bug通常是这几类回调函数this丢失把对象方法当作事件回调或Promise回调传递时方法内部的this在真正执行时已经变了。setTimeout里的thissetTimeout回调执行时相当于一次普通函数调用this不指向外层对象很多人因此debug半天。第三方库的backbone/underscore风格函数它们会把你传进来的回调函数裸调用this指向跟预期完全不同。解决办法我一般按这个顺序优先用箭头函数定义“需要捕获环境this”的方法其次是bind最后慎用call动态指定调用方不可控时风险高。6. 用DevTools亲眼“看见”执行上下文断点调试实操6.1 为什么看源码不如看调试面板环境链是可视化的纸上谈兵到这里得拿点实际工具出来。Chrome DevTools的Sources面板里断点调试时能看到三个关键区域Call Stack就是执行上下文栈能看到当前停在哪一层上面压着哪些待返回的调用。Scope能展开当前上下文的词法环境/变量环境的关联情况会分成Local、Closure、Global三层。Watch可以在断点处添加表达式直接求值。打开一个闭包调试的页面在Closure里能明确看到当前函数捕获了外层环境的哪些变量。这是比任何规范文字都更直观的“执行上下文”观察方式强烈建议你亲自动手打断点看一次。6.2 调试步骤用一个小Demo跑通全过程建议读者复制下面这段代码到浏览器控制台或一个页面里调试let globalCounter 0; function createCounter() { let count 0; return function increment() { count; globalCounter; console.log(count, globalCounter); return count; }; } const counter createCounter(); counter();在count;这一行打断点运行后看Call Stack和Scope。你会看到Call Stack里是全局上下文和一个increment上下文Scope里Local有count、return value等Closure里有createCounter环境下的count0Global里有globalCounter。这比任何术语都直观闭包保留的是词法环境而不是执行上下文本身。6.3 动态修改值来测环境记录的特性调试的时候可以顺便干一件有意思的事在Scope面板里直接双击某个闭包变量的值改成另一个数再继续执行。你会发现函数内部的逻辑会按修改后的值继续跑。这说明了一个重要的底层事实闭包捕获的是变量绑定本身对变量的引用不是值的快照。这个特性就是为什么闭包能维持“状态”也解释了for循环var方案回调全打印3的原因之一——回调捕获的是同一个绑定。7. 把执行上下文内化成直觉几个自测题与“复苏”总结7.1 自测题先自己推一遍再看答案对照建议你先在心里模拟一遍执行上下文的创建、入栈、登记、执行过程再对答案。第一题var x 10; function bar() { console.log(x); var x 30; } bar();第二题let a 1; function outer() { let b 2; function inner() { console.log(a, b); } return inner; } const fn outer(); fn();第三题function Foo() { getName function() { console.log(inner); }; return this; } Foo.getName function() { console.log(outer); }; Foo.getName(); // new Foo().getName?.(); // 这行可以忽略第一题答案是undefined第二题答案1 2第三题常规输出outer。分析时强行按照“创建阶段登记 执行阶段赋值 词法环境链查找”三个步骤走基本不会错。7.2 为什么说“执行上下文是JS运行模型的地基”作用域链、闭包、this、变量提升、暂时性死区、调用栈爆栈所有这些词归根结底都是执行上下文在不同层面的表现。我在带新人时经常说如果只允许你理解JS运行时的一个概念那就选执行上下文一旦你把这个概念在脑子里转熟了作用域和this就不再是玄学而是可以推导的确定性机制。7.3 把执行上下文画进脑子里的“运行图”每个人适合的心智模型不一样我自己最终沉淀下来的运行图是这样的代码不是立即执行的而是先被引擎“预扫描”一遍搭好环境登记好标识符然后代码才开始真正执行遇到函数调用就再搭新的环境嵌套着搭环境的过程形成了栈环境之间的outer引用链形成了作用域链。这个模型配合一个习惯非常管用每次看到一段JS代码先不问“输出是什么”而是问“这段代码的执行上下文有哪些这些环境是怎么嵌套的”一旦把第一问回答清楚输出基本就确定了。8. 一些个人的debug经验与系列预告8.1 在真实项目里排查执行上下文相关问题的三个阶段遇到莫名其妙的“this不对”“变量没定义”“闭包值不对”我一般按三段式处理先看变量是由var还是let/const声明的这决定了它登记在哪个环境也决定了它的生命周期。再定位当前函数是怎么被调用的是用作回调、对象方法、还是直接调用判断this绑定规则。最后打断点看Scope面板确认实际作用域链里的环境和变量值比自己死磕代码快得多。这三步走下来市面上80%的“玄学bug”都能直接定位到是哪个上下文、哪层环境出了问题。8.2 “复苏”的意义忘记了不是罪捡起来才是本事“复苏日记”这个系列对我来说就是把那些曾是“常识”却随着项目变多而遗忘的底层知识重新捡起来的过程。执行上下文这个概念大学时觉得无聊工作时觉得没用直到真正排查过几个复杂的闭包共同状态问题才意识到它是整个JS语言行为模型的圆心。如果你也曾经学过一遍又忘干净这个系列应该能在不堆术语的前提下帮你把这些概念重新焊接回脑子里。下一章我打算聊作用域链与闭包在真实业务场景里的应用包括如何用闭包实现状态封装、如何规避闭包内存泄漏、以及怎么把模块化思想和闭包结合起来写出更干净的业务代码。如果这一章里有些细节你还觉得哪里没通我建议先别急着往下冲回头把“创建阶段三件事调用栈压栈顺序”这两点再看一遍它解决的问题比你想的要多得多。