JavaScript 中的 this 经常会表现得让人抓摸不透，甚至让新手感到疑惑不解。
有些文章为了讲解 this，甚至有时会将它和其他概念混在一起讲解，但这只会让人更加疑惑，最后彻底迷失在这些概念中。
本文主要目标就是剔除这些概念的混淆，从本质上看清楚 this。在理解 this 的概念后，根据这些理解我会给出一些合理的建议。
理解 Lexical Scoping 和 Dynamic Scoping
在弄清 this 之前，需要理解静态作用域(Lexical Scoping，简称 LS ) 和 动态作用域(Dynamic Scoping，简称 DS ) 的概念。LS 和 DS 涉及到语言设计的层面，它们是不同类型的作用域。虽然在大多数情况下，它们表现类似，但在有些情况下，它们会表现出微妙的差别。而这些差别，真是我们被 this 迷惑的原因。
下面的这段代码，可以分辨出一种语言的作用域是 LS 还是 DS。
var a = 'I am Lexical Scoping' // a1
var b = function () {
console.log(a)
}
var c = function () {
var a = 'I am Dynamic Scoping' // a2
b()
}
c() // I am Lexical Scoping
将这代码复制黏贴到浏览器的控制台，就会发现 JavaScript 是 LS 的。
LS 和 DS 最根本的区别在于，它们对函数中的自由变量（上面例子中的 a 变量）具有不同的处理方式。
LS 会在函数声明的时候保存该函数所需要的自由变量(上面例子中的 a1)，并且在函数执行的时候调用前面保存的自由变量(上面例子中的 a1)。
DS 会在函数执行的时候寻找该函数所需要的自由变量(上面例子中的 a2)。因此在 DS 的语言中，上面的例子的执行结果应该是 'I am Dynamic Scoping'。
尽管 DS 更具有灵活性，因为如果能够允许函数的自由变量在执行的时候确定的话，那么一个函数就能在不同的上下文中表现出不同的效果。然而当我们写代码需要用到自由变量的时候，更倾向于在声明的时候确定自由变量。在这种情况下，DS 隐蔽的灵活性将是一场灾难。更致命的是，DS 破坏了函数的封闭性，函数不再作为一个黑箱，而有可能因为环境的变化而表现不同，导致耦合的产生。
假设例子中的 函数b 在另一个文件被调用，而那个文件中恰好声明了一个 变量a，那么就很可能会导致很多奇怪的事情发生。因为对于调用者而言，函数b 应该是一个黑盒，他不应该也没有义务费心思去了解 函数b 中有哪些自由变量。
出于以上的种种原因，现代语言几乎都采用 LS，而 JavaScript 自然也采用了 LS。但是 JavaScript 有一个致命的缺陷，那就是 JavaScript 中的 this 更倾向于表现得像 DS。
this 让人疑惑的原因
在 JavaScript 中，this 是在函数执行的时候才确定下来的(箭头函数除外)。
将上面的小例子转换下，得到下面的例子，就可以看出问题所在。
var name = 'I am window'
var a1 = {
name: 'I am Lexical',
b: function () {
// this 是在函数执行的时候确定
console.log(this.name)
}
}
var c = function () {
var a2 = {
name: 'I am Dynamic'
}
a2.b = a1.b
a2.b()
}
c() // I am Dynamic
而这就是 JavaScript 中的 this 表现得让人疑惑的根本原因。
箭头函数
为了解决这个问题，ES6 引入了箭头函数。箭头函数有一个重要的特点，就是在箭头函数的 this 是在函数定义的时候确定下来的，并且不管用 bind，call 还是 apply，箭头函数中的 this 都不会改变。怎么样，听起来很像静态作用域对不对。
将上面例子中 函数b 的定义变成箭头函数。
var name = 'I am window'
var a1 = {
name: 'I am Lexical',
// 函数b变成箭头函数
b: () => {
console.log(this.name)
}
}
var c = function () {
var a2 = {
name: 'I am Dynamic'
}
a2.b = a1.b
a2.b()
}
c() // I am window
你会发现结果并不是我们希望看到的 'I am Lexical'，而是 'I am window'。
这是因为每个普通函数(非箭头函数)会在其执行的时候，通过执行时候的上下文生成一个属于自己的 this。
而箭头函数虽然会在声明的时候确定它的 this ，但是却不会生成一个新的this，而是借用当前上下文所指向的 this 来作为自身的 this。
从上一个例子和接下来的例子，都可以看出来。
var name = 'I am window'
var a1 = {
name: 'I am Lexical',
bCreator: function () {
return () => {
// 该 this 为 bCreator 所产生的 this
console.log(this.name)
}
}
}
// 在这里 函数bCreator 执行的时候生成了一个 this 指向 a1
// 函数b 借用了由 bCreator函数生成的 this
a1.b = a1.bCreator()
var c = function () {
var a2 = {
name: 'I am Dynamic'
}
a2.b = a1.b
a2.b() // 函数b 中的 this 一直指向 a1
}
c() // I am Lexical
何时使用 this
由于普通函数下的 this 的表现是如此诡异，在我们使用函数的时候，我们应该尽量确保函数中的 this 不变。
比如尽管我们在 class 的定义中使用了普通函数，但可以通过在 constructor 的时候对普通函数进行 bind 而使其 this 不变。而对于其他情况则应该用箭头函数来保证这种不变性。
class View {
constructor (name) {
this.name = name
this.handler = this.handler.bind(this) // good part
}
handler () {
console.log(this.name)
}
}
最不应该的就是尝试利用普通函数的“动态” this 来“增加”该函数的功能。
如果一个函数需要在不同上下文中表现不同的特点，最好的方法应该是把上下文作为参数显示地传递进去。而不是通过偷偷地改变函数的 this 来做到这一点。同时也尽量避免用 apply，call 等来改变 this。
对于前面的例子，如果需要 函数b 在不同的对象中表现得不一样，最好的方法应该是下面这种方法。
var name = 'I am window'
var a1 = {
name: 'I am Lexical',
// 将上下文作为参数显示地传递进函数
b: function (ctx) {
console.log(ctx.name)
}
}
var c = function () {
var a2 = {
name: 'I am Dynamic'
}
a2.b = a1.b
a2.b(a2) // 在函数执行的时候确定好 ctx
}
c() // I am Dynamic
这种方式清晰明了，而且 ctx 同样是在函数执行的时候确定，不会减弱其灵活性。
总结
总体而言，通过保证函数的 this 的不变性，可以让我们的思想负担变轻，因为我们不需要每次调用一个函数的 this 的时候，都考虑它会不会变的情况。这也让一些很隐晦的 bug 无处藏身。
当你需要改变 this 的时候，你需要的可能不是 this，而是一个普通的参数。
Just keep it simple and make your life easy.
