最近工作变动原因,开始从事前端工作,搞了一本《你不知道的JavaScript》系列. 拜读之后,收获颇丰.

作用域和闭包

作用域

将变量引入程序会引起几个很有意思的问题，也正是我们将要讨论的：这些变量住在哪里？换句话说，它们储存在哪里？最重要的是，程序需要时如何找到它们？

这些问题说明需要一套设计良好的规则来存储变量，并且之后可以方便地找到这些变量。这套规则被称为作用域。

编译原理

尽管JavaScript通常被归类为”动态“或”解释执行“语言，但事实上它是一门编译语音。但与传统的编译语言不同，它不是提前编译的，编译结果也不能在分布式系统中进行移植。

在传统编译语音的流程中，程序中的一段源代码在执行前会经历三个步骤，统称为”编译“。

• 分词/词法分析
  • 这个过程将由字符组成的字符串分解成有意义的代码块称为词法单元。例如var 2 = 2；这段程序通常被分解为以下词法单元，var、a、=、2、；。空格是否被视作词法单元，取决于不同语言的定义。
• 解析/语法分析
  • 这个过程将词法单元流（数组）转换成一个由元素逐级嵌套所组成的代表了程序语法的树。这个树称为"抽象语法树（Abstract Syntax Tree，AST）"。例如，var a = 2；的抽象语法树中可能会有一个叫做Identifier（它的值是a）的子节点，以及一个叫做AssignmentExpression的子节点。AssignmentExpression节点会有一个叫做NumericLiteral（它的值是2）的子节点。
• 代码生成
  • 将AST转换为可执行代码的过程被称为代码生成。抛开具体细节，简单来说就是有某种方法可以将var a = 2；的AST转换为一组机器指令，用来创建一个叫做a的变量（包括分配内存等），并将一个值储存在a中。

比起那些编译过程只有三个步骤的语言的编译器，JavaScript引擎要复杂的更多。例如，在解析和代码生成阶段有特定的步骤来对运行性能进行优化，包括对冗余元素进行优化等。这里只做宏观的简单的介绍，接下来会慢慢发现这些看起来高深的内容与所要讨论的事情有什关联。

首先，JavaScript引擎不会有大量的（像其他语言编译器那么多的）时间用来进行优化，因为与其他语言不同，JavaScript的编译过程不是发生在构建之前的。

对于JavaScript来说，大部分情况下编译发生在代码执行前的几微妙，甚至更短的时间内。在所要讨论的作用域背后，JavaScript引擎用尽了各种办法，比如JIT，可以延迟编译甚至实施重编译，来保证性能最佳。

简单来说，任何JavaSc代码片段在执行前都要进行编译（通常就是执行前）。因此，JavaScript编译器首先会对 var a = 2；这段程序进行编译，然后做好执行它的准备，并且通常马上就会执行它。

理解作用域✨✨✨

通过模拟几个人物间对话的方式来学习作用域。

角色

针对程序var a = 2；进行处理的过程中的角色有以下对话。

• 引擎：从头到尾负责整个JavaScript程序的编译及执行过程。
• 编译器：引擎的好朋友之一，负责分词、语法分析及代码生成等脏活累活。
• 作用域：引擎的另一位好朋友，负责收集并维护由所有声明的标志符（变量）组成的一系列查询，并实施一套非常严格的规则，确定当前执行的代码对这些标志符的访问权限。

对话✨

为了理解JavaScript的工作原理，需要开始像引擎和它的朋友们一样思考。

当看到var a = 2；这段程序时，会认为这是一句声明。但是引擎不这么看。事实上，引擎认为这里有俩个完全不同的声明，一个由编译器在编译时处理，另一个则由引擎在运行时处理。

下面将var a = 2；分解，看看引擎和它的朋友们如何协同工作的。

编译器首先会将这段程序分解成词法单元，然后将词法单元解析成一个树结构。但是当编译器开始进行代码生成时，它对这段程序的处理方式会和预期有所不同。

可以合理的假设编译器所产生的代码能够用下面的伪代码进行概括：”为一个变量分配内存，将其命名为a，然后将值2保存进这个变量。“ 然而，这并不完全正确。

事实上，编译器会进行如下处理：

1.遇到var a，编译器会询问作用域是否已经有了一个该名称的变量存在于同一个作用域的集合中。如果是，编译器会忽略该声明，继续进行编译；否则它会要求作用域在当前作用域的集合中声明一个新的变量，并命名为 a。

2.接下来编译器会为引擎生成运行时所需的代码，这些代码被用来处理 a = 2 这个赋值操作。引擎运行时会首先询问作用域，在当前的作用域集合中是否存在一个叫做 a 的变量。如果是，引擎会使用这个变量； 如果否，引擎会继续查找该变量。如果引擎最终找到了 a 变量，就会将 2 赋值给它。否则引擎就会举手示意，并抛出一个异常！

总结：变量的赋值操作会执行俩个动作，首先编译器会在当前作用域中声明一个变量（如果之前没有声明过），然后在运行时引擎会在作用域中查找该变量，如果能够找到就会对它赋值。

关于编译器

为了进一步理解，需要多介绍一点编译器术语。

编译器在编译过程中的第二步生成了代码，引擎执行它时，会通过查找变量a来判断是否已经声明过。查找的过程由作用域协助，但是引擎执行怎样的查找，会影响最终的查找结果。

在例子中，引擎为变量a进行了LHS（Left-Hand-Side）查询。还有一种查找的类型叫做RHS（Right-Hand-Side）。"L"和"R"代表左右，再准确点来说，是一个赋值操作的左侧和右侧。即：当变量出现在赋值操作的左侧时进行LHS查询，出现在赋值操作右侧时进行RHS查询。

更精准一点，RHS查询与简单的查找某个变量的值别无二致，而LHS查询则是试图找到变量的容器本身，从而可以对其赋值。

console.log(a)

其中对a的引用是一个RHS引用，因为这里a并没有赋予任何值。

相比之下，

a = 2

这里对a的引用则是LHS引用，并不关心当前值是什么，只是想要为=2这个赋值操作找到一个目标。

引擎和作用域✨

function foo(a){
	console.log(a) //2
}

foo(2)

以上代码想象成一段对话可能是下面这样的：

• 引擎：作用域，我需要为foo进行RHS引用，你见过它么？
• 作用域：见过，编译器刚声明了它，它是一个函数，给你。
• 引擎：够意思，我来执行一下foo。
• 引擎：作用域，还有个事，我需要为a进行LHS引用，你见过它么？
• 作用域：这个也见过，编译器最近把它声明为foo的一个形式参数了，拿去吧。
• 引擎：大恩不言谢，我现在要把2赋值给a。
• 引擎：不好意思，我现在要为console进行RHS引用，你见过它么？
• 作用域：这个有，console是个内置对象，给你。、
• 引擎：我得看看这里面有没有log()，太好了，找到了， 是一个函数。
• 引擎：哥们，能帮我再找一下对a的RHS引用么？虽然我记得它，但是我想再确认一下。
• 作用域：放心吧，这个变量就没有变动过。
• 引擎：真棒，我来把a的值，也就是2传递到log()
• ......

作用域嵌套

之前说过，作用域是根据名称查找变量的一套规则。实际上，通常需要同时顾及多个作用域嵌套的场景。

当一个块或函数嵌套在另一个块或函数中时， 就发生了作用域的嵌套。因此，在当前作用域中无法找到某个变量时，引擎就会在外层嵌套的作用域中继续查找， 直到找到该变量，或抵达最外层的作用域（也就是全局作用域）为止。

分析如下代码片段：

function foo(a){
	console.log(a + b)
}
var b = 2
foo(2)

对b进行的RHS引用无法在函数foo内部完成，但可以再上一级作用域中完成。

因此，引擎和作用域之间的对话如下：

• 引擎：foo的作用域兄弟，你见过b么？我需要对b进行RHS引用。
• 作用域：没听过，再见。
• 引擎：foo的上级作用域兄弟，你见过b么？我需要对它进行RHS引用。
• 作用域：当然了，拿去吧。

把作用域链比喻成一个建筑。

这个建筑代表程序中的嵌套作用域链，第一层代表当前之前执行作用域，建筑顶层代表全局作用域。

异常

为什么区分LHS和RHS是一件重要的事情？

因为在变量还没有声明，在任何作用域都无法找到该变量的情况下，这俩种查询的行为是不一样的。

思考如下代码：

function foo(a){
	console.log(a + b)
	b = a
}
foo(2)

分析：

• line5: foo的RHS
• line1: a的LHS，隐式
• line2: a的RHS
• line2: b的RHS，找不到
• line3 b的LHS
• line3: a的RHS

第一次对b进行RHS查询时是无法找到该变量的。这是一个"未声明"的变量，因为在任何相关的作用域中都无法找到它。

如果RHS查询在所有嵌套的作用域中找不到所需的变量，引擎就会抛出ReferenceError异常。

相比之下，当引擎执行LHS查询时，如果在顶层（全局作用域）中也无法找到目标变量，全局作用域就会创建一个具有该名称的变量，并将其返还给引擎，前提是程序运行在非"严格模式"下。

ES5中引入了"严格模式"。同正常模式，或者说宽松、懒惰模式相比，严格模式在行为上有很多不同。其中一个不同就是严格模式禁止自动或隐式的创建全局变量。因此，在严格模式中LHS查询失败时，并不会返回一个全局变量，引擎会抛出同RHS查询失败类似的ReferenceError异常。

如果RHS查询找到了一个变量，但是尝试对这个变量的值进行不合理的操作，比如试图对非函数类型的值进行函数调用，或者引用null或者undefined类型的值中的属性，那么引擎会抛出TypeError。

ReferenceError同作用域判别失败相关，而TypeError则代表作用域判别成功了，但是对结果操作是非法或不合理的。

小结✨

作用域是一套规则，用于确定在何处以及如何查找变量（标识符）​。如果查找的目的是对变量进行赋值，那么就会使用LHS查询；如果目的是获取变量的值，就会使用RHS查询。

LHS和RHS查询都会在当前执行作用域中开始，如果有需要（也就是说它们没有找到所需的标识符）​，就会向上级作用域继续查找目标标识符，这样每次上升一级作用域（一层楼）​，最后抵达全局作用域（顶层）​，无论找到或没找到都将停止。

ReferenceError同作用域判别失败相关，而TypeError则代表作用域判别成功了，但是对结果操作是非法或不合理的。

词法作用域

之前将""作用域"定义为一套规则，这套规则用来管理引擎如何在当前作用域及嵌套的作用域中根据标识符名称进行变量查找。作用域共俩种主要的工作模型。第一种是最普遍的，被大多数编程语言所采用的词法作用域，另一种是动态作用域，仍有一些编程语言在用，比如Bash脚本、Perl等，这里只做对比。重点关注词法作用域。

词法阶段

大部分标准语言编译器的第一个工作阶段叫做词法化，也叫单词化，词法化的过程会对源代码中的字符进行检查，如果是有状态的解析过程，还会赋予单词语义。

简单来说，词法作用域就是定义在词法阶段的作用域。换句话说，词法作用域是在写代码时将变量和块作用域写在哪里来决定的，因此当词法分析器处理代码时会保持作用域不变（大部分情况是这样的）。

这个概念是理解词法作用域及其名称来历的基础。

function foo(a){
	var b = a * 2
	functino bar(c){
		console.log(a, b, c)
	}
	bar(b * 3*)
}

foo(2) //

这里有三个逐级嵌套的作用域，为了方便理解，可以想象成几个逐级包含的气泡：

• ①包含着整个全局作用域，其中只有一个标识符：foo
• ②包含着foo所创建的作用域，其中有三个标识符：a、bar、b
• ③包含着bar所创建的作用域，其中只有一个标识符：c

查找

作用域气泡的结构和互相之间的位置关系给引擎提供了足够的位置信息，引擎用这些信息来查找标识符的位置。

在上一个代码片段中，引擎执行console.log(..)声明，并查找a、b和c三个变量的引用。它首先从最内部的作用域，也就是bar(..)函数的作用域气泡开始查找。引擎无法在这里找到a，因此会去上一级到所嵌套的foo(..)的作用域中继续查找。在这里找到了a，因此引擎使用了这个引用。对b来讲也是一样的。而对c来说，引擎在bar(..)中就找到了它。

如果a、c都存在于bar(..)和foo(..)的内部，console.log(..)就可以直接使用bar(..)中的变量，而无需到外面的foo(..)中查找。

作用域查找会在找到第一个匹配的标识符时停止。在多层的嵌套作用域中可以定义同名的标识符，这叫作“遮蔽效应”​（内部的标识符“遮蔽”了外部的标识符）​。抛开遮蔽效应，作用域查找始终从运行时所处的最内部作用域开始，逐级向外或者说向上进行，直到遇见第一个匹配的标识符为止。

全局变量会自动成为全局对象（比如浏览器中的window对象）的属性，因此可以不直接通过全局对象的词法名称，而是间接地通过对全局对象属性的引用来对其进行访问。比如：window.a

通过这种技术可以访问那些被同名变量所遮蔽的全局变量。但非全局的变量如果被遮蔽了，无论如何都无法被访问到。

无论函数在哪里被调用，也无论它如何被调用，它的词法作用域都只由函数被声明时所处的位置决定。

欺骗词法

如果词法作用域完全由写代码期间函数所声明的位置来定义，怎样才能在运行时来“修改”​（也可以说欺骗）词法作用域呢？

JavaScript中有俩种机制来实现这个目的。社区普遍认为使用这俩种机制并不是什么好主意，但其实争论中通常会忽略掉最重要的点：欺骗词法作用域会导致性能下降。

eval

JavaScript中的eval(..)函数可以接受一个字符串为参数，并将其中的内容视为好像在书写时就存在于程序中这个位置的代码。换句话说，可以在你写的代码中用程序生成代码并运行，就好像代码是写在那个位置的一样。

function foo(str, a){
	eval(str) // 欺骗！
	console.log(a, b)
}
var b = 2
foo("var b = 3", 1) // 输出 1. 3 而非 1， 2

和前面提到的原理一样，这段代码实际上在foo(..)内部创建了一个变量b，并遮蔽了外部（全局）作用域中的同名变量。当console.log(..)被执行时，会在foo(..)的内部同时找到a和b，但是永远也无法找到外部的b。因此会输出“1, 3”而不是正常情况下会输出的“1, 2”​。

with

JavaScript中另一个难以掌握（并且现在也不推荐使用）的用来欺骗词法作用域的功能是with关键字。with通常被当作重复引用同一个对象中的多个属性的快捷方式，可以不需要重复引用对象本身。

var obj = {
	a: 1,
	b: 2,
	c: 3
}

// 单调乏味的重复obj
obj.a=2
obj.b=3
obj.c=4

// 简单的快捷方式
with(obj){
	a = 3
	b = 4
	c = 5
}

但实际上这不仅仅是为了方便地访问对象属性。考虑如下代码：

function foo(obj){
	with(obj){
		a = 2
	}
}
var o1 = {
	a: 3
}
var o2 = {
	b: 3
}
foo(o1)
console.log(o1.a) // 2
foo(o2)
console.log(o2.a) // undefined
console.log(a) //2 : 糟糕，a被泄露到全局作用域上了！！

当我们将o1传递进去，a=2赋值操作找到了o1.a并将2赋值给它，这在后面的console.log(o1.a)中可以体现。而当o2传递进去，o2并没有a属性，因此不会创建这个属性，o2.a保持undefined。

但是可以注意到一个奇怪的副作用，实际上a = 2赋值操作创建了一个全局的变量a。这是怎么回事？

with可以将一个没有或有多个属性的对象处理为一个完全隔离的词法作用域，因此这个对象的属性也会被处理为定义在这个作用域中的词法标识符。

可以这样理解，当我们传递o1给with时，with所声明的作用域是o1，而这个作用域中含有一个同o1.a属性相符的标识符。但当我们将o2作为作用域时，其中并没有a标识符，因此进行了正常的LHS标识符查找（查看第1章）​。o2的作用域、foo(..)的作用域和全局作用域中都没有找到标识符a，因此当a=2执行时，自动创建了一个全局变量（因为是非严格模式）​。

性能

JavaScript引擎会在编译阶段进行数项的性能优化。其中有些优化依赖于能够根据代码的词法进行静态分析，并预先确定所有变量和函数的定义位置，才能在执行过程中快速找到标识符。

但如果引擎在代码中发现了eval(..)或with，它只能简单地假设关于标识符位置的判断都是无效的，因为无法在词法分析阶段明确知道eval(..)会接收到什么代码，这些代码会如何对作用域进行修改，也无法知道传递给with用来创建新词法作用域的对象的内容到底是什么。

如果代码中大量使用eval(..)或with，那么运行起来一定会变得非常慢。无论引擎多聪明，试图将这些悲观情况的副作用限制在最小范围内，也无法避免如果没有这些优化，代码会运行得更慢这个事实。

小结

词法作用域意味着作用域是由书写代码时函数声明的位置来决定的。编译的词法分析阶段基本能够知道全部标识符在哪里以及是如何声明的，从而能够预测在执行过程中如何对它们进行查找。

JavaScript中有两个机制可以“欺骗”词法作用域：eval(..)和with。这两个机制的副作用是引擎无法在编译时对作用域查找进行优化，因为引擎只能谨慎地认为这样的优化是无效的。使用这其中任何一个机制都将导致代码运行变慢。不要使用它们

函数作用域和块作用域

正如之前讨论的那样，作用域包含了一系列的“气泡”​，每一个都可以作为容器，其中包含了标识符（变量、函数）的定义。这些气泡互相嵌套并且整齐地排列成蜂窝型，排列的结构是在写代码时定义的。

但是，究竟是什么生成了一个新的气泡？只有函数会生成新的气泡吗？JavaScript中的其他结构能生成作用域气泡吗？

函数中的作用域

通常来讲JavaScript具有基于函数的作用域，意味着每声明一个函数都会为其自身创建一个气泡，而其他结构都不会创建作用域气泡。但事实上这并不完全正确，下面我们来看一下。首先需要研究一下函数作用域及其背后的一些内容。

functino foo(a){
	var b = 2
	// 一些代码
	function bar(){
		//...
	}
	var c = 3
}

在这个代码片段中，foo(..)的作用域气泡中包含了标识符a、b、c和bar。无论标识符声明出现在作用域中的何处，这个标识符所代表的变量或函数都将附属于所处作用域的气泡。

bar(..)拥有自己的作用域气泡。全局作用域也有自己的作用域气泡，它只包含了一个标识符：foo。

由于标识符a、b、c和bar都附属于foo(..)的作用域气泡，因此无法从foo(..)的外部对它们进行访问。也就是说，这些标识符全都无法从全局作用域中进行访问，因此下面的代码会导致ReferenceError错误：

bar() // 失败
console.log(a, b, c) // 3个都失败

但是，这些标识符（a、b、c、foo和bar）在foo(..)的内部都是可以被访问的，同样在bar(..)内部也可以被访问（假设bar(..)内部没有同名的标识符声明）​。

函数作用域的含义是指:：属于这个函数的全部变量都可以在整个函数的范围内使用及复用（事实上在嵌套的作用域中也可以使用）​。这种设计方案是非常有用的，能充分利用JavaScript变量可以根据需要改变值类型的“动态”特性。

隐藏内部实现

对函数的传统认知就是先声明一个函数，然后再向里面添加代码。但反过来想也可以带来一些启示：从所写的代码中挑选出一个任意的片段，然后用函数声明对它进行包装，实际上就是把这些代码“隐藏”起来了。

实际的结果就是在这个代码片段的周围创建了一个作用域气泡，也就是说这段代码中的任何声明（变量或函数）都将绑定在这个新创建的包装函数的作用域中，而不是先前所在的作用域中。换句话说，可以把变量和函数包裹在一个函数的作用域中，然后用这个作用域来“隐藏”它们。

为什么“隐藏”变量和函数是一个有用的技术？

有很多原因促成了这种基于作用域的隐藏方法。它们大都是从最小特权原则中引申出来的，也叫最小授权或最小暴露原则。这个原则是指在软件设计中，应该最小限度地暴露必要内容，而将其他内容都“隐藏”起来，比如某个模块或对象的API设计。

例如：

function doSomething(a){
	b = a + doSomethingElse(a * 2)
	console.log(b * 3)
}
function doSomethingElse(a){
	return a - 1
}
var b 
doSomething(2) // 15

在这个代码片段中，变量b和函数doSomethingElse(..)应该是doSomething(..)内部具体实现的“私有”内容。给予外部作用域对b和doSomethingElse(..)的“访问权限”不仅没有必要，而且可能是“危险”的，因为它们可能被有意或无意地以非预期的方式使用，从而导致超出了doSomething(..)的适用条件。更“合理”的设计会将这些私有的具体内容隐藏在doSomething(..)内部，例如：

function doSomething(a){
	function doSomethingElse(a){
		return a - 1
	}
	var b
	b = a + doSomethingElse(a * 2)
	console.log(b *3)
}
doSomething(2) // 15

现在，b和doSomethingElse(..)都无法从外部被访问，而只能被doSomething(..)所控制。功能性和最终效果都没有受影响，但是设计上将具体内容私有化了，设计良好的软件都会依此进行实现。

规避冲突

“隐藏”作用域中的变量和函数所带来的另一个好处，是可以避免同名标识符之间的冲突，两个标识符可能具有相同的名字但用途却不一样，无意间可能造成命名冲突。冲突会导致变量的值被意外覆盖。

例如：

function foo(){
	function bar(a){
		i = 3 // 修改for循环所属作用域中的i
		console.log(a + i)
	}
	for(var i = 0; i < 10; i++){
		bar(i * 2) // 无限循环了
	}
}
foo()

bar(..)内部的赋值表达式i = 3意外地覆盖了声明在foo(..)内部for循环中的i。在这个例子中将会导致无限循环，因为i被固定设置为3，永远满足小于10这个条件。

全局命名空间

变量冲突的一个典型例子存在于全局作用域中。当程序中加载了多个第三方库时，如果它们没有妥善地将内部私有的函数或变量隐藏起来，就会很容易引发冲突。

这些库通常会在全局作用域中声明一个名字足够独特的变量，通常是一个对象。这个对象被用作库的命名空间，所有需要暴露给外界的功能都会成为这个对象（命名空间）的属性，而不是将自己的标识符暴露在顶级的词法作用域中。

例如：

var MyReallyCoolLibrary = {
	awesome: "stuff",
	doSomething: function(){
		// ...
	},
	doAnotherThing: functino(){
		// ...
	}
}

模块管理

另外一种避免冲突的办法和现代的模块机制很接近，就是从众多模块管理器中挑选一个来使用。使用这些工具，任何库都无需将标识符加入到全局作用域中，而是通过依赖管理器的机制将库的标识符显式地导入到另外一个特定的作用域中。

函数作用域

已经确认在任意代码片段外部添加包装函数，可以将内部的变量和函数定义“隐藏”起来，外部作用域无法访问包装函数内部的任何内容。

例如：

var a = 2
function foo(){ // 添加这一行
	var a = 3
	console.log(a) // 3
} // 以及这一行
foo() // 以及这一行
console.log(a) // 2

虽然这种技术可以解决一些问题，但是它并不理想，因为会导致一些额外的问题。首先，必须声明一个具名函数foo()，意味着foo这个名称本身“污染”了所在作用域（在这个例子中是全局作用域）​。其次，必须显式地通过函数名（foo()）调用这个函数才能运行其中的代码。

如果函数不需要函数名（或者至少函数名可以不污染所在作用域）​，并且能够自动运行，这将会更加理想。幸好，JavaScript提供了能够同时解决这两个问题的方案、

修改后：

var a = 2
(function foo(){ // 添加这一行
	var a = 3
	console.log(a) // 3
})() // 以及这一行
console.log(a) // 2

分析一下这里发生了什么：

首先，包装函数的声明以(function..．而不仅是以function..．开始。尽管看上去这并不是一个很显眼的细节，但实际上却是非常重要的区别：函数会被当作函数表达式而不是一个标准的函数声明来处理。

区分函数声明和表达式最简单的方法是看function关键字出现在声明中的位置（不仅仅是一行代码，而是整个声明中的位置）​。如果function是声明中的第一个词，那么就是一个函数声明，否则就是一个函数表达式。

函数声明和函数表达式之间最重要的区别是它们的名称标识符将会绑定在何处。

比较一下前面两个代码片段。第一个片段中foo被绑定在所在作用域中，可以直接通过foo()来调用它。第二个片段中foo被绑定在函数表达式自身的函数中而不是所在作用域中。

换句话说，(function foo(){ .. })作为函数表达式意味着foo只能在 .. 所代表的位置中被访问，外部作用域则不行。foo变量名被隐藏在自身中意味着不会非必要地污染外部作用域。

匿名和具名✨

对于函数表达式最熟悉的场景可能就是回调参数了，比如：

setTimeout(function() {
	console.log("wait 1 seconde")
}, 1000)

这叫作匿名函数表达式，因为function().．没有名称标识符。函数表达式可以是匿名的，而函数声明则不可以省略函数名——在JavaScript的语法中这是非法的。

匿名函数表达式书写起来简单快捷，很多库和工具也倾向鼓励使用这种风格的代码。但是它也有几个缺点需要考虑。

1．匿名函数在栈追踪中不会显示出有意义的函数名，使得调试很困难。 2．如果没有函数名，当函数需要引用自身时只能使用已经过期的arguments.callee引用，比如在递归中。另一个函数需要引用自身的例子，是在事件触发后事件监听器需要解绑自身。 3．匿名函数省略了对于代码可读性/可理解性很重要的函数名。一个描述性的名称可以让代码不言自明。

行内函数表达式非常强大且有用——匿名和具名之间的区别并不会对这点有任何影响。给函数表达式指定一个函数名可以有效解决以上问题。始终给函数表达式命名是一个最佳实践：

setTimeout(function timeoutHandler(){ // yeah  有名字了
	console.log("waited 1 seconde")
}, 1000)

立即执行函数表达式(IIFE)✨

var a = 2
(function foo(){
	var a = 3
	console.log(a) // 3
})()
console.log(a) // 2

由于函数被包含在一对()括号内部，因此成为了一个表达式，通过在末尾加上另外一个()可以立即执行这个函数，比如(function foo(){ .. })()。第一个()将函数变成表达式，第二个()执行了这个函数。

这种模式很常见，几年前社区给它规定了一个术语：IIFE，代表立即执行函数表达式（Immediately Invoked Function Expression）​；

函数名对IIFE当然不是必须的，IIFE最常见的用法是使用一个匿名函数表达式。虽然使用具名函数的IIFE并不常见，但它具有上述匿名函数表达式的所有优势，因此也是一个值得推广的实践。

var a = 2
(function IIFE(){
	var a = 3
	console.log(a) // 3
})()
console.log(a) // 2

相较于传统的IIFE形式，很多人都更喜欢另一个改进的形式：(function(){ .. }())。仔细观察其中的区别。第一种形式中函数表达式被包含在()中，然后在后面用另一个()括号来调用。第二种形式中用来调用的()括号被移进了用来包装的()括号中。

这两种形式在功能上是一致的。选择哪个全凭个人喜好。

IIFE的另一个非常普遍的进阶用法是把它们当作函数调用并传递参数进去。

var a = 2
(function IIFE(global){
	var a = 3
	console.log(a) // 3
	console.log(global.a) // 2
})(window)

console.log(a) // 2

IIFE还有一种变化的用途是倒置代码的运行顺序，将需要运行的函数放在第二位，在IIFE执行之后当作参数传递进去。这种模式在UMD（Universal Module Definition）项目中被广泛使用。尽管这种模式略显冗长，但有些人认为它更易理解。

var a = 2
(function IIFE(def){
	def(window)
})(function def(global){
	var a = 3
	console.log(a) // 3
	console.log(global.a) // 2
})

函数表达式def定义在片段的第二部分，然后当作参数（这个参数也叫作def）被传递进IIFE函数定义的第一部分中。最后，参数def（也就是传递进去的函数）被调用，并将window传入当作global参数的值。

块作用域

尽管函数作用域是最常见的作用域单元，当然也是现行大多数JavaScript中最普遍的设计方法，但其他类型的作用域单元也是存在的。

尽管你可能连一行带有块作用域风格的代码都没有写过，但对下面这种很常见的JavaScript代码一定很熟悉：

for(var i = 0; i < 10; i++){
	console.log(i)
}

在for循环的头部直接定义了变量i，通常是因为只想在for循环内部的上下文中使用i，而忽略了i会被绑定在外部作用域（函数或全局）中的事实。

这就是块作用域的用处。变量的声明应该距离使用的地方越近越好，并最大限度地本地化。另外一个例子：

var foo = true
if(foo){
	var bar = foo * 2
	bar = something(bar)
	console.log(bar)
}

bar变量仅在if声明的上下文中使用，因此如果能将它声明在if块内部中会是一个很有意义的事情。但是，当使用var声明变量时，它写在哪里都是一样的，因为它们最终都会属于外部作用域。 这段代码是为了风格更易读而伪装出的形式上的块作用域，如果使用这种形式，要确保没在作用域其他地方意外地使用bar只能依靠自觉性。

块作用域是一个用来对之前的最小授权原则进行扩展的工具，将代码从在函数中隐藏信息扩展为在块中隐藏信息。

可惜，表面上看JavaScript并没有块作用域的相关功能，除非你更加深入地研究。

with

with关键字。它不仅是一个难于理解的结构，同时也是块作用域的一个例子（块作用域的一种形式）​，用with从对象中创建出的作用域仅在with声明中而非外部作用域中有效。

try catch

少有人会注意到JavaScript的ES3规范中规定try/catch的catch分句会创建一个块作用域，其中声明的变量仅在catch内部有效。

例如：

try{
	undefined() // 执行一个非法操作来强制制造一个异常
}
catch(err){
	console.log(err) // 能够正常执行
}

console.log(err) // ReferenceError: err not found

正如你所看到的，err仅存在catch分句内部，当试图从别处引用它时会抛出错误。

let

ES6改变了现状，引入了新的let关键字，提供了除var以外的另一种变量声明方式。

let关键字可以将变量绑定到所在的任意作用域中（通常是{ .. }内部）​。换句话说，let为其声明的变量隐式地劫持了所在的块作用域。

var foo = true
if(foo){
	let bar = foo * 2
	bar = something(bar)
	console.log(bar)
}

console.log(bar) // ReferenceError

之后会讨论提升，提升是指声明会被视为存在于其所出现的作用域的整个范围内。

但是使用let进行的声明不会在块作用域中进行提升。声明的代码被运行之前，声明并不“存在”。

{
	console.log(bar) // ReferenceError
	let bar = 2
}

垃圾收集

另一个块作用域非常有用的原因和闭包及回收内存垃圾的回收机制相关。这里简要说明一下，而内部的实现原理，也就是闭包的机制会在后续讨论。

考虑如下代码：

function process(data){
	// do something
}

var someReallyBigData = {..}

process(someReallyBigData)

var btn = doucument.getElementById("my button")

btn.addEventListener("click", functino click(evt){
	console.log("button clicked")
}, /*capturingPhase=*/false)

click函数的点击回调并不需要someReallyBigData变量。理论上这意味着当process(..)执行后，在内存中占用大量空间的数据结构就可以被垃圾回收了。但是，由于click函数形成了一个覆盖整个作用域的闭包，JavaScript引擎极有可能依然保存着这个结构（取决于具体实现）​。

块作用域可以打消这种顾虑，可以让引擎清楚地知道没有必要继续保存someReallyBigData了：

function process(data){
	// do something
}

// 在这个块中定义的内容完事可以销毁
{
	let someReallyBigData = {..}
	process(someReallyBigData)
}

process(someReallyBigData)

var btn = doucument.getElementById("my button")

btn.addEventListener("click", functino click(evt){
	console.log("button clicked")
}, /*capturingPhase=*/false)

let循环

一个let可以发挥优势的典型例子就是之前讨论的for循环。

for(let i=0; i<10; i++){
	console.log(i)
}

console.log(i) // ReferenceError

for循环头部的let不仅将i绑定到了for循环的块中，事实上它将其重新绑定到了循环的每一个迭代中，确保使用上一个循环迭代结束时的值重新进行赋值。

下面通过另一种方式来说明每次迭代时进行重新绑定的行为：

{
	let j
	for(j=0; j<10; j++){
		let i = j // 每个迭代重新绑定！
		console.log(i)
	}
}

每个迭代进行重新绑定非常有趣，讨论闭包时再进行详细说明。

const

除了let以外，ES6还引入了const，同样可以用来创建块作用域变量，但其值是固定的（常量）​。之后任何试图修改值的操作都会引起错误。

小结

函数是JavaScript中最常见的作用域单元。本质上，声明在一个函数内部的变量或函数会在所处的作用域中“隐藏”起来，这是有意为之的良好软件的设计原则。

但函数不是唯一的作用域单元。块作用域指的是变量和函数不仅可以属于所处的作用域，也可以属于某个代码块（通常指{ .. }内部）​。

从ES3开始，try/catch结构在catch分句中具有块作用域。

在ES6中引入了let关键字（var关键字的表亲）​，用来在任意代码块中声明变量。if (..){ let a = 2; }会声明一个劫持了if的{ .. }块的变量，并且将变量添加到这个块中。

提升✨✨✨

到现在为止，已经很熟悉作用域的概念，以及根据声明的位置和方式将变量分配给作用域的相关原理了。函数作用域和块作用域的行为是一样的，可以总结为：任何声明在某个作用域内的变量，都将附属于这个作用域。

但是作用域同其中的变量声明出现的位置有某种微妙的联系。

先有鸡还是先有蛋

直觉上会认为JavaScript代码在执行时是由上到下一行一行执行的。但实际上这并不完全正确，有一种特殊情况会导致这个假设是错误的。

考虑如下代码：

a = 2
var a
console.log(a)

很多开发者会认为是undefined，因为var a声明在a = 2之后，他们自然而然地认为变量被重新赋值了，因此会被赋予默认值undefined。但是，真正的输出结果是2。

考虑另外一段代码：

console.log(a)
var a = 2

鉴于上一个代码片段所表现出来的某种非自上而下的行为特点，你可能会认为这个代码片段也会有同样的行为而输出2。还有人可能会认为，由于变量a在使用前没有先进行声明，因此会抛出ReferenceError异常。不幸的是两种猜测都是不对的。输出来的会是undefined。

那么到底发生了什么？看起来我们面对的是一个先有鸡还是先有蛋的问题。

编译器再度来袭

为了搞明白这个问题，我们需要回顾一下关于编译器的内容。回忆一下，引擎会在解释JavaScript代码之前首先对其进行编译。编译阶段中的一部分工作就是找到所有的声明，并用合适的作用域将它们关联起来。前文展示了这个机制，也正是词法作用域的核心内容。

因此，正确的思考思路是：包括变量和函数在内的所有声明都会在任何代码被执行前首先被处理。

当你看到var a = 2；时，可能会认为这是一个声明。但JavaScript实际上会将其看成两个声明：var a；和a = 2;。第一个定义声明是在编译阶段进行的。第二个赋值声明会被留在原地等待执行阶段。

第一个代码片段将会以如下形式进行处理：

var a
a = 2
console.log(a)

其中第一部分编译，而第二部分是执行。

类似的，第二个代码片段实际是按照一下流程处理的：

var a
console.log(a)
a = 2

因此，打个比方，这个过程就好像变量和函数声明从它们在代码中出现的位置被“移动”到了最上面。这个过程就叫作提升。

只有声明本身会被提升，而赋值或其他运行逻辑会留在原地。如果提升改变了代码执行的顺序，会造成非常严重的破坏。

foo()

function foo(){
	console.log(a) // undefined
	var a = 2
}

/*
foo函数的声明（这个例子还包括实际函数的隐含值）被提升了，因此第一行中的调用可以正常执行。
*/

值得注意的是，每个作用域都会进行提升操作。尽管前面大部分的代码片段已经简化了（因为它们只包含全局作用域）​，而我们正在讨论的foo(..)函数自身也会在内部对var a进行提升（显然并不是提升到了整个程序的最上方）​。因此这段代码实际上会被理解为下面的形式：

function foo(){
	var a 
	console.log(a) // undefined
	a = 2
}

foo()

可以看到，函数声明会被提升，但是函数表达式却不会被提升。

foo()   // 不是ReferenceError,  而是TypeError
var foo = function bar(){
	// ...
}

/*
这段程序中的变量标识符foo()被提升并分配给所在作用域（在这里是全局作用域）​，因此foo()不会导致ReferenceError。但是foo此时并没有赋值（如果它是一个函数声明而不是函数表达式，那么就会赋值）​。foo()由于对undefined值进行函数调用而导致非法操作，因此抛出TypeError异常。
*/

同时，即使是具名的函数表达式，名称标识符在赋值之前也无法在所在作用域中使用：

foo() // TypeError
bar() // ReferenceError

var foo = function bar(){
	// ...
}

这个代码经过提升后，实际上会被理解为以下形式：

var foo

foo() // TypeError
bar() // ReferenceError

foo() = function(){
	var bar = ...self...
	// ...
}

函数优先

函数声明和变量声明都会被提升。但是一个值得注意的细节（这个细节可以出现在有多个“重复”声明的代码中）是函数会首先被提升，然后才是变量。

考虑以下代码：

foo() // 1

var foo

function foo(){
	console.log(1)
}

foo = function(){
	console.log(2)
}

会输出1而不是2！这个代码片段会被引擎理解为如下形式：

function foo(){
	console.log(1)
}

foo() // 1

foo = function(){
	console.log(2)
}

注意，var foo尽管出现在function foo()..．的声明之前，但它是重复的声明（因此被忽略了）​，因为函数声明会被提升到普通变量之前。

尽管重复的var声明会被忽略掉，但出现在后面的函数声明还是可以覆盖前面的。

foo()

function foo(){
	console.log(1)
}

var foo = function(){
	console.log(2)
}

function foo(){
	console.log(3)
}

虽然这些听起来都是些无用的学院理论，但是它说明了在同一个作用域中进行重复定义是非常糟糕的，而且经常会导致各种奇怪的问题。

小结

我们习惯将var a = 2；看作一个声明，而实际上JavaScript引擎并不这么认为。它将var a和a = 2当作两个单独的声明，第一个是编译阶段的任务，而第二个则是执行阶段的任务。

这意味着无论作用域中的声明出现在什么地方，都将在代码本身被执行前首先进行处理。可以将这个过程形象地想象成所有的声明（变量和函数）都会被“移动”到各自作用域的最顶端，这个过程被称为提升。

声明本身会被提升，而包括函数表达式的赋值在内的赋值操作并不会提升。

要注意避免重复声明，特别是当普通的var声明和函数声明混合在一起的时候，否则会引起很多危险的问题！

作用域闭包

相关信息

接下来的内容需要对作用域工作原理相关的基础知识有非常深入的理解。

我们将注意力转移到这门语言中一个非常重要但又难以掌握，近乎神话的概念上：闭包。

启示

提示

javaScript中闭包无处不在，你只需要能够识别并拥抱它。闭包并不是一个需要学习新的语法或模式才能使用的工具，它也不是一件必须接受像Luke一样的原力训练才能使用和掌握的武器。闭包是基于词法作用域书写代码时所产生的自然结果，你甚至不需要为了利用它们而有意识地创建闭包。闭包的创建和使用在你的代码中随处可见。你缺少的是根据你自己的意愿来识别、拥抱和影响闭包的思维环境。

实质问题

提示

当函数可以记住并访问所在的词法作用域时，就产生了闭包，即使函数是在当前词法作用域之外执行。

参考以下代码：

function foo(){
	var a = 2
	function bar(){
		console.log(a) //2
	}
	bar()
}
foo()

基于词法作用域的查找规则，函数bar()可以访问外部作用域中的变量a，并且属于一个RHS引用查询。

这是闭包么？

技术上来讲，也许是。但根据前面的定义，确切地说并不是。我认为最准确地用来解释bar()对a的引用的方法是词法作用域的查找规则，而这些规则只是闭包的一部分。​（但却是非常重要的一部分！）

从纯学术的角度说，在上面的代码片段中，函数bar()具有一个涵盖foo()作用域的闭包（事实上，涵盖了它能访问的所有作用域，比如全局作用域）​。也可以认为bar()封闭了foo()的作用域中。为什么呢？原因简单明了，因为bar()嵌套在foo()内部。

但是通过这种方式定义的闭包并不能直接进行观察，也无法明白在这个代码片段中闭包是如何工作的。我们可以很容易地理解词法作用域，而闭包则隐藏在代码之后的神秘阴影里，并不那么容易理解。

再来看一段代码，清晰的展示了闭包：

function foo(){
	var a = 2

	function bar(){
		console.log(a)
	}

	return bar
}

var baz = foo()
baz()  // 2,  这就是闭包的效果！！

函数bar()的词法作用域能够访问foo()的内部作用域。然后我们将bar()函数本身当作一个值类型进行传递。在这个例子中，我们将bar所引用的函数对象本身当作返回值。

在foo()执行后，其返回值（也就是内部的bar()函数）赋值给变量baz并调用baz()，实际上只是通过不同的标识符引用调用了内部的函数bar()。

bar()显然可以被正常执行。但是在这个例子中，它在自己定义的词法作用域以外的地方执行。

在foo()执行后，通常会期待foo()的整个内部作用域都被销毁，因为我们知道引擎有垃圾回收器用来释放不再使用的内存空间。由于看上去foo()的内容不会再被使用，所以很自然地会考虑对其进行回收。

而闭包的“神奇”之处正是可以阻止这件事情的发生。事实上内部作用域依然存在，因此没有被回收。谁在使用这个内部作用域？原来是bar()本身在使用。

拜bar()所声明的位置所赐，它拥有涵盖foo()内部作用域的闭包，使得该作用域能够一直存活，以供bar()在之后任何时间进行引用。

bar()依然持有对该作用域的引用，而这个引用就叫作闭包。

因此，在几微秒之后变量baz被实际调用（调用内部函数bar）​，不出意外它可以访问定义时的词法作用域，因此它也可以如预期般访问变量a。

这个函数在定义时的词法作用域以外的地方被调用。闭包使得函数可以继续访问定义时的词法作用域。

当然，无论使用何种方式对函数类型的值进行传递，当函数在别处被调用时都可以观察到闭包。

function foo(){
	var a = 2
	function baz(){
		console.log(a) // 2
	}
	bar(baz)
}

function bar(fn){
	fn() // 这就是闭包！！因为函数作为参数传递了进来，也就是说函数在别处被调用了呀！！！
}

把内部函数baz传递给bar，当调用这个内部函数时（现在叫作fn）​，它涵盖的foo()内部作用域的闭包就可以观察到了，因为它能够访问a。

传递函数当然也可以是间接的。

var fn 
function foo(){
	var a = 2
	function baz(){
		console.log(a)
	}
	fn = baz // 将baz分配给全局变量
}

function bar(){
	fn() // 函数在别处调用了！！！ 闭包了这就是！！！即便是间接的！！！
}

foo()
bar() // 2

重要

无论通过何种手段将内部函数传递到所在的词法作用域以外，它都会持有对原始定义作用域的引用，无论在何处执行这个函数都会使用闭包。

大师我悟了

相关信息

前面的代码片段有点死板，并且为了解释如何使用闭包而人为地在结构上进行了修饰。但我保证闭包绝不仅仅是一个好玩的玩具。你已经写过的代码中一定到处都是闭包的身影。现在让我们来搞懂这个事实。

function wait(msg){
	setTimeout(function timer(){
		console.log(msg)
	}, 1000)
}

wait("Hello~~~")

将一个内部函数（名为timer）传递给setTimeout(..)。timer具有涵盖wait(..)作用域的闭包，因此还保有对变量message的引用。

wait(..)执行1000毫秒后，它的内部作用域并不会消失，timer函数依然保有wait(..)作用域的闭包。

在引擎内部，内置的工具函数setTimeout(..)持有对一个参数的引用，这个参数也许叫作fn或者func，或者其他类似的名字。引擎会调用这个函数，在例子中就是内部的timer函数，而词法作用域在这个过程中保持完整。

这就是闭包。

本质上无论何时何地，如果将（访问它们各自词法作用域的）函数当作第一级的值类型并到处传递，你就会看到闭包在这些函数中的应用。在定时器、事件监听器、Ajax请求、跨窗口通信、Web Workers或者任何其他的异步（或者同步）任务中，只要使用了回调函数，实际上就是在使用闭包！

循环和闭包

要说明闭包，for循环是最常见的例子。

for(var i=1; i<=5; i++){
	setTimeout(function timer(){
		console.log(i)
	}, i*1000)
}

正常情况下，我们对这段代码行为的预期是分别输出数字1～5，每秒一次，每次一个。

但实际上，这段代码在运行时会以每秒一次的频率输出五次6。

这是为什么？

首先解释6是从哪里来的。这个循环的终止条件是i不再<=5。条件首次成立时i的值是6。因此，输出显示的是循环结束时i的最终值。

事实上，延迟函数的回调会在循环结束时才执行，当定时器运行时即使每个迭代中执行的是setTimeout(.., 0)，所有的回调函数依然是在循环结束后才会被执行，因此会每次输出一个6出来。

这里引伸出一个更深入的问题，代码中到底有什么缺陷导致它的行为同语义所暗示的不一致呢？

缺陷是：我们试图假设循环中的每个迭代在运行时都会给自己“捕获”一个i的副本。但是根据作用域的工作原理，实际情况是尽管循环中的五个函数是在各个迭代中分别定义的，但是它们都被封闭在一个共享的全局作用域中，因此实际上只有一个i。

这样说的话，当然所有函数共享一个i的引用。循环结构让我们误以为背后还有更复杂的机制在起作用，但实际上没有。如果将延迟函数的回调重复定义五次，完全不使用循环，那它同这段代码是完全等价的。

下面回到正题。缺陷是什么？我们需要更多的闭包作用域，特别是在循环的过程中每个迭代都需要一个闭包作用域。

之前介绍过，IIFE会通过声明并立即执行一个函数来创建作用域。我们来试一下：

for(var i=1; i<=5; i++){
	(function IIFE(){
		setTimeout(function timer(){
			console.log(i)
		}, i*1000)
	})()
}

这样不行。但是为什么呢？我们现在显然拥有更多的词法作用域了。的确每个延迟函数都会将IIFE在每次迭代中创建的作用域封闭起来。

如果作用域是空的，那么仅仅将它们进行封闭是不够的。仔细看一下，我们的IIFE只是一个什么都没有的空作用域。

它需要包含一点实质内容才能为我们所用。它需要有自己的变量，用来在每个迭代中储存i的值：

for(var i=1; i<=5; i++){
	(function IIFE(){
		var j = i
		setTimeout(function timer(){
			console.log(j)
		}, j*1000)
	})()
}

行了！它能正常工作了！。

可以对这段代码进行一些改进：

for(var i=1; i<=5; i++){
	(function IIFE(j){
		setTimeout(function timer(){
			console.log(j)
		}, j*1000)
	})(i)
}

当然，这些IIFE也不过就是函数，因此我们可以将i传递进去，如果愿意的话可以将变量名定为j，当然也可以还叫作i。无论如何这段代码现在可以工作了。

在迭代内使用IIFE会为每个迭代都生成一个新的作用域，使得延迟函数的回调可以将新的作用域封闭在每个迭代内部，每个迭代中都会含有一个具有正确值的变量供我们访问。

问题解决啦！

重返块作用域

仔细思考前面的解决方案。使用IIFE在每次迭代时都创建一个新的作用域。换句话说，每次迭代都需要一个块作用域。let声明，可以用来劫持块作用域，并且在这个块作用域中声明一个变量。本质上这是将一个块转换成一个可以被关闭的作用域。因此，下面这些看起来很酷的代码就可以正常运行了：

for(var i=1; i<=5; i++){
	let j = i // 似的！！ 闭包的块作用域！！！
	setTimeout(function timer(){
		console.log(j)
	}, j*1000)
}

但是，这还不是全部！for循环头部的let声明还会有一个特殊的行为。这个行为指出变量在循环过程中不止被声明一次，每次迭代都会声明。随后的每个迭代都会使用上一个迭代结束时的值来初始化这个变量。还可以优化为：

for(let i=1; i<=5; i++){
	setTimeout(function timer(){
		console.log(i)
	}, i*1000)
}

重要

块作用域和闭包联手便可天下无敌。

模块

提示

还有其他的代码模式利用闭包的强大威力，但从表面上看，它们似乎与回调无关。下面一起来研究其中最强大的一个：模块。

function foo(){
	var something = "cool"
	var another = [1, 2, 3]

	function doSomething(){
		console.log(something)
	}

	function doAnother(){
		console.log(another.join(" ! "))
	}
}

这里并没有明显的闭包，只有两个私有数据变量something和another，以及doSomething()和doAnother()两个内部函数，它们的词法作用域（而这就是闭包）也就是foo()的内部作用域。

考虑如下代码：

function CoolModule(){
	var something = "cool"
	var another = [1, 2, 3]

	function doSomething(){
		console.log(something)
	}

	function doAnother(){
		console.log(another.join(" ! "))
	}

	return {
		doSomething: doSomething,
		doAnother: doAnother
	}
}

var foo = CoolModule()

foo.doSomething() // cool
foo.doAnother() // 1 ! 2 ! 3

这个模式在JavaScript中被称为模块。最常见的实现模块模式的方法通常被称为模块暴露，这里展示的是其变体。

首先，CoolModule()只是一个函数，必须要通过调用它来创建一个模块实例。如果不执行外部函数，内部作用域和闭包都无法被创建。

其次，CoolModule()返回一个用对象字面量语法{ key: value, ... }来表示的对象。这个返回的对象中含有对内部函数而不是内部数据变量的引用。我们保持内部数据变量是隐藏且私有的状态。可以将这个对象类型的返回值看作本质上是模块的公共API。

这个对象类型的返回值最终被赋值给外部的变量foo，然后就可以通过它来访问API中的属性方法，比如foo.doSomething()。从模块中返回一个实际的对象并不是必须的，也可以直接返回一个内部函数。

doSomething()和doAnother()函数具有涵盖模块实例内部作用域的闭包（通过调用CoolModule()实现）​。当通过返回一个含有属性引用的对象的方式来将函数传递到词法作用域外部时，我们已经创造了可以观察和实践闭包的条件。

如果要更简单的描述，模块模式需要具备两个必要条件：

1．必须有外部的封闭函数，该函数必须至少被调用一次（每次调用都会创建一个新的模块实例）​。

2．封闭函数必须返回至少一个内部函数，这样内部函数才能在私有作用域中形成闭包，并且可以访问或者修改私有的状态。

上一个示例代码中有一个叫作CoolModule()的独立的模块创建器，可以被调用任意多次，每次调用都会创建一个新的模块实例。当只需要一个实例时，可以对这个模式进行简单的改进来实现单例模式：

var foo = (function CoolModule(){
	var something = "cool"
	var another = [1, 2, 3]

	function doSomething(){
		console.log(something)
	}

	function doAnother(){
		console.log(another.join(" ! "))
	}

	return {
		doSomething: doSomething,
		doAnother: doAnother
	}
})()

foo.doSomething() // cool
foo.doAnother() // 1 ! 2 ! 3

将模块函数转换成了IIFE​，立即调用这个函数并将返回值直接赋值给单例的模块实例标识符foo。

模块也是普通的函数，因此可以接受参数：

function CoolModule(id){
	function identify(){
		console.log(id)
	}
	return {
		identify: identify
	}
}

var foo1 = CoolModule("foo 1")
var foo2 = CoolModule("foo 2")

foo1.identify() // "foo 1"
foo2.identify() // "foo 2"

模块模式另一个简单但强大的用法是命名将要作为公共API返回的对象：

var foo = (function CoolModule(id){
	function change(){
		// 修改公共API
		publicAPI.identify = identify2
	}
	function identify(){
		console.log(id)
	}
	function identify2(){
		console.log(id.toUpperCase())
	}
	var publicAPI = {
		change: change,
		identify: identify1
	}
	return publicAPI
})("foo module")

foo.identify() // foo module
foo.change()
foo.identify() // FOO MODULE

通过在模块实例的内部保留对公共API对象的内部引用，可以从内部对模块实例进行修改，包括添加或删除方法和属性，以及修改它们的值。

现代的模块机制

大多数模块依赖加载器/管理器本质上都是将这种模块定义封装进一个友好的API。这里并不会研究某个具体的库，为了宏观了解简单地介绍一些核心概念：

var MyModule = (function Manager(){
	var modules = []

	function define(name. deps, impl){
		for(var i=0; i< deps.length; i++){
			deps[i] = modules[deps[i]]
		}
		modules[name] = impl.apply(impl, deps)
	}

	function get(name){
		return modules[name]
	}

	return {
		define: define,
		get: get
	}
})()

下面展示了如何使用它来定义模块：

MyModules.define("bar", [], function(){
	function hello(who){
		return "Let me introduce: "+ who
	}
	return {
		hello: hello
	}
})

MyModules.define("foo", ["bar"], function(bar){
	var hungry = "hippo"
	function awesome(){
		console.log(bar.hello(hungry).toUpperCase())
	}
	return {
		awesome: awesome
	}
})

var bar = MyModules.get("bar")
var foo = MyModules.get("foo")

console.log(bar.hello("hippo")) // Let me introduce: hippo
foo.awesome() // LET ME INTRODUCE: HIPPO

"foo"和"bar"模块都是通过一个返回公共API的函数来定义的。"foo"甚至接受"bar"的实例作为依赖参数，并能相应地使用它。

为我们自己着想，应该多花一点时间来研究这些示例代码并完全理解闭包的作用吧。最重要的是要理解模块管理器没有任何特殊的“魔力”​。它们符合前面列出的模块模式的两个特点：调用包装了函数定义的包装函数，并且将返回值作为该模块的API。换句话说，模块就是模块，即使在它们外层加上一个友好的包装工具也不会发生任何变化。

未来模块机制

ES6中为模块增加了一级语法支持。在通过模块系统进行加载时，ES6会将文件当作独立的模块来处理。每个模块都可以导入其他模块或特定的API成员，同样也可以导出自己的API成员。

基于函数的模块并不是一个能被静态识别的模式（编译器无法识别）​，它们的API语义只有在运行时才会被考虑进来。因此可以在运行时修改一个模块的API（参考前面关于publicAPI的讨论）​。

相比之下，ES6模块API是静态的（API不会在运行时改变）​。由于编辑器知道这一点，因此可以在（的确也这样做了）编译期检查对导入模块的API成员的引用是否真实存在。如果API引用并不存在，编译器会在编译时就抛出“早期”错误，而不会等到运行期再动态解析（并且报错）​。

ES6的模块没有“行内”格式，必须被定义在独立的文件中（一个文件一个模块）​。浏览器或引擎有一个默认的“模块加载器”​（可以被重载，但这远超出了我们的讨论范围）可以在导入模块时同步地加载模块文件。

考虑如下代码：

bar.js

function hello(who){
	return "Let me introduce: "+ who
}

export hello

foo.js

// 仅从 "bar" 模块 导入hello
import hello form "bar"

var hungry = "hippo"

function awesome(){
	console.lo(
		hello(hungry).toUpperCase()
	)
}

expoort awesome

baz.js

// 导入完整的"foo"和"bar"模块
module foo from "foo"
module bar from "bar" 

console.log(
	bar.hello("rhino")
) // Let me introduce: rhino

foo.awesome() // LET ME INTRODUCE: HIPPO

import可以将一个模块中的一个或多个API导入到当前作用域中，并分别绑定在一个变量上（在我们的例子里是hello）​。module会将整个模块的API导入并绑定到一个变量上（在我们的例子里是foo和bar）​。export会将当前模块的一个标识符（变量、函数）导出为公共API。这些操作可以在模块定义中根据需要使用任意多次。

小结

提示

闭包就好像从JavaScript中分离出来的一个充满神秘色彩的未开化世界，只有最勇敢的人才能够到达那里。但实际上它只是一个普通且明显的事实，那就是我们在词法作用域的环境下写代码，而其中的函数也是值，可以随意传来传去。

当函数可以记住并访问所在的词法作用域，即使函数是在当前词法作用域之外执行，这时就产生了闭包。

提示

如果没能认出闭包，也不了解它的工作原理，在使用它的过程中就很容易犯错，比如在循环中。但同时闭包也是一个非常强大的工具，可以用多种形式来实现模块等模式。

模块有两个主要特征：​（1）为创建内部作用域而调用了一个包装函数；​（2）包装函数的返回值必须至少包括一个对内部函数的引用，这样就会创建涵盖整个包装函数内部作用域的闭包。

重要

现在我们会发现代码中到处都有闭包存在，并且我们能够识别闭包然后用它来做一些有用的事！

---

this和对象原型

相关信息

本书第二部分“this和对象原型”非常不错，它很好地衔接了本书第一部分“作用域和闭包”​，进一步介绍了JavaScript语言中非常重要的两个部分，this关键字和原型。这两个部分对于你未来的学习来说非常重要，它们是使用JavaScript进行编程的基础。只有掌握了如何创建、关联和扩展对象，你才能用JavaScript创建类似谷歌地图这样大型的复杂应用。

关于this

提示

this关键字是JavaScript中最复杂的机制之一。它是一个很特别的关键字，被自动定义在所有函数的作用域中。但是即使是非常有经验的JavaScript开发者也很难说清它到底指向什么。

实际上，JavaScript中this的机制并没有那么先进，但是开发者往往会把理解过程复杂化，毫无疑问，在缺乏清晰认识的情况下，this对你来说完全就是一种魔法。

为什么用this

下面我们来解释一下为什么要使用this：

function identify(){
	return this.name.toUpperCase()
}

function speak(){
	var greeting = "Hello, I'm " + identify.call(this)
	console.log(greeting)
}

var me = {
	name: Kyle
}

var you = {
	name: Reader
}

identify.call(me) // KYLE
identify.call(you) // READER

speak.call(me) // Hello, I'm KYLE
speak.call(you) // Hello, I'm READER

看不懂这段代码？不用担心！我们很快就会讲解。现在请暂时抛开这些问题，专注于为什么。

这段代码可以在不同的上下文对象（me和you）中重复使用函数identify()和speak()，不用针对每个对象编写不同版本的函数。

如果不使用this，那就需要给identify()和speak()显式传入一个上下文对象。

function identify(context){
	return context.name.toUpperCase()
}

function speak(context){
	var greeting = "Hello, I'm " + identify(context)
	console.log(greeting)
}

var me = {
	name: Kyle
}

var you = {
	name: Reader
}

identify(you) // READER
speak(me) // Hello, I'm KYLE

然而，this提供了一种更优雅的方式来隐式“传递”一个对象引用，因此可以将API设计得更加简洁并且易于复用。

随着你的使用模式越来越复杂，显式传递上下文对象会让代码变得越来越混乱，使用this则不会这样。当我们介绍对象和原型时，你就会明白函数可以自动引用合适的上下文对象有多重要。

误解

重要

之后会解释this到底是如何工作的，但是首先需要消除一些关于this的错误认识。太拘泥于“this”的字面意思就会产生一些误解。有两种常见的对于this的解释，但是它们都是错误的。

(1)指向自身；(2)指向它的作用域，这俩种都是错误的！

指向自身

很容易把this理解成指向函数自身，这个推断从英语的语法角度来说是说得通的。

this并不像我们所想的那样指向函数本身。

参考以下代码：

function foo(num){
	console.log("foo: " + num)
	// 记录foo被调用的次数
	this.count++
}

foo.count = 0

var i
for(i=0; i< 10; i++){
	if(i>5){
		foo(i)
	}
}

// foo: 6
// foo: 7
// foo: 8
// foo: 9

// foo 被调用了多少次
console.log(foo.count) // 0 为什么？？？

console.log语句产生了4条输出，证明foo(..)确实被调用了4次，但是foo.count仍然是0。显然从字面意思来理解this是错误的。

执行foo.count = 0时，的确向函数对象foo添加了一个属性count。但是函数内部代码this.count中的this并不是指向那个函数对象，所以虽然属性名相同，根对象却并不相同，困惑随之产生。

提示

负责的开发者一定会问“如果我增加的count属性和预期的不一样，那我增加的是哪个count? ”实际上，如果他深入探索的话，就会发现这段代码在无意中创建了一个全局变量count，它的值为NaN。当然，如果他发现了这个奇怪的结果，那一定会接着问：​“为什么它是全局的，为什么它的值是NaN而不是其他更合适的值？​”​

遇到这样的问题时，许多开发者并不会深入思考为什么this的行为和预期的不一致，也不会试图回答那些很难解决但却非常重要的问题。他们只会回避这个问题并使用其他方法来达到目的，比如创建另一个带有count属性的对象。

function foo(num){
	console.log("foo: " + num)
	// 记录foo被调用的次数
	data.count++
}

var data = {
	count: 0
}

var i
for(i=0; i< 10; i++){
	if(i>5){
		foo(i)
	}
}

// foo: 6
// foo: 7
// foo: 8
// foo: 9

// foo 被调用了多少次
console.log(foo.count) // 4

重要

从某种角度来说这个方法确实“解决”了问题，但可惜它忽略了真正的问题——无法理解this的含义和工作原理——而是返回舒适区，使用了一种更熟悉的技术：词法作用域。

词法作用域是一种非常优秀并且有用的技术。丝毫没有贬低它的意思（可以参考第一部分“作用域和闭包”​）​。但是如果仅仅是因为无法猜对this的用法，就放弃学习this而去使用词法作用域，就不能算是一种很好的解决办法了。

如果要从函数对象内部引用它自身，那只使用this是不够的。一般来说你需要通过一个指向函数对象的词法标识符（变量）来引用它。

思考一下下面这两个函数：

function foo(){
	foo.count = 4 // foo 指向它自身
}

setTimeout(function(){
	// 匿名函数无法指向自身
}, 10)

第一个函数被称为具名函数，在它内部可以使用foo来引用自身。

但是在第二个例子中，传入setTimeout(..)的回调函数没有名称标识符（这种函数被称为匿名函数）​，因此无法从函数内部引用自身。（还有一种传统的但是现在已经被弃用和批判的用法，是使用arguments. callee来引用当前正在运行的函数对象。已弃用。）

所以，对于我们的例子来说，另一种解决方法是使用foo标识符替代this来引用函数对象：

function foo(num){
	console.log("foo: " + num)
	// 记录foo被调用的次数
	foo.count++
}

foo.count = 0

var i
for(i=0; i< 10; i++){
	if(i>5){
		foo(i)
	}
}

// foo: 6
// foo: 7
// foo: 8
// foo: 9

// foo 被调用了多少次
console.log(foo.count) // 4

然而，这种方法同样回避了this的问题，并且完全依赖于变量foo的词法作用域。

另一种方法是强制this指向foo函数对象：

function foo(num){
	console.log("foo: " + num)
	// 记录foo被调用的次数
	// 注意，在当前的调用方式下，this确实指向foo
	this.count++
}

foo.count = 0

var i
for(i=0; i< 10; i++){
	if(i>5){
		// 使用call(..) 可以确保this指向函数对象foo本身
		foo.call(foo, i)
	}
}

// foo: 6
// foo: 7
// foo: 8
// foo: 9

// foo 被调用了多少次
console.log(foo.count) // 4

这次我们接受了this，没有回避它。

指向它的作用域

第二种常见的误解是，this指向函数的作用域。这个问题有点复杂，因为在某种情况下它是正确的，但是在其他情况下它却是错误的。

需要明确的是，this在任何情况下都不指向函数的词法作用域。在JavaScript内部，作用域确实和对象类似，可见的标识符都是它的属性。但是作用域“对象”无法通过JavaScript代码访问，它存在于JavaScript引擎内部。

思考一下下面的代码，它试图（但是没有成功）跨越边界，使用this来隐式引用函数的词法作用域：

function foo(){
	var a = 2
	this.bar()
}

function bar(){
	console.log(this.a)
}

foo() // ReferenceError: a is not defined

首先，这段代码试图通过this.bar()来引用bar()函数。这样调用能成功纯属意外，我们之后会解释原因。调用bar()最自然的方法是省略前面的this，直接使用词法引用标识符。

此外，编写这段代码的开发者还试图使用this联通foo()和bar()的词法作用域，从而让bar()可以访问foo()作用域里的变量a。这是不可能实现的，使用this不可能在词法作用域中查到什么。

提示

每当你想要把this和词法作用域的查找混合使用时，一定要提醒自己，这是无法实现的。

this到底是什么

提示

this是在运行时进行绑定的，并不是在编写时绑定，它的上下文取决于函数调用时的各种条件。this的绑定和函数声明的位置没有任何关系，只取决于函数的调用方式。

当一个函数被调用时，会创建一个活动记录（有时候也称为执行上下文）​。这个记录会包含函数在哪里被调用（调用栈）​、函数的调用方式、传入的参数等信息。this就是这个记录的一个属性，会在函数执行的过程中用到。

小结

提示

this是非常重要的，但是猜测、试错和盲目地从Stack Overflow上复制和粘贴答案并不能让你真正理解this的机制。

提示

学习this的第一步是明白this既不指向函数自身也不指向函数的词法作用域，抛开以前错误的假设和理解。

提示

this实际上是在函数被调用时发生的绑定，它指向什么完全取决于函数在哪里被调用。

this解析

提示

排除了一些对于this的错误理解并且明白了每个函数的this是在调用时被绑定的，完全取决于函数的调用位置（也就是函数的调用方法）​。所以来看一下如何寻找函数的调用位置，从而判断函数在执行过程中会如何绑定this。

调用位置

通常来说，寻找调用位置就是寻找“函数被调用的位置”​，但是做起来并没有这么简单，因为某些编程模式可能会隐藏真正的调用位置。

最重要的是要分析调用栈（就是为了到达当前执行位置所调用的所有函数）​。我们关心的调用位置就在当前正在执行的函数的前一个调用中。

下面我们来看看到底什么是调用栈和调用位置：

function baz(){
	// 当前调用栈是： baz
	// 因此，当前调用位置是全局作用域

	console.log("baz")
	bar() // <-- bar的调用位置
}

function bar(){
	// 当前调用栈是 baz -> bar
	// 因此，当前调用位置在baz中

	console.log("bar")
	foo()
}

function foo(){
	// 当前调用栈是 bazs -> bar -> foo
	// 因此，当前调用位置在bar中

	console.log("foo")
}

baz() // <-- baz的调用位置

注意如何（从调用栈中）分析出真正的调用位置的，因为它决定了this的绑定。

绑定规则

相关信息

来看看在函数的执行过程中调用位置如何决定this的绑定对象。

必须找到调用位置，然后判断需要应用下面四条规则中的哪一条。

默认绑定

最常用的函数调用类型：独立函数调用。可以把这条规则看作是无法应用其他规则时的默认规则。

思考如下代码：

function foo(){
	console.log(this.a)
}

var a = 2
foo() // 2

应该注意到的第一件事是，声明在全局作用域中的变量（比如var a = 2）就是全局对象的一个同名属性。它们本质上就是同一个东西，并不是通过复制得到的。

可以看到当调用foo()时，this.a被解析成了全局变量a。为什么？因为在本例中，函数调用时应用了this的默认绑定，因此this指向全局对象。

那么我们怎么知道这里应用了默认绑定呢？可以通过分析调用位置来看看foo()是如何调用的。在代码中，foo()是直接使用不带任何修饰的函数引用进行调用的，因此只能使用默认绑定，无法应用其他规则。

如果使用严格模式（strict mode）​，则不能将全局对象用于默认绑定，因此this会绑定到undefined：

function foo(){
	"use strict"

	console.log(this.a)
}

var a = 2
foo() // TyepError: this is undefined

隐式绑定

提示

另一条需要考虑的规则是调用位置是否有上下文对象，或者说是否被某个对象拥有或者包含，不过这种说法可能会造成一些误导。

思考如下代码：

function foo(){
	console.log(this.a)
}

var obj = {
	a: 2,
	foo: foo
}

obj.foo() // 2

首先需要注意的是foo()的声明方式，及其之后是如何被当作引用属性添加到obj中的。但是无论是直接在obj中定义还是先定义再添加为引用属性，这个函数严格来说都不属于obj对象。

然而，调用位置会使用obj上下文来引用函数，因此你可以说函数被调用时obj对象“拥有”或者“包含”它。

无论你如何称呼这个模式，当foo()被调用时，它的前面确实加上了对obj的引用。当函数引用有上下文对象时，隐式绑定规则会把函数调用中的this绑定到这个上下文对象。因为调用foo()时this被绑定到obj，因此this.a和obj.a是一样的。

对象属性引用链中只有上一层或者说最后一层在调用位置中起作用。举例来说：

function foo(){
	console.log(this.a)
}

var obj2 = {
	a: 42,
	foo: foo
}

var obj1 = {
	a: 2,
	obj2: obj2
}

obj1.obj2.foo() // 42

隐式丢失

提示

一个最常见的this绑定问题就是被隐式绑定的函数会丢失绑定对象，也就是说它会应用默认绑定，从而把this绑定到全局对象或者undefined上，取决于是否是严格模式。

思考如下代码：

function foo(){
	console.log(this.a)
}

var obj = {
	a: 2,
	foo: foo
}

var bar = obj.foo // 函数别名

var a = "opps, global" // a是全局对象属性

bar() // "oops, global"

虽然bar是obj.foo的一个引用，但是实际上，它引用的是foo函数本身，因此此时的bar()其实是一个不带任何修饰的函数调用，因此应用了默认绑定。

一种更微妙、更常见并且更出乎意料的情况发生在传入回调函数时：

function foo(){
	console.log(this.a)
}

function doFoo(fn){
	// fn其实引用的是foo
	fn() // 调用位置
}

var obj = {
	a: 2,
	foo: foo
}

var a = "opps, global" // a是全局对象属性

doFoo(obj.foo) // "oops, global"

参数传递其实就是一种隐式赋值，因此我们传入函数时也会被隐式赋值，所以结果和上一个例子一样。

如果把函数传入语言内置的函数而不是传入你自己声明的函数，会发生什么呢？结果是一样的，没有区别：

function foo(){
	console.log(this.a)
}

var obj = {
	a: 2,
	foo: foo
}

var a = "oops, global"

setTimeout(obj.foo, 100) // "oops, global"

因为，其实JavaScript环境中内置的setTimeout()函数实现和下面的伪代码类似：

function setTimeout(fn, delay){
	// 等待delay毫秒
	fn() // 调用位置
}

相关信息

回调函数丢失this绑定是非常常见的。除此之外，还有一种情况this的行为会出乎我们意料：调用回调函数的函数可能会修改this。在一些流行的JavaScript库中事件处理器常会把回调函数的this强制绑定到触发事件的DOM元素上。这在一些情况下可能很有用，但是有时它可能会让你感到非常郁闷。遗憾的是，这些工具通常无法选择是否启用这个行为。

无论是哪种情况，this的改变都是意想不到的，实际上你无法控制回调函数的执行方式，因此就没有办法控制调用位置以得到期望的绑定。之后我们会介绍如何通过固定this来修复这个问题。

显式绑定

就像我们刚才看到的那样，在分析隐式绑定时，我们必须在一个对象内部包含一个指向函数的属性，并通过这个属性间接引用函数，从而把this间接（隐式）绑定到这个对象上。

那么如果我们不想在对象内部包含函数引用，而想在某个对象上强制调用函数，该怎么做呢？

JavaScript中的“所有”函数都有一些有用的特性（这和它们的Prototype有关。可以用来解决这个问题。具体点说，可以使用函数的call(..)和apply(..)方法。JavaScript提供的绝大多数函数以及你自己创建的所有函数都可以使用call(..)和apply(..)方法。

重要

这两个方法是如何工作的呢？它们的第一个参数是一个对象，是给this准备的，接着在调用函数时将其绑定到this。因为你可以直接指定this的绑定对象，因此我们称之为显式绑定。

思考如下代码：

function foo(){
	console.log(this.a)
}

var obj = {
	a: 2
}

foo.call(obj) // 2

通过foo.call(..)，我们可以在调用foo时强制把它的this绑定到obj上。

如果你传入了一个原始值（字符串类型、布尔类型或者数字类型）来当作this的绑定对象，这个原始值会被转换成它的对象形式（也就是new String(..)、new Boolean(..)或者new Number(..)）​。这通常被称为“装箱”​。

可惜，显式绑定仍然无法解决我们之前提出的丢失绑定问题

硬绑定

重要

但是显式绑定的一个变种可以解决这个问题。

思考如下代码：

function foo(){
	console.log(this.a)
}

var obj = {
	a: 2
}

var bar = function(){
	foo.call(obj)
}

bar() // 2
setTimeout(bar, 100) // 2

// 硬绑定的bar不可能再修改它的this
bar.call(window) // 2

首先创建了函数bar()，并在它的内部手动调用了foo.call(obj)，因此强制把foo的this绑定到了obj。无论之后如何调用函数bar，它总会手动在obj上调用foo。这种绑定是一种显式的强制绑定，因此我们称之为硬绑定。

硬绑定的典型应用场景就是创建一个包裹函数，负责接收参数并返回值：

function foo(something){
	console.log(this.a, something)
	return this.a + something
}

var obj = {
	a: 2
}

var bar = function(){
	return foo.apply(obj, arguments)
}

var b = bar(3) // 2 3
console.log(b) // 5

另一种使用方法是创建一个可以重复使用的辅助函数：

function foo(something){
	console.log(this.a, something)
	return this.a + something
}

// 简单的辅助绑定函数
function bind(fn, obj){
	return function(){
		return fn.apply(obj, arguments)
	}
}

var obj = {
	a: 2
}

var bar = bind(foo, obj)

var b = bar(3) // 2 3
console.log(b) // 5

由于硬绑定是一种非常常用的模式，所以ES5提供了内置的方法Function.prototype.bind，它的用法如下：

function foo(something){
	console.log(this.a, something)
	return this.a + something
}

var obj = {
	a: 2
}

var bar = foo.bind(foo, obj)

var b = bar(3) // 2 3
console.log(b) // 5

bind(..)会返回一个硬编码的新函数，它会把你指定的参数设置为this的上下文并调用原始函数。

API调用的"上下文"

提示

第三方库的许多函数，以及JavaScript语言和宿主环境中许多新的内置函数，都提供了一个可选的参数，通常被称为“上下文”​（context）​，其作用和bind(..)一样，确保你的回调函数使用指定的this。

举例说明：

function foo(el){
	console.log(el, this.id)
}

var obj = {
	id: "awesome"
}

// 调用foo(..)时把this绑定到obj
[1, 2, 3].forEach(foo, obj)
// 1 awesome 2 awesome 3 awesome

这些函数实际上就是通过call(..)或者apply(..)实现了显式绑定，这样你可以少写一些代码。

new绑定

讲解它之前我们首先需要澄清一个非常常见的关于JavaScript中函数和对象的误解。

在传统的面向类的语言中，​“构造函数”是类中的一些特殊方法，使用new初始化类时会调用类中的构造函数。通常的形式是这样的：

something = new MyClass(...)

JavaScript也有一个new操作符，使用方法看起来也和那些面向类的语言一样，绝大多数开发者都认为JavaScript中new的机制也和那些语言一样。然而，JavaScript中new的机制实际上和面向类的语言完全不同。

首先我们重新定义一下JavaScript中的“构造函数”​。在JavaScript中，构造函数只是一些使用new操作符时被调用的函数。它们并不会属于某个类，也不会实例化一个类。实际上，它们甚至都不能说是一种特殊的函数类型，它们只是被new操作符调用的普通函数而已。

举例来说，思考一下Number(..)作为构造函数时的行为，ES5.1中这样描述它：

当Number在new表达式中被调用时，它是一个构造函数：它会初始化新创建的对象。

所以，包括内置对象函数（比如Number(..)）在内的所有函数都可以用new来调用，这种函数调用被称为构造函数调用。这里有一个重要但是非常细微的区别：实际上并不存在所谓的“构造函数”​，只有对于函数的“构造调用”​。

使用new来调用函数，或者说发生构造函数调用时，会自动执行下面的操作。

1．创建（或者说构造）一个全新的对象。 2．这个新对象会被执行[​[Prototype]​]连接。 3．这个新对象会绑定到函数调用的this。 4．如果函数没有返回其他对象，那么new表达式中的函数调用会自动返回这个新对象。

我们现在关心的是第1步、第3步、第4步，所以暂时跳过第2步，思考下面的代码：

function foo(a){
	this.a = a
}

var bar = new foo(2)
console.log(bar.a) // 2

提示

使用new来调用foo(..)时，我们会构造一个新对象并把它绑定到foo(..)调用中的this上。new是最后一种可以影响函数调用时this绑定行为的方法，我们称之为new绑定。

优先级

提示

已经了解了函数调用中this绑定的四条规则，需要做的就是找到函数的调用位置并判断应当应用哪条规则。但是，如果某个调用位置可以应用多条规则该怎么办？为了解决这个问题就必须给这些规则设定优先级。毫无疑问，默认绑定的优先级是四条规则中最低的，所以我们可以先不考虑它。

隐式绑定和显式绑定哪个优先级更高？我们来测试一下：

function foo(){
	 console.log(this.a)
}

var obj1 = {
	a: 2,
	foo: foo
}

var obj2 = {
	a: 3,
	foo: foo
}

obj1.foo() // 2
obj2.foo() // 3

obj1.foo.call(obj2) // 3
obj2.foo.call(obj1) // 2

可以看到，显式绑定优先级更高，也就是说在判断时应当先考虑是否可以存在显式绑定。

现在需要搞清楚new绑定和隐式绑定的优先级谁高谁低：

function foo(something){
	this.a = something
}

var obj1 = {
	foo: foo
}

var obj2 = {}

obj1.foo(2)
console.log(obj1.a) // 2

obj1.foo.call(obj2, 3)
console.log(obj2.a) // 3

var bar = new obj1.foo(4)
console.log(obj1.a) // 2
console.log(bar.a) // 4

可以看到new绑定比隐式绑定优先级高。但是new绑定和显式绑定谁的优先级更高呢？

new和call/apply无法一起使用，因此无法通过new foo.call(obj1)来直接进行测试。但是我们可以使用硬绑定来测试它俩的优先级。

在看代码之前先回忆一下硬绑定是如何工作的。Function.prototype.bind(..)会创建一个新的包装函数，这个函数会忽略它当前的this绑定（无论绑定的对象是什么）​，并把我们提供的对象绑定到this上。

这样看起来硬绑定（也是显式绑定的一种）似乎比new绑定的优先级更高，无法使用new来控制this绑定。

看一下是不是这样：

function foo(something){
	this.a = something
}

var obj1 = {}

var bar = foo.bind(obj1)
bar(2)
console.log(obj1.a) // 2

var baz = new bar(3)
console.log(obj1.a) // 2
console.log(baz.a) // 3

出乎意料！bar被硬绑定到obj1上，但是new bar(3)并没有像我们预计的那样把obj1.a修改为3。相反，new修改了硬绑定（到obj1的）调用bar(..)中的this。因为使用了new绑定，我们得到了一个名字为baz的新对象，并且baz.a的值是3。

再来看看我们之前介绍的“裸”辅助函数bind：

function bind(fn, obj){
	return function(){
		fn.apply(obj, arguments)
	}
}

非常令人惊讶，因为看起来在辅助函数中new操作符的调用无法修改this绑定，但是在刚才的代码中new确实修改了this绑定。

实际上，ES5中内置的Function.prototype.bind(..)更加复杂。下面是MDN提供的一种bind(..)实现，为了方便阅读我们对代码进行了排版：

相关信息

这种bind(..)是一种polyfill代码（polyfill就是我们常说的刮墙用的腻子，polyfill代码主要用于旧浏览器的兼容，比如说在旧的浏览器中并没有内置bind函数，因此可以使用polyfill代码在旧浏览器中实现新的功能）​，对于new使用的硬绑定函数来说，这段polyfill代码和ES5内置的bind(..)函数并不完全相同（后面会介绍为什么要在new中使用硬绑定函数）​。由于polyfill并不是内置函数，所以无法创建一个不包含．prototype的函数，因此会具有一些副作用。如果你要在new中使用硬绑定函数并且依赖polyfill代码的话，一定要非常小心。

下面是new修改this的相关代码：

this instanceof fNOP && oThis ? this : oThis

// ..以及

fNOP.prototype = this.prototype
fBound.prototype = new fNOP()

这里就不详细解释这段代码做了什么（这非常复杂并且不在我们的讨论范围之内）​，不过简单来说，这段代码会判断硬绑定函数是否是被new调用，如果是的话就会使用新创建的this替换硬绑定的this。

之所以要在new中使用硬绑定函数，主要目的是预先设置函数的一些参数，这样在使用new进行初始化时就可以只传入其余的参数。bind(..)的功能之一就是可以把除了第一个参数（第一个参数用于绑定this）之外的其他参数都传给下层的函数（这种技术称为“部分应用”​，是“柯里化”的一种）​。举例来说：

function foo(p1, p2){
	this.val = p1 + p2
}

// 之所以使用null是因为在这里并不关心硬绑定的this是什么
// 反正使用new时会被修改

var bar = foo.bind(null, "p1")
var baz = new bar("p2")
baz.val // p1p2

判断this

现在可以根据优先级来判断函数在某个调用位置应用的是哪条规则。可以按照下面的顺序来进行判断：

1. 函数是否在new中调用（new绑定）​？如果是的话this绑定的是新创建的对象。

  var bar = new foo()

2. 函数是否通过call、apply（显式绑定）或者硬绑定调用？如果是的话，this绑定的是指定的对象。

var bar = foo.call(obj2)

3. 函数是否在某个上下文对象中调用（隐式绑定）​？如果是的话，this绑定的是那个上下文对象。

var bar = obj1.foo()

4. 如果都不是的话，使用默认绑定。如果在严格模式下，就绑定到undefined，否则绑定到全局对象。

var bar = foo()

5. 结束

   相关信息

   就是这样。对于正常的函数调用来说，理解了这些知识你就可以明白this的绑定原理了。不过……凡事总有例外。

版权所有

版权归属：Mars Chin

许可证：署名-非商业性 4.0 国际 (CC-BY-NC-4.0)