各位同仁，各位对JavaScript充满热情的朋友们，大家好！
今天，我们将深入探讨JavaScript中一个既基础又常常令人困惑的特性——变量提升（Hoisting）。具体来说，我们将聚焦于它最容易产生“坑”的地方：function 声明和 var 声明在词法环境（Lexical Environment）创建时的时序差异。理解这一点，对于编写健壮、可预测的JavaScript代码至关重要，也能帮助我们更好地阅读和调试他人的代码。
在现代JavaScript开发中，虽然我们有了 let 和 const 这些更具块级作用域特性的声明方式，但 var 和 function 声明的变量提升机制仍然是语言核心的一部分，尤其是在面对遗留代码、跨文件作用域或进行面试时，其重要性不言而喻。我们将以编程专家的视角，从底层执行机制出发，层层剖析，确保大家能对这个概念有透彻的理解。
JavaScript执行上下文：一切的起点
要理解变量提升，我们必须首先理解JavaScript代码的执行环境。当JavaScript引擎执行代码时，它会为每一段可执行代码（如全局代码、函数代码或eval代码）创建一个“执行上下文”（Execution Context）。这个执行上下文可以被想象成一个包含所有必要信息来执行当前代码的环境。
一个执行上下文主要包含以下三个关键部分：
- 变量环境（Variable Environment）：这是变量和函数声明实际存储的地方。在ES6之前，它主要负责处理
var声明和function声明。 - 词法环境（Lexical Environment）：这是一个更抽象的概念，它在功能上与变量环境非常相似，但在ES6之后，它被用于处理
let和const声明，并且负责维护作用域链。实际上，变量环境是词法环境的一个具体化。 this绑定（thisBinding）：决定了当前执行上下文中this关键字的值。
我们今天关注的重点是变量环境（或者更广义地说，词法环境）在“创建阶段”的行为。
JavaScript代码的执行可以分为两个主要阶段：
- 创建阶段（Creation Phase）：在这个阶段，JavaScript引擎会扫描当前执行上下文的代码，识别所有的变量和函数声明，并为它们在内存中分配空间。这个过程就是我们所说的“提升”。
- 执行阶段（Execution Phase）：在这个阶段，JavaScript引擎开始逐行执行代码，进行变量赋值、函数调用等操作。
变量提升的“坑”，恰恰就藏在创建阶段的精细时序中。
深入创建阶段：Function 声明的优先级
在执行上下文的创建阶段，JavaScript引擎会按照特定的顺序处理声明。这个顺序，是理解 function 和 var 行为差异的关键。
处理顺序：
- 绑定
this值。 - 创建词法环境（Lexical Environment）和变量环境（Variable Environment）。
- 扫描函数声明（Function Declarations）。
- 扫描
var变量声明。
是的，你没看错，函数声明会先于 var 变量声明被处理。这意味着在创建阶段，当引擎遍历代码时，它会优先处理所有 function 关键字开头的函数声明，然后才是 var 关键字开头的变量声明。
函数声明的提升：完全初始化
当JavaScript引擎在创建阶段遇到一个函数声明（function foo() {}）时，它会在变量环境（或词法环境）中创建一个与该函数同名的标识符，并将该标识符的值完整地初始化为该函数本身。这意味着，在代码执行到该函数声明的物理位置之前，我们就可以引用并调用这个函数。
让我们看一个例子：
console.log(greet()); // 输出 "Hello from greet!"
function greet() {
return "Hello from greet!";
}
console.log(greet()); // 再次输出 "Hello from greet!"内部机制分析：
- 创建阶段：
- JavaScript引擎扫描到
function greet() { ... }声明。 - 在全局执行上下文的变量环境中，创建一个名为
greet的标识符。 - 将
greet的值设置为实际的函数对象function greet() { return "Hello from greet!"; }。
- JavaScript引擎扫描到
- 执行阶段：
console.log(greet());被执行。此时greet已经被完全初始化为一个函数，所以它可以被正常调用，并返回字符串。
这使得函数声明在整个作用域内都是可用的，无论你在何处定义它，都可以像是在文件顶部定义一样使用。
var 变量的提升：初始化为 undefined
与函数声明不同，当JavaScript引擎在创建阶段遇到一个 var 变量声明（var myVar = "value";）时，它也会在变量环境中创建一个与该变量同名的标识符。但此时，它不会将变量初始化为其在代码中赋的实际值，而是将其初始化为 undefined。只有当代码执行到该 var 变量的物理赋值位置时，它才会被赋上真正的值。
看下面的例子：
console.log(myVar); // 输出 undefined
var myVar = "Hello from myVar!";
console.log(myVar); // 输出 "Hello from myVar!"内部机制分析：
- 创建阶段：
- JavaScript引擎扫描到
var myVar = "Hello from myVar!";声明。 - 在全局执行上下文的变量环境中，创建一个名为
myVar的标识符。 - 将
myVar的值设置为undefined。
- JavaScript引擎扫描到
- 执行阶段：
console.log(myVar);被执行。此时myVar的值为undefined，所以输出undefined。- 代码执行到
var myVar = "Hello from myVar!";。此时myVar被赋值为"Hello from myVar!"。 console.log(myVar);被执行。此时myVar的值为"Hello from myVar!"，所以输出该字符串。
这是一个经典的 var 变量提升行为，也是很多初学者容易犯错的地方。
let 和 const 声明（简要对比）
为了更好地理解 var 和 function 的行为，我们简要提一下 let 和 const。它们也存在“提升”现象，但它们的行为与 var 和 function 截然不同。
当JavaScript引擎遇到 let 或 const 声明时，它也会在词法环境（注意，这里是词法环境，不是变量环境）中为这些变量创建标识符。然而，这些标识符不会被初始化。它们会处于一个被称为“暂时性死区”（Temporal Dead Zone, TDZ）的状态。在此期间，任何对这些变量的访问都会导致 ReferenceError。只有当代码执行到 let 或 const 声明的物理位置时，变量才会被初始化（let 初始化为 undefined，const 必须同时赋值），并离开TDZ。
console.log(myLetVar); // ReferenceError: Cannot access 'myLetVar' before initialization
let myLetVar = "I am a let variable";
console.log(myConstVar); // ReferenceError: Cannot access 'myConstVar' before initialization
const myConstVar = "I am a const variable";这个对比强调了 var 和 function 在创建阶段的特殊初始化行为。
词法环境创建时序的“坑”：Function 与 Var 的冲突
现在，我们把这两种声明放在一起，看看当它们同名时，如何在创建阶段产生冲突，以及这种冲突如何影响代码的执行。这正是本次讲座的核心“坑”所在。
核心规则：在执行上下文的创建阶段，函数声明会优先于 var 变量声明被处理。如果存在同名的函数声明和 var 声明，函数声明会“覆盖” var 声明在创建阶段的初始化。
让我们用一个具体的例子来演示：
console.log(myIdentifier); // ? 预想一下这里会输出什么？
console.log(typeof myIdentifier); // ?
var myIdentifier = "I am a var string";
function myIdentifier() {
return "I am a function!";
}
console.log(myIdentifier); // ?
console.log(typeof myIdentifier); // ?
// 尝试调用 myIdentifier
// console.log(myIdentifier()); // 如果在 var 赋值之前调用，结果会不同如果你对输出结果感到困惑，那正是我们今天要解决的问题。
内部机制的详细剖析：
-
全局执行上下文创建阶段：
- 步骤 1：处理函数声明。
- JavaScript引擎扫描到
function myIdentifier() { ... }。 - 在全局变量环境中，创建一个名为
myIdentifier的标识符。 - 将
myIdentifier的值完全初始化为该函数对象。 - 此时，全局变量环境可以想象为：
{ myIdentifier: function myIdentifier() { return "I am a function!"; } }
- JavaScript引擎扫描到
- 步骤 2：处理
var声明。- JavaScript引擎扫描到
var myIdentifier = "I am a var string";。 - 引擎发现
myIdentifier这个标识符已经存在于变量环境中（因为它在步骤1中已经被函数声明创建了）。 - 注意：
var声明不会重新初始化一个已经存在的、由函数声明创建的同名标识符。它会跳过undefined的初始化步骤。 - 所以，在创建阶段结束后，
myIdentifier的值仍然是那个函数对象。 - 此时，全局变量环境仍然是：
{ myIdentifier: function myIdentifier() { return "I am a function!"; } }
- JavaScript引擎扫描到
- 步骤 1：处理函数声明。
-
全局执行上下文执行阶段：
- 代码行 1：
console.log(myIdentifier);- 引擎查找
myIdentifier。在变量环境中，它找到值为function myIdentifier() { return "I am a function!"; }的myIdentifier。 - 输出：
[Function: myIdentifier](或类似函数定义的字符串表示)
- 引擎查找
- 代码行 2：
console.log(typeof myIdentifier);- 引擎查找
myIdentifier。它的值是函数。 - 输出：
function
- 引擎查找
- 代码行 3：
var myIdentifier = "I am a var string";- 这是一个赋值操作。引擎找到
myIdentifier标识符，并将其值从函数对象更新为字符串"I am a var string"。 - 此时，全局变量环境更新为：
{ myIdentifier: "I am a var string" }
- 这是一个赋值操作。引擎找到
- 代码行 4：
function myIdentifier() { ... }- 这是一个函数声明。在执行阶段，它被跳过，因为它的初始化已经在创建阶段完成。它不会再次影响
myIdentifier的值。
- 这是一个函数声明。在执行阶段，它被跳过，因为它的初始化已经在创建阶段完成。它不会再次影响
- 代码行 5：
console.log(myIdentifier);- 引擎查找
myIdentifier。在变量环境中，它找到值为"I am a var string"的myIdentifier。 - 输出：
I am a var string
- 引擎查找
- 代码行 6：
console.log(typeof myIdentifier);- 引擎查找
myIdentifier。它的值是字符串。 - 输出：
string
- 引擎查找
- 代码行 1：
结果总结：
在 var myIdentifier = "I am a var string"; 这行代码执行之前，myIdentifier 的值是一个函数。只有当 var 声明的赋值部分执行时，myIdentifier 才会被赋予字符串值，从而覆盖了之前的函数值。
这种行为可以用下表来清晰地表示：
| 阶段 / 代码行 | myIdentifier 的状态（在变量环境中） |
解释 |
|---|---|---|
| 创建阶段（所有代码扫描完毕） | function myIdentifier() { ... } |
函数声明优先被处理并完全初始化。var 声明发现同名已存在，跳过 undefined 初始化。 |
console.log(myIdentifier); |
function myIdentifier() { ... } |
访问到的是函数。 |
console.log(typeof myIdentifier); |
function myIdentifier() { ... } |
typeof 结果是 function。 |
var myIdentifier = "I am a var string"; |
"I am a var string" |
赋值操作，myIdentifier 的值被更新为字符串。 |
function myIdentifier() { ... } |
"I am a var string" |
函数声明在执行阶段被跳过，不影响当前 myIdentifier 的值。 |
console.log(myIdentifier); |
"I am a var string" |
访问到的是字符串。 |
console.log(typeof myIdentifier); |
"I am a var string" |
typeof 结果是 string。 |
这个例子完美地展示了 function 声明在创建阶段的优先级，以及 var 声明的赋值行为在执行阶段如何改变变量的值。
另一个常见误解：函数表达式与函数声明
为了进一步巩固理解，我们需要区分函数声明（function foo() {}）和函数表达式（var foo = function() {} 或 const foo = () => {}）。
函数声明会像我们上面讨论的那样被完全提升。
函数表达式则不同，它们创建的函数对象是作为赋值操作的一部分。因此，只有 var 关键字（如果是 var 声明）会被提升，而函数体本身不会被提升。它在创建阶段的行为与普通 var 变量完全一致：只提升变量名，并初始化为 undefined。
console.log(myFunctionExpression); // 输出 undefined
// console.log(myFunctionExpression()); // TypeError: myFunctionExpression is not a function
var myFunctionExpression = function() {
return "I am a function expression!";
};
console.log(myFunctionExpression()); // 输出 "I am a function expression!"
// 对比函数声明
console.log(myFunctionDeclaration()); // 输出 "I am a function declaration!"
function myFunctionDeclaration() {
return "I am a function declaration!";
}在这个例子中，myFunctionExpression 在赋值之前是 undefined，尝试调用 undefined 会导致 TypeError。这再次强调了函数表达式和函数声明在提升行为上的根本差异。
多个同名 var 声明和函数声明
JavaScript允许使用 var 关键字进行重复声明，并且不会报错。如果存在多个同名的 var 声明，它们在创建阶段只会创建一个标识符，后续的 var 声明会被忽略。但赋值操作仍然会按顺序执行。
var x = 10;
var x = 20; // 这里的 var x; 在创建阶段被忽略，但 x = 20; 仍然是赋值操作
console.log(x); // 输出 20当 var 声明与函数声明同名时，我们已经看到函数声明在创建阶段占据主导。如果同一个作用域内有多个函数声明，情况又如何呢？
console.log(foo()); // 输出 "Second foo"
function foo() {
return "First foo";
}
function foo() {
return "Second foo";
}
console.log(foo()); // 输出 "Second foo"内部机制分析：
- 创建阶段：
- JavaScript引擎扫描到
function foo() { return "First foo"; }。在变量环境中，foo被初始化为这个函数。 - 接着，引擎扫描到
function foo() { return "Second foo"; }。由于foo已经存在，并且它是一个函数声明，JavaScript引擎会用第二个函数声明覆盖第一个。 - 因此，在创建阶段结束时，
foo的值是第二个函数声明。
- JavaScript引擎扫描到
- 执行阶段：
console.log(foo());第一次调用时，foo已经是第二个函数，所以输出 "Second foo"。console.log(foo());第二次调用时，结果依然如此。
这个行为说明，当存在多个同名函数声明时，后面的函数声明会覆盖前面的函数声明。这在实际开发中很少见，因为通常会避免这种模糊的声明方式，但在某些情况下，理解这一行为是重要的。
建立一个清晰的心理模型
为了更好地理解和预测JavaScript中变量提升的行为，我们可以建立一个清晰的心理模型。当进入一个新的执行上下文时（例如，调用一个函数或运行全局代码），请想象以下步骤：
- 扫描函数声明： 找到所有
function关键字开头的函数声明。将它们的名字作为标识符添加到当前作用域的变量环境/词法环境，并立即将它们的值设置为对应的函数对象。如果遇到同名函数声明，后面的会覆盖前面的。 - 扫描
var声明： 找到所有var关键字开头的变量声明。对于每个var变量，检查它是否已经存在于变量环境/词法环境中（例如，被一个同名函数声明创建）。- 如果不存在，则创建一个新的标识符，并将其值初始化为
undefined。 - 如果已经存在（由函数声明创建），则什么也不做，保持其现有值（即函数对象）。
var声明不会覆盖函数声明。
- 如果不存在，则创建一个新的标识符，并将其值初始化为
- 扫描
let和const声明： 找到所有let和const关键字开头的变量声明。将它们的名字作为标识符添加到当前作用域的词法环境，但不初始化它们的值。将它们标记为处于“暂时性死区”（TDZ）。 - 执行代码： 逐行执行代码。
- 当遇到赋值操作时，更新变量的值。
- 当遇到函数调用时，执行函数。
- 当遇到
let或const声明的物理位置时，变量会被初始化（let为undefined，const为其赋值），并离开TDZ。
下表总结了不同声明类型的提升行为：
| 声明类型 | 提升到作用域顶部 | 初始化状态（在创建阶段） | 访问时机（在声明前） | 备注 |
|---|---|---|---|---|
function 声明 |
是 | 完全初始化为函数对象 | 可访问和调用 | 优先于 var 处理，同名会覆盖。 |
var 声明 |
是 | 初始化为 undefined |
可访问（值为 undefined） |
赋值前使用可能导致 undefined 行为。 |
let / const 声明 |
是（但处于TDZ） | 未初始化 | 导致 ReferenceError |
提供块级作用域，更安全，推荐使用。 |
函数表达式 (var func = function(){}) |
仅 var 部分提升 |
func 初始化为 undefined |
func 为 undefined，不能直接调用 |
行为与普通 var 变量一致。 |
实践意义与最佳实践
理解变量提升的复杂性并非仅仅是为了通过面试，它对我们日常编写高质量JavaScript代码具有深远的指导意义。
-
避免
var声明的陷阱：
var的函数级作用域和其独特的提升行为常常导致意外的变量覆盖和难以调试的错误。例如，在循环中不小心使用var可能会导致所有闭包共享同一个变量的最终值。
最佳实践： 尽可能使用let和const。它们提供了块级作用域，并且通过“暂时性死区”机制，强制开发者在声明之后再使用变量，这大大提高了代码的可预测性和健壮性。 -
函数声明与函数表达式的选择：
- 如果你需要一个在整个作用域内都可用的函数（例如，一个辅助函数或工具函数），并且希望它能被其他代码在任何位置调用，那么函数声明是一个不错的选择。它的提升行为确保了这一点。
- 如果你希望函数作为变量的一部分，或者需要在运行时动态创建函数（例如，作为回调函数、立即执行函数表达式IIFE），那么函数表达式是更好的选择。它们的行为更像普通变量，可以与
let和const结合使用，从而获得块级作用域的优势。 - 最佳实践： 优先使用函数声明，除非你有明确的理由使用函数表达式（例如，防止函数名污染全局作用域，或者需要将函数作为值传递）。
-
养成良好的声明习惯：
即使JavaScript允许你先使用后声明（由于提升），但为了代码的清晰度和可读性，始终在作用域的顶部声明你的变量和函数。这样做可以消除关于变量何时可用、其值是什么的任何歧义，并使代码更易于理解和维护。// 推荐的写法 function calculateTotal(items) { const taxRate = 0.05; // 声明在顶部 let total = 0; // 声明在顶部 for (const item of items) { total += item.price; } return total * (1 + taxRate); } // 不推荐，尽管能运行 function calculateTotalBad(items) { // taxRate 和 total 在这里被使用，但声明在后面 for (const item of items) { total += item.price; // total 在这里是 undefined + number，导致 NaN } const taxRate = 0.05; let total = 0; return total * (1 + taxRate); }当然，对于
let和const而言，calculateTotalBad会直接抛出ReferenceError，因为它在TDZ中被访问了。这正是let/const能够避免var提升陷阱的优点。 -
利用Linter和ESLint：
现代开发流程中，Linting工具如ESLint是不可或缺的。它们可以配置规则，强制执行诸如“no-var”或“no-use-before-define”等最佳实践，从而在代码提交之前就发现并纠正潜在的变量提升问题。
高级考量与细微之处
嵌套函数与作用域链
变量提升不仅发生在全局作用域，也发生在每个函数作用域中。当JavaScript引擎执行一个函数时，它会为该函数创建一个新的执行上下文，并在这个新的上下文中重复上述的创建阶段和执行阶段。
作用域链（Scope Chain）是词法环境的一个重要特性。当JavaScript引擎需要查找一个变量时，它会首先在当前执行上下文的词法环境中查找。如果找不到，它会沿着作用域链向上查找父级词法环境，直到找到变量或到达全局作用域。
var globalVar = "Global";
function outer() {
console.log(globalVar); // "Global" (从父级作用域查找)
console.log(outerVar); // undefined (outerVar 在当前作用域提升但未赋值)
// console.log(innerVar); // ReferenceError (innerVar 在内部函数作用域，未提升到这里)
var outerVar = "Outer";
function inner() {
console.log(globalVar); // "Global"
console.log(outerVar); // "Outer" (从父级作用域查找)
console.log(innerVar); // undefined (innerVar 在当前作用域提升但未赋值)
var innerVar = "Inner";
}
inner();
}
outer();这个例子展示了在不同嵌套作用域中，var 变量的提升行为以及作用域链如何影响变量的查找。每个函数都有自己的变量环境，其中包含该函数内部声明的变量和函数的提升版本。
typeof 操作符与未声明变量
在JavaScript中，typeof 操作符对未声明的变量会返回 "undefined"，而不会抛出 ReferenceError。这与 let/const 声明在TDZ中的行为形成对比。
console.log(typeof undeclaredVar); // 输出 "undefined"
// console.log(undeclaredVar); // ReferenceError: undeclaredVar is not defined
console.log(typeof myLetVarInTDZ); // ReferenceError: Cannot access 'myLetVarInTDZ' before initialization
let myLetVarInTDZ;这表明 typeof 对未声明变量的处理非常宽容，但这种宽容并不适用于 let/const 在TDZ中的情况。在 let/const 的TDZ中，即使是 typeof 也会触发错误，因为它仍然是一种访问。
严格模式（Strict Mode）的影响
在严格模式下（'use strict';），虽然变量提升的基本机制没有改变，但某些不规范的行为会被禁止，从而减少了因提升可能引发的潜在问题。例如，在严格模式下，不允许使用未声明的变量（即，隐式全局变量），这能帮助我们更好地管理变量的声明。然而，它并不会改变 function 和 var 提升的优先级或初始化行为。
总结与展望
通过今天的探讨，我们深入剖析了JavaScript中变量提升的机制，特别是 function 声明和 var 声明在词法环境创建阶段的时序差异。我们了解到，函数声明会优先被处理并完全初始化，而 var 变量则被初始化为 undefined。当两者同名时，函数声明会在创建阶段占据主导地位，而 var 声明的赋值操作则在执行阶段覆盖之前的值。
理解这些底层机制，是掌握JavaScript这门语言的关键一步。虽然现代JavaScript倾向于使用 let 和 const 来规避 var 的一些复杂性，但对 var 和 function 提升的深入理解，不仅能帮助我们更好地阅读和维护传统代码，更能培养我们对语言执行逻辑的深刻洞察力。通过遵循最佳实践，我们能够编写出更加清晰、健壮且可预测的JavaScript代码。