JavaScript核心机制精讲：执行上下文、作用域链、闭包与this-开发者社区

JavaScript面试有个很有趣的现象：十个候选人里，七八个能流利背出“闭包就是函数嵌套函数”，但真拿一道综合题让他们分析输出结果，立刻分高下。问题不在记不记得定义，而在于执行上下文、作用域链、闭包和this这四件事本来就环环相扣，单独背任何一个结论，实战中都容易露馅。

这篇是JavaScript核心机制解析的上篇，我会把这四块放在一起讲透。它们之间不是四个独立知识点，而是同一套运行时机制的不同侧面：代码执行时上下文如何创建、变量沿着什么路径查找、函数为什么能“记住”外部变量、this到底由谁说了算。把这些串起来之后，再看任何JS代码都能在脑子里画出执行轨迹。

内容适合三类人：面试前需要系统梳理基础的前端开发者；工作几年但一直靠“背结论”写代码、遇到诡异bug只能靠console.log盲试的人；以及想给团队做内部分享的资深工程师，这篇可以直接当课件底稿。

1. 执行上下文：代码运行时的底层舞台

1.1 为什么必须先聊执行上下文

很多教材把执行上下文描述得很抽象，我换个说法：它是JavaScript引擎在运行一段代码前，为这段代码准备的一套“运行环境”。这套环境里记录了三样东西——当前代码能用哪些变量和函数（变量环境）、当前代码怎么查外层变量（作用域链）、当前代码里的this指向谁。

所以执行上下文不是“一个概念”，而是一个实实在在的数据结构。引擎每执行一段可执行代码，就会创建一份上下文，然后把它压进调用栈。栈顶的上下文才是正在运行的，其余的全在底下排队。

有个关键点容易忽略：上下文分为两种创建时机。全局上下文在程序启动时创建，函数上下文在“函数被调用时”创建。注意，是调用时，不是定义时。这意味着同一个函数每次调用都会生成全新的上下文，哪怕是在递归里调用自己，每一次递归都是独立的运行环境。

1.2 创建阶段和执行阶段：两阶段各做了什么

一个完整的执行上下文生命周期，分成两个阶段。

创建阶段做四件事：

创建变量对象（VO/AO），把函数声明、变量声明、函数参数都登记进去
建立作用域链
确定this绑定
处理arguments对象（函数上下文才有）

执行阶段做一件事：逐行执行代码，给变量赋值，调用其他函数。

这里藏着JavaScript最经典的面试题——变量提升。为什么console.log(a)写在var a = 1之前不会报错，而是输出undefined？因为在创建阶段，变量对象里已经登记了a这个名字，只是还没赋值。等执行阶段跑到赋值那行，才把1塞进去。函数声明同理，但它更特殊：创建阶段不仅登记名字，还直接把函数体引用也存好了，所以函数声明可以在定义之前调用。

我用一个生活场景类比：执行上下文创建阶段就像你入住酒店时前台先登记身份信息、分配房卡（变量对象），执行阶段才是你真的刷卡进房间、把行李放下来（赋值）。你还没放行李，但房间已经登记在你名下了。

1.3 调用栈：执行上下文的管理器

调用栈本质上是个LIFO结构。引擎执行代码时，遇到函数调用就把这个函数的新上下文压栈，函数执行完再弹栈，控制权交还给栈顶的上下文。

function bar() { console.log('bar'); } function foo() { bar(); } foo();

这段代码执行时栈的变化是：

初始：栈里只有全局执行上下文
调用foo：压入foo的上下文
foo内部调用bar：压入bar的上下文
bar执行完：弹出bar的上下文
foo执行完：弹出foo的上下文
回到全局，直到程序结束弹出全局上下文

栈溢出（RangeError: Maximum call stack size exceeded）就是因为压栈太多、弹栈太慢，把栈空间堆满了。常见的递归没有终止条件，基本都是这个错。

我自己的排查经验：遇到“栈溢出”或者“变量诡异为空”的问题，第一步永远是打开DevTools的Sources面板，看Call Stack那一栏。它能直接告诉你当前停在哪里、之前经过了哪些函数、每一层的this和变量是什么。用抽象概念排查问题不如直接看调用栈，这是最快路径。

2. 作用域链：变量查找的寻址路径

2.1 词法作用域：写代码的时候就定死了

作用域链的核心是词法作用域（Lexical Scope）。也就是说，变量的查找范围在“写代码的那一刻”就确定了，由代码的嵌套结构决定，跟函数在哪里调用没有任何关系。

很多人混淆“作用域”和“this”，其实完全两个维度。作用域是静态的，写死了查变量走哪条路；this是动态的，调用时才知道指向谁。后面第四章细说this，这里先记住这个分野。

JavaScript的作用域分三种：全局作用域、函数作用域、块级作用域（ES6引入，由{}限定，只有let和const遵守）。

2.2 逐层查找：从内往外，找到即止

作用域链的构建规则很简单：每个函数的上下文里，作用域链 = 当前函数的变量对象 + 父级作用域链。也就是说，链的起点永远是当前上下文自己，然后一层一层往外接，直到全局对象。

var x = 10; function outer() { var y = 20; function inner() { var z = 30; console.log(x + y + z); // 60 } inner(); } outer();

inner内部访问x时，查找顺序是：inner自己的AO（没有x）→ outer的AO（没有x）→ 全局VO（找到x: 10）。y也一样，在inner自己找不到，去outer的AO找，命中20。

这个逐层查找只往上走，不走回头路。子作用域能访问父作用域，父作用域访问不到子作用域。就像小区快递代收点：你家里没人，快递放小区代收点，再没人放快递总站。但快递总站永远不会把包裹塞进你家卧室。

2.3 块级作用域：var和let的本质差异

ES6之前，JavaScript只有全局和函数两级作用域，var声明的变量会被“提升”到函数顶部。ES6的let和const补上了块级，{}圈起来的地方就是独立作用域。

我最常被问到的一个问题是：“为什么大家都说不要在for循环里用var？”看个例子：

for (var i = 0; i < 3; i++) { setTimeout(() => console.log(i), 100); } // 3 3 3 for (let i = 0; i < 3; i++) { setTimeout(() => console.log(i), 100); } // 0 1 2

var没有块级作用域，循环里的i其实是全局/函数作用域里同一个变量，等定时器回调触发时，循环早跑完了，i已经变成3，三次回调拿同一个引用，自然都输出3。let每次循环都创建新的块级作用域，闭包捕获的是每次迭代独立的i，结果就是0、1、2。

这个差异背后还是执行上下文的作用域链在起作用——每次循环迭代，let都会生成一个新鲜的词法环境，闭包引用的是各自环境里的i，互不干扰。

3. 闭包：函数记住外部变量的能力

3.1 闭包到底是什么

闭包的经典定义：函数与其定义时所在词法环境的组合。说白了，一个函数在定义时，会把它外面的变量环境“打包”进自己的[[Scope]]属性里。即使外部函数已经执行完，内部函数只要还被引用，那份外部变量环境就不会被垃圾回收。

看代码：

function counter() { let count = 0; return function () { count++; return count; }; } const c = counter(); console.log(c()); // 1 console.log(c()); // 2 console.log(c()); // 3

关键在于：counter()执行完，按理说它的执行上下文弹栈了，局部变量count应该被回收。但因为返回的函数还握有counter变量环境的引用，count就活了下来。这就是闭包——执行上下文销毁了，但变量环境没销毁。

用内存图理解：调用栈里没有了counter上下文，但堆内存里那{ count: 0 }对象被匿名函数持有着，所以内存无法释放。这个“持有引用”就是闭包的内存开销来源。

3.2 闭包的经典应用场景

闭包最实用的三个场景：

私有变量。模拟传统面向对象里的私有属性，外部只能通过暴露的方法操作内部状态：

function createUser(name) { let age = 0; return { getName: () => name, getAge: () => age, birthday: () => age++, }; } const user = createUser('Luna'); user.birthday(); console.log(user.getAge()); // 1 console.log(user.age); // undefined

防抖节流。保存定时器id，这是前端高频场景：

function debounce(fn, delay) { let timer = null; return function (...args) { if (timer) clearTimeout(timer); timer = setTimeout(() => fn.apply(this, args), delay); }; }

高阶函数/柯里化。延迟部分参数的传入，让函数式写法更灵活。工程上用得最多的是模块模式——用一个IIFE包裹一堆内部变量和方法，只把需要公开的API暴露到全局，Node里的模块机制底层思路也是这个。

3.3 闭包的内存陷阱与回收

闭包不是免费的，保留变量环境必然占用内存。但这里有个差别：闭包本身不泄漏，泄漏的是“该释放的闭包没释放”。

经典泄漏场景：全局变量引用着某个不需要的闭包，或者事件监听器绑定了不该绑定的函数却没解绑。

function setup() { const hugeData = new Array(10000000).fill(1); window.onresize = function () { console.log('resize'); }; } setup();

setup调用后，onresize回调持有了setup的变量环境，hugeData永远无法回收。虽然回调本身只用了几行代码，但它连带巨大数组一起被保留了。解决方式是主动解绑window.onresize = null，或者把hugeData移出闭包覆盖的范围。

我给团队定过一条规则：写闭包时先问三句话，这个闭包会被谁持有？持有多久？它连带引用的大对象是否必要？如果持有者是长期存活的（全局变量、事件监听器、定时器），就要特别留意内部引用的对象大小。闭包本身不是洪水猛兽，很多人被“闭包泄漏”吓到，其实是没管理好闭包的生命周期。

4. this指向：调用方式决定一切

4.1 四种绑定规则

this是执行上下文创建阶段就确定好的，但它不遵守词法规则，遵守的是调用规则。同一函数，调用方式不同，this就不同。

默认绑定：直接调用函数，非严格模式下this指向全局对象（浏览器window），严格模式下是undefined。

function show() { console.log(this); } show(); // window

隐式绑定：作为对象方法调用，this指向这个对象。

const obj = { name: 'obj', show() { console.log(this.name); }, }; obj.show(); // 'obj'

但隐式绑定有个著名陷阱：把方法单独拆出来，this就丢了。

const fn = obj.show; fn(); // undefined，this是window（严格模式）或全局（非严格）

显式绑定：call、apply、bind硬性指定this指向。

function show(name) { console.log(this.prefix + name); } show.call({ prefix: 'Hello ' }, 'Luna'); // Hello Luna

new绑定：new调用时，this指向新创建的对象实例，优先级最高。

4.2 优先级排序与箭头函数的例外

四者优先级从高到低：new绑定 > 显式绑定 > 隐式绑定 > 默认绑定（严格模式默认不算绑定）。硬要说例外，bind比call/apply更高一点，因为bind返回的是绑定过的新函数。

箭头函数是整个规则里唯一的例外。它不创建自己的this，而是沿着作用域链向上找外层函数的this。所以：

const obj = { name: 'obj', show: function () { console.log(this); // obj const inner = () => console.log(this); // obj，继承了外层this }, }; obj.show();

这个特性让它天然适合做回调函数。如果不用箭头函数，传统方案是var self = this缓存变量：

const obj = { name: 'obj', show: function () { const self = this; setTimeout(function () { console.log(self.name); // obj }, 100); }, }; obj.show();

4.3 实战中this踩坑最深的三个场景

我在实际项目里见过、也修过最多的this bug，集中在下面三种：

事件处理器回调。DOM事件绑定的函数，this默认指向触发事件的元素，不是组件实例。这坑过不少写Vue 2 Options API的人：methods里定义的方法，传给addEventListener后，this指错了对象。我的处理习惯是：组件里凡是给外部传的回调，一律箭头函数或者提前bind好。

数组方法回调中的this。很多人不知道forEach、map的第二个参数可以指定this：

const obj = { factor: 2 }; const arr = [1, 2, 3]; const result = arr.map(function (x) { return x * this.factor; }, obj); // [2, 4, 6]

不知道这个第二参数的话，大部分人会在外面包一层箭头函数。两个方案都能用，但直接传thisArg优雅多了。

class方法被解构调用。ES6类的方法默认不是绑定的，把this.method单独传出去，this就丢了。React早期类组件里最常见的就是onClick={this.handleClick}导致this undefined，最后全用bind或箭头函数类字段解决。现在虽然函数组件成为主流，但任何类内部方法外传时都要警惕这个问题。

5. 四件事如何联动：一次完整函数调用背后的全过程

5.1 从调用到输出的完整链路

把前四章串起来，看一次函数调用发生了什么：

const name = 'Global'; function greet(person) { const prefix = 'Hello'; return function inner() { return `${prefix}, ${person}. I am ${this.name}`; }; } const say = greet('Luna'); console.log(say());

逐步拆解：

第1步：全局上下文创建，登记name、greet函数声明，this指向window。

第2步：调用greet('Luna')，创建greet的执行上下文。创建阶段：arguments对象里有person:'Luna'，变量对象登记prefix，作用域链指向全局，this按默认绑定指向window。

第3步：greet执行，prefix赋值为'Hello'。return内层函数。内层函数的[[Scope]]快照记录了greet的变量环境（prefix、person）和全局环境。

第4步：greet的上下文弹栈。但内层函数被赋给say，所以greet的变量环境没被回收。

第5步：调用say()，创建inner的执行上下文。它的作用域链是：inner变量对象（空）→ greet存活变量环境（prefix、person）→ 全局环境。沿链查找，找到prefix和person。this呢？默认绑定，非严格模式是window，所以this.name是'Global'。

最终输出：Hello, Luna. I am Global。

这个例子完整覆盖了四件事：上下文创建回收、作用域链逐层查变量、闭包保留变量环境、this动态绑定。拆开看每步都简单，合起来就是一个经典面试题。

5.2 一道高频综合题的完整推导

再看个难一点的，我面试必问：

var length = 10; function fn() { console.log(this.length); } const obj = { length: 5, method(fn) { fn(); arguments[0](); }, }; obj.method(fn, 1);

很多人第一次做这题直接懵。我们按规则推：

obj.method(fn, 1)调用时，method的this指向obj。但method内部：

fn()是直接调用，默认绑定，非严格模式this是window，window.length是10（var声明的全局变量挂到window上），输出10。
arguments[0]()是隐式绑定，调用者变成了arguments对象。arguments对象有length属性，值是传入实参个数——2。所以输出2。

这题厉害在于：它同时考了默认绑定、隐式绑定、arguments对象的length，以及全局变量挂载。我见过不少人折在第二问，因为没想到arguments[0]()的this是arguments本身。