深入理解JavaScript中this的运行时绑定机制

this 的绑定规则并非在代码编写阶段确定，而是在函数实际运行时动态决定的。这一机制完全取决于函数被调用的具体上下文条件。this 的绑定结果与函数在源码中的声明位置无关，而是严格关联于函数被调用的方式。this 既不代表函数对象本身的引用，也不指向函数定义时的词法作用域。this 实际上是在函数执行期间建立的一种动态绑定，其具体指向完全由调用点（Call-site）决定。

每次函数调用都会创建一个执行环境的活动记录（Execution Context Record）。该记录记录了函数的调用来源（即调用栈中的位置）、调用方式以及传递的参数等关键信息。该记录中包含的一个关键属性，就是在函数执行过程中将被使用的 this 引用。

为什么需要 this？

对于经验丰富的 JavaScript 开发者而言，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

如果上述代码的工作机制让你感到困惑，无需担心！我们将在后续部分详细解析。此处暂且搁置“如何工作”的问题，以便更清晰地探讨“为何有用”。

这段代码片段允许 identify() 和 speak() 函数复用多个环境对象（me 和 you），而无需为每个对象单独定义函数版本。

与使用 this 相反地，你可以明确地将环境对象传递给 identify() 和 speak()。

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

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

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

然而，this 机制提供了一种更优雅的方式来隐式“传递”对象引用，从而实现了更简洁的 API 设计并提高了代码复用性。

随着使用模式的复杂化，你会越来越清晰地看到：将执行环境作为显式参数传递，通常比依赖 this 动态解析执行环境更为混乱。在后续探讨对象和原型时，你将看到一组能自动引用恰当执行环境对象的函数是多么高效。

this的常见困惑

在深入讲解 this 的实际工作原理之前，我们必须先澄清一些常见的误解——明确它“不是”如何工作的。

开发者往往对“this”这一名称进行过于字面化的理解，从而产生两种常见的错误推测。

第一种常见倾向是认为 this 指向函数自身。从语法角度看，这似乎是一个合理的推测。

为什么需要在函数内部引用自身？最常见的场景包括递归调用（函数内部调用自身），或者在首次调用后解除绑定的事件处理器。

初学者常认为，将函数视为对象（JavaScript 中所有函数均为对象），可以在方法调用间通过属性存储状态。这确实可行且有一定用途，但本书后续章节将阐述许多其他模式，它们比在函数对象中存储状态更为优越。

this与词法作用域

对 this 含义的另一种常见误解是，它 somehow 指向了函数的作用域。这是一个微妙的问题，因为在某种意义上它包含部分正确性，而在另一种意义上则是严重的误导。

明确地说，this 不会以任何方式指向函数的词法作用域。虽然作用域在内部实现上类似于一个包含所有可用标识符的对象，但 JavaScript 代码无法直接访问这个“作用域对象”，它是引擎的内部实现细节。

考虑以下代码，它（失败地）试图通过 this 隐式引用函数的词法作用域：

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

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

foo(); //undefined

这段代码中存在不止一个错误。虽然它看起来像是故意编写的混乱代码，但它实际上提取自公共社区帮助论坛中交换的真实代码。这充分说明了将 this 误解为作用域引用的误导性之强。

首先，代码试图通过 this.bar() 来引用 bar() 函数。这在某种程度上可以说是“碰巧”工作，我们稍后解释原因。调用 bar() 最自然的方式是省略开头的 this.，仅使用标识符进行词法引用。

然而，编写这段代码的开发者试图利用 this 在 foo() 和 bar() 的词法作用域之间建立一座“桥”，使得 bar() 能够访问 foo() 内部作用域中的变量 a。这样的桥是不存在的。你无法使用 this 来在词法作用域中查找变量，这是不可能的。

每当你感觉自己试图使用 this 进行词法作用域查询时，请提醒自己：这里没有桥。

this的调用点（Call-site）

为了理解 this 的绑定规则，我们必须理解调用点：即函数在代码中被调用的位置（而非声明位置）。我们必须考察调用点才能回答：这个 this 指向什么？

通常，寻找调用点即“找到函数被调用的位置”，但在某些特定的编码模式下，真正的调用点可能并不明显。

考虑调用栈（call-stack）——即导致当前执行位置而被调用的所有方法的堆栈——至关重要。我们关心的调用点位于当前执行函数之前的那个调用。

我们来展示一下调用栈和调用点的关系：

function baz() {
    // 调用栈是: `baz`
    // 我们的调用点是 global scope（全局作用域）

    console.log( "baz" );
    bar(); // <-- `bar` 的调用点
}

function bar() {
    // 调用栈是: `baz` -> `bar`
    // 我们的调用点位于 `baz`

    console.log( "bar" );
    foo(); // <-- `foo` 的 call-site
}

function foo() {
    // 调用栈是: `baz` -> `bar` -> `foo`
    // 我们的调用点位于 `bar`

    console.log( "foo" );
}

baz(); // <-- `baz` 的调用点

在分析代码以寻找（从调用栈中）真正的调用点时要格外小心，因为它是影响 this 绑定的唯一因素。

注意：你可以通过按顺序观察函数调用链在脑海中构建调用栈视图，如上文代码注释所示。但这既痛苦又容易出错。另一种观察调用栈的方式是使用浏览器的调试工具。大多数现代桌面浏览器内置开发者工具，其中包含 JS 调试器。在上面的代码段中，你可以为 foo() 函数的第一行设置断点，或在该行插入一个 debugger 语句。运行网页时，调试器将在该位置暂停，并展示到达该行之前所有被调用过的函数列表，这就是你的调用栈。因此，如果你想调查 this 绑定，可以使用开发者工具获取调用栈，然后从上向下找到第二个记录，那就是你真正的调用点。

到此这篇关于JavaScript中this机制是如何真正工作的的文章就介绍到这了,更多相关JavaScript中this关键字内容请搜索本站以前的文章或继续浏览下面的相关文章希望大家以后多多支持本站！