深入理解 JavaScript 的 this 指向：四种绑定规则的优先级与陷阱

很多 JavaScript 开发者都经历过这样的困惑：明明是在同一个对象里写的函数，调用的时候 this 却指向了别的地方。尤其是刚接触 React 类组件或者处理 DOM 事件时，经常会因为 this 丢失而抓狂。网上关于 this 的文章很多，但大多只列规则不解释原因，看完还是不知道怎么写。这篇文章想从绑定规则的角度，把 this 的指向逻辑讲透，顺便聊聊为什么它会产生那些看似反直觉的行为。

先说一个容易被忽略的事实：JavaScript 的 this 并不是在定义函数时确定的，而是在函数被调用时由调用方式决定的。这意味着同一函数，用不同方式调用，this 指向可能完全不同。理解这一点，后面所有规则都能顺理成章地推导出来。

四种绑定规则：先记住它们，再谈优先级

关于 this 的指向，业界通常归纳为四种绑定规则：默认绑定、隐式绑定、显式绑定和 new 绑定。它们不是并列关系，而是存在明确的优先级。但多数初学者只记住了“谁调用就指向谁”这条简化的隐式绑定逻辑，结果遇到 setTimeout、解构赋值、回调函数时就直接翻车。

默认绑定：最基础也最容易误判

当函数独立调用，没有任何调用上下文时，就是默认绑定。在非严格模式下，this 指向全局对象（浏览器里是 window）；在严格模式下，this 指向 undefined。很多人会在这里犯一个错误：以为函数写在对象里就一定会绑定这个对象，其实不然，关键还是看调用方式。

function sayHello() {
  console.log(this.name);
}

var name = 'Global';

var obj = {
  name: 'Object',
  sayHello: sayHello
};

// 独立调用，this 指向全局（非严格模式）
var fn = obj.sayHello;
fn(); // "Global"

这里的场景在工程里非常常见：从对象中取出方法再作为回调传递时，方法的“调用者”变成了全局环境，于是 this 就回到了默认绑定。这其实就是所谓的 this 丢失问题。

隐式绑定：对象方法调用的甜与苦

当函数以 obj.method() 的形式调用时，this 自然指向该对象，这叫隐式绑定。看起来轻松，但它有一个致命弱点：方法一旦被赋值给变量或者作为参数传入异步函数，隐式绑定立刻失效。下面这段代码几乎每个前端项目都踩过坑：

const user = {
  name: 'Alice',
  greet: function() {
    console.log(`Hello, ${this.name}`);
  }
};

setTimeout(user.greet, 1000);
// 输出 Hello, undefined（非严格模式）

为什么会这样？因为 setTimeout 接收的是 user.greet 这个函数引用，等定时器触发时，它是在全局环境里被调用的，与 user 对象再无关系。正确的做法是用箭头函数包裹，或者提前 bind 好：

setTimeout(() => user.greet(), 1000);
// 或者
setTimeout(user.greet.bind(user), 1000);

显式绑定：call、apply、bind 的把控力

所谓显式绑定，就是通过 call、apply、bind 方法来手动指定 this。这三个方法让开发者在函数调用时能精确控制 this 的指向，代价是代码变得啰嗦，并且需要你明确知道此刻该让 this 指向谁。

function introduce(city, age) {
  console.log(`${this.name} from ${city}, ${age} years old`);
}

const person = { name: 'Bob' };
introduce.call(person, 'Shanghai', 30);
introduce.apply(person, ['Shanghai', 30]);
const bound = introduce.bind(person, 'Shanghai');
bound(30);

call 和 apply 的区别只是参数传递方式，一个散列，一个数组。bind 则返回一个新函数，新函数的 this 被永久绑定为传入的对象。这里需要提醒一个注意点：bind 之后再次执行 bind，不会改变 this 指向，因为它内部的实现是绑定一次后就不再覆盖。

new 绑定：构造器场景下的特殊待遇

用 new 关键字调用函数时，JavaScript 会创建一个新对象，将这个新对象的 prototype 链接到函数的 prototype，同时将 this 绑定到新对象上。如果构造函数显式返回了一个对象，那么 new 出来的结果会覆盖这个绑定，否则 this 指向的新对象就是最终返回值。

function Person(name) {
  this.name = name;
  this.greet = function() {
    console.log(this.name);
  };
}

const p = new Person('Cathy');
p.greet(); // Cathy

new 绑定的优先级非常高，即使构造函数内部使用了 call 或 apply，也会被 new 覆盖。这是 JavaScript 设计中的一个重要细节，理解它才能正确判断那些看起来像是显式绑定却依然不生效的代码。

优先级总结：谁说了算

四种绑定规则的优先级从低到高是：默认绑定 → 隐式绑定 → 显式绑定 → new 绑定。箭头函数不参与这些规则，它的 this 是由词法作用域决定的，后面单独说。这里用一个表格把规则梳理出来：

绑定规则	触发方式	this 指向	优先级	典型陷阱
默认绑定	独立函数调用	全局对象或 undefined	最低	回调函数中的 this 丢失
隐式绑定	obj.method()	方法所属对象	较低	方法被赋值给变量后失效
显式绑定	call / apply / bind	手动传入的对象	更高	bind 后无法再次覆盖
new 绑定	new 构造函数	新创建的对象	最高	构造函数返回对象导致绑定失效

这张表解决了一个核心问题：当多种规则同时出现时，如何判断 this。比如 obj.method.call(other)，隐式绑定和显式绑定冲突，显式绑定胜出。再比如 new obj.method()，new 的优先级最高，所以 this 指向新对象，而不是 obj。理解这个顺序，很多看似诡异的 this 谜题都能迎刃而解。

箭头函数：不遵守规则的异类

箭头函数的设计初衷就是避免 this 带来的心智负担。它没有自己的 this，所以它内部的 this 实际上继承自外层作用域。这个特性使得箭头函数非常适合在回调中使用，因为它能稳定地保留定义时的 this，而不是被调用方式劫持。

const timer = {
  name: 'Timer',
  wait: function() {
    setTimeout(() => {
      console.log(this.name);
    }, 100);
  }
};

timer.wait(); // Timer

注意这里 wait 是普通函数，this 在调用时绑定到 timer，然后箭头函数定义在 wait 内部，它的 this 就沿用了 wait 的 this。如果 wait 也写成箭头函数，那么这个对象内部就失去了 this 的来源，行为就会完全不同。

箭头函数的优势很明显，但它不是银弹。尤其在需要动态指定 this 的场景（比如事件监听里要根据事件源获取数据），箭头函数反而会把 this 固定在不合适的上下文上。另外，箭头函数不能用作构造函数，也不能在内部使用 arguments，这些限制在工程中需要提前想好。

真实项目中最常见的三种 this 陷阱

光知道规则还不够，得知道在真实代码里这些规则是怎么坑人的。我总结了三个大多数团队都至少遇到过的问题。

1. 拆分调用导致的 this 静默丢失

ES6 解构赋值让代码更简洁，但也容易让 this 悄悄跑掉。比如从 store 对象里解构出 action 方法，再直接传入组件，方法里的 this 就不再指向 store 了。

const store = {
  count: 0,
  increment: function() {
    this.count++;
  }
};

const { increment } = store;
increment(); // 报错或操作全局 / undefined

解决方案是保持调用链完整，或者显式绑定：const increment = store.increment.bind(store)。但如果 store 里的方法本身依赖 this，解构后还想用，只能 bind 或者用箭头函数重新封装。

2. 嵌套函数中的 this 漂移

在传统函数中，如果在一个对象方法内部再定义一个普通函数，那么内部函数的 this 又回到了默认绑定，即使是方法调用内部的写法也救不回来。

const obj = {
  data: [1, 2, 3],
  process: function() {
    return this.data.map(function(item) {
      return item * this.factor; // this 是 undefined
    });
  },
  factor: 10
};

这里的 map 回调里的 this 指向全局（或 undefined），而不是 obj。老式解决方案是把外层的 this 保存到变量中（let self = this），或者给 map 传入第二个参数作为 thisArg。现代项目里更推荐直接用箭头函数，因为箭头函数会继承 process 的 this。

3. 事件监听器中的 this 与 target 混淆

在 jQuery 时代，很多人用 $(this) 获取触发事件的元素。原生 addEventListener 中，this 会指向绑定事件的元素，这是一个隐式绑定？严格说这是 DOM API 的特殊处理。但如果你在 React 类组件中监听事件，React 使用事件委托，this 并不自动指向组件实例，需要手动绑定。这个差异是很多新手困惑的来源。

button.addEventListener('click', handler);
// handler 中的 this 指向 button

// 但是同样的 handler 在 React 类组件里如果是作为回调传入，
// 不 bind 的话 this 就是 undefined

所以别再用“this 就是当前元素”这种粗浅说法了，它只在原生 DOM 监听器里成立。框架层面的事件系统往往重构了调用链，this 会发生改变。

为什么 this 的设计这么反直觉？

很多人抱怨 this 设计得不好，但了解完后你可能逐渐理解它的价值。JavaScript 的函数既可以是传统意义上的“方法”，也可以是独立的“过程”。this 实际上提供了一种动态的上下文机制，让函数可以在不同对象之间复用。这种灵活性的确导致了误用的可能，但也让 JavaScript 在高阶函数、状态管理等领域表现得非常强大。

真正需要的不是抱怨设计，而是理解规则后形成一套稳定的应对策略。在我看来，最实用的策略是：在团队代码里强制约定，箭头函数用于所有需要外部 this 的回调，普通函数只用于对象方法或构造函数。这样约定之后，大多数 this 陷阱都能在编码阶段被规避。