写了几年前端，我见过太多同事在 this 上翻车，也包括我自己。印象最深的一次，是在做某后台管理系统时，我用 setInterval 刷新列表数据，回调函数里想调用当前组件的某个方法，结果一直报“找不到方法”。查了半天才发现，回调里的 this 早就不是外层那个对象了。那是我第一次认真去啃 this 的绑定规则，啃完之后回头看，其实规则非常清晰，只是很少有人一开始就把它们讲明白。这篇先把 this 的绑定规则彻底说透，属于整个 this 话题的上半部分，重点解决“this 到底指向谁”这个问题。
无论是刚接触 JavaScript 的新手，还是写了几年代码偶尔还会在 this 上卡壳的朋友，这篇都适合你。我会把默认绑定、隐式绑定、显式绑定、new 绑定这四种规则完整过一遍，再讲清楚箭头函数这个特例，最后给你一套可以直接套用的判断流程。所有例子我都尽量写得可以直接复制运行，建议你边看边在控制台里敲一遍，比光读印象深得多。
1. this 到底是什么：一个比想象中更“随意”的变量
1.1 先破除一个误解：this 不是“当前对象”
很多语言里都有 this 或 self 的概念，通常指“当前实例对象”。这个直觉搬到 JavaScript 里，坑了一大批人。JavaScript 的 this 并不指向“定义它的对象”，也不指向“当前所在的对象”，它完全由函数被调用那一刻的调用方式决定。
为了让你直观感受这个区别，看一段对比代码：
const outerValue = 'OutsideValue'; function readLexical() { return outerValue; // 词法作用域：函数定义在哪，就能访问哪的变量 } function readThis() { return this.currentValue; // this 是谁，取决于函数怎么被调用 }readLexical 读取的是词法作用域里的变量，这种绑定在函数定义时就已经确定了，跟运行环境无关。而 readThis 里的 this 是什么，在没有执行之前谁都没法确定。
我习惯用一个类比来解释：词法作用域像你在公司有固定工位，工位不会因为你今天去哪个会议室开会就搬走；this 更像“你现在代表谁在说话”，同样一番话，代表 A 公司说和代表 B 公司说，立场和结果完全不同。
提示：判断 this 指向，永远盯着“调用现场”，而不是“定义现场”。
1.2 调用位置才是关键
搞清 this 的第一步，是找到函数的调用位置（call-site）。所谓调用位置，就是代码里“真正执行函数调用”的那一行，不是函数定义的那一行。
看这个例子：
const personA = { name: 'PersonA', getName: function () { console.log(this.name); } }; const extracted = personA.getName; extracted(); // 输出什么？很多人会本能地认为“getName 定义在 personA 里，this 肯定指向 personA”。但结果是：非严格模式下输出全局 name（如果存在的话），严格模式下直接报错。原因很简单，提取出来的 extracted 是 personA.getName 这个函数引用本身，调用时是裸调用extracted()，没有经过任何对象的点语法，所以走的是默认绑定规则，this 跟 personA 一点关系都没有。
这个例子特别重要，它解释了为什么回调函数里的 this 总是“莫名其妙”丢。你以为是“这个方法是从 personA 身上拿下来的”，实际上“它被调用的方式，决定了它已经没有宿主对象了”。想通这一点，后面所有绑定规则都会顺很多。
2. 四种绑定规则：调用方式决定 this 走向
JavaScript 的 this 绑定，绝大部分时候都逃不出四种规则：默认绑定、隐式绑定、显式绑定、new 绑定。下面逐个拆开细讲。
2.1 默认绑定：裸调用的兜底
默认绑定是最简单也最容易被忽略的一种规则。当一个函数没有任何修饰、没有被任何对象持有、也没有被 new，就是赤裸裸地在某个地方调用时，this 走的就是默认绑定。
function directCall() { console.log('当前 this：', this); } directCall();这段代码的运行结果取决于环境和模式：
- 非严格模式下，浏览器里 this 是全局对象 Window；Node 环境里是 global 或 globalThis。
- 严格模式下，this 是 undefined。
严格模式的写法：
'use strict'; function strictCall() { console.log(this); } strictCall(); // undefined有没有想过，为什么严格模式要把默认绑定改成 undefined？因为非严格模式下，函数内部不小心用到了 this，会静默地拿到一个全局对象，问题很难暴露。改成 undefined 之后，一旦你误用 this，马上就会报错，程序员能第一时间发现自己的调用姿势有问题。
默认绑定经常在哪些场景出现？最常见的就是把函数作为回调传递，比如 setTimeout、事件监听、数组的遍历方法。这些场景里，回调函数往往是被“系统”调用的，不是被你的对象调用的，所以 this 自然掉进默认绑定，指向全局对象或 undefined。
2.2 隐式绑定：点语法调用的“谁调用指向谁”
隐式绑定是平时写代码最常遇到的情况。形式很简单：通过对象的点语法去调用函数，this 就指向点左侧的那个对象。
const personB = { name: 'PersonB', say() { console.log(this.name); } }; personB.say(); // PersonB这里 personB.say() 的调用方式，让函数内部的 this 指向了 personB，符合直觉——“谁调用，this 指向谁”。
如果对象属性链比较长，比如 a.b.c.method()，this 指向的并不是 a，而是点调用链上“最后一层”的对象：
const container = { inner: { name: 'InnerObj', get: function () { return this.name; } } }; container.inner.get(); // InnerObj调用链是 container.inner.get()，虽然前面经过了 container，但真正持有这个函数的是 inner，所以 this 指向 inner。
隐式绑定最大的坑，是“隐式丢失”。回顾开头提到的 personA 例子：
const personC = { name: 'PersonC', greet() { console.log(this.name); } }; const cb = personC.greet; cb(); // 非严格模式下输出全局 name，严格模式下报错为什么同样是那个函数，用personC.greet()调就指向 personC，赋值给 cb 之后再调就丢了？因为 cb 拿到的只是函数本身，函数在被调用时没有任何对象“陪同”，隐式绑定自然失效，退回到默认绑定。
这个现象在真实开发里几乎每天都在发生。回调函数传参、定时器回调、事件监听器，本质上都是把方法引用从宿主对象上“拆下来”，然后在一个没有上下文的地方裸调用。你可能在 console.log 里看到 this 是 Window，气得骂人，其实规则早就写好了。
要挽救这种丢失，常用的办法是显式绑定，也就是下一节要讲的 call / apply / bind。
2.3 显式绑定：call / apply / bind 直接指定 this
既然调用现场决定了 this，那就干脆“现场指定”。call、apply、bind 这三个方法就是用来直接指定函数内部 this 指向的。
function showInfo(city, year) { console.log(this.name + '，' + city + '，' + year); } const user = { name: 'UserX' }; showInfo.call(user, '北京', 2024); // UserX，北京，2024 showInfo.apply(user, ['北京', 2024]); // UserX，北京，2024call 和 apply 的区别只有一个：传参方式。call 是一个一个传，apply 是把参数放在数组里传。其他行为完全一样，都会立即执行函数，并且临时把 this 指向第一个参数。
那么 bind 呢？它不会立即执行，而是返回一个新函数，新函数内部的 this 被永久绑定到传入的对象上：
const boundShow = showInfo.bind(user, '北京'); boundShow(2024); // UserX，北京，2024bind 的好处是你可以提前绑定 this，然后把新函数交给任何回调、定时器或事件，它被调用时 this 都不会再变。这就是解决隐式丢失最直接的手段。
举个实际场景：前端组件里有个方法需要作为事件处理函数传入，但事件回调内部的 this 通常是触发事件的元素。如果不做 bind，原方法内部的 this 完全错乱；如果提前 bind(this)，就没问题了。
const counter = { count: 0, increment() { this.count++; console.log(this.count); }, setup() { document.addEventListener('click', this.increment.bind(this)); } };这里this.increment.bind(this)的本质是：把 increment 方法“包裹”成一个新的函数，并规定它里面的 this 永远固定为 counter 对象。这是实战里最常用的 this 保护方式。
2.4 new 绑定：构造函数中的特殊 this
使用 new 调用一个函数时，this 指向的既不是全局对象，也不是对象方法链上的宿主，而是一个刚刚创建的新对象。
function Person(name) { this.name = name; this.createdAt = Date.now(); } const p1 = new Person('UserP'); console.log(p1.name); // UserPnew 的过程中到底发生了什么？我把它拆成四步：
- 创建一个全新的空对象。
- 这个空对象的原型会被连接到构造函数的 prototype。
- 构造函数内部的 this 指向这个空对象，并开始执行函数体。
- 如果构造函数显式返回一个对象，那么这个对象会覆盖新对象作为结果；如果返回的是基本类型，则直接忽略，最终返回新对象。
第四步有个很值得注意的细节。我们看一段“奇怪”的代码：
function Weird() { this.value = 'inner'; return { value: 'outer' }; } const w = new Weird(); console.log(w.value); // outer构造函数明明设置了 this.value，但因为手动 return 了一个对象，new 出来的结果就变成了那个手动返回的对象。日常业务代码里几乎没人会这么写，但面试题里很爱考，知道这个规则能帮你避开很多莫名其妙的“陷阱”。
new 绑定和箭头函数还有个重要关系：箭头函数不能作为构造函数使用，也不能通过 new 来调用。这一点放到箭头函数那一节一起讲。
3. 绑定优先级：多条规则同时出现时谁说了算
看到这里你可能想：如果我又用了 new，又调用了 bind，函数里面 this 到底听谁的？JavaScript 对这几种绑定规则是有明确优先级的，不是谁先写谁就赢。
3.1 显式绑定优先于隐式绑定
先看相对好理解的一组：显式绑定和隐式绑定打架的场景。
const objA = { name: 'ObjA', foo() { return this.name; } }; const objB = { name: 'ObjB' }; console.log(objA.foo.call(objB)); // ObjBobjA.foo 通过点语法调用，本来隐式绑定会让 this 指向 objA；但后面接了一个.call(objB)，这是显式绑定，最终结果是 ObjB。说明显式绑定的优先级高于隐式绑定。
3.2 new 绑定优先于显式绑定
更反直觉的是 new 绑定和显式绑定之间的比拼。按直觉说，bind 已经把 this 锁死了，new 还能把它改回来吗？答案是能。
function Obj(name) { this.name = name; } const preset = { name: 'Preset' }; const BoundObj = Obj.bind(preset); const instance = new BoundObj('Instance'); console.log(instance.name); // Instance console.log(preset.name); // Preset这段代码里，Obj 被 bind 到了 preset 对象上，理论上就算被调用，this 也应该指向 preset。但用 new 去调用 BoundObj 时，this 被重新指向新创建的对象，所以 instance.name 是 Instance，preset.name 依然是 Preset，没有被污染。
这个设计不难理解：new 的语义是“创建一个全新实例”，如果允许 bind 强行指定到某个已有对象上，那 new 出来的东西就不是新对象了，整个语言的设计意图就崩了。所以 new 绑定必须压过显式绑定。
3.3 完整的优先级排序
把四种规则整理成一张表，方便记忆：
| 优先级 | 绑定规则 | 触发条件 | this 指向 | 典型写法 |
|---|---|---|---|---|
| 最高 | new 绑定 | 用 new 调用函数 | 新创建的实例对象 | new Foo() |
| 高 | 显式绑定 | 调用 call / apply / bind | 显式传入的对象 | foo.call(obj) |
| 中 | 隐式绑定 | 对象方法通过点语法调用 | 点左侧的宿主对象 | obj.foo() |
| 低 | 默认绑定 | 裸调用函数 | 全局对象或 undefined | foo() |
判断顺序也很简单，从最高到最低逐个问：是不是 new 调用的？是不是 call / apply / bind 指定的？是不是某个对象通过点语法调用的？都不是，那就是默认绑定。
4. 箭头函数：唯一不按规则出牌的特例
前面四种规则覆盖了普通函数的所有情况。但 JavaScript 里还有一种函数，它压根不参与这套动态绑定规则，那就是箭头函数。
4.1 箭头函数没有自己的 this
箭头函数在定义时不会创建自己的 this，它会捕获定义位置所在外层函数或作用域的 this，并且这个“捕获”是词法级的，类似于普通变量查找。
直接理解：箭头函数内部 if 有这个 this，它不是箭头函数自己的，而是往外层作用域一层一层找出来的。
const outerObj = { name: 'Outer', wait: function () { setTimeout(() => { console.log(this.name); }, 100); } }; outerObj.wait(); // Outerwait 方法是普通函数，被 outerObj.wait() 调用时，this 指向 outerObj。wait 内部的箭头函数在定义时捕获了 wait 的 this，也就是 outerObj，所以 setTimeout 里即便回调是裸调用，this 也不会丢。
这就是箭头函数解决“this 丢失”经典问题的核心原理。对比一下，如果把 setTimeout 里的回调换成普通函数：
const outerObj2 = { name: 'Outer2', wait: function () { setTimeout(function () { console.log(this.name); }, 100); } }; outerObj2.wait(); // 非严格模式输出 undefined 或全局 name同样的场景，普通函数进入默认绑定，this 不再指向 outerObj2，只有箭头函数能继承外层 this。所以你在写回调、定时器、事件处理器时，箭头函数默认是一个安全的选择。
4.2 箭头函数直接当对象方法会翻车
箭头函数虽然能救回调，但并不是所有地方都适合它。最典型的误区是想用箭头函数定义对象的方法：
const badObj = { name: 'Bad', show: () => { console.log(this.name); } }; badObj.show(); // 不是 'Bad'为什么？因为 show 是箭头函数，它的 this 不参与隐式绑定，所以点调用的方式在这里完全无效。show 在定义时，外层作用域如果是全局或模块作用域，this 就是全局对象或 undefined，取 this.name 自然得不到 Bad。
这个坑在真实代码里我见得太多了，有些人觉得“箭头函数既然更安全，那所有函数都用箭头函数好了”。其实对象的方法需要动态绑定到当前对象，用普通函数才是正解，箭头函数反而把有用的动态绑定剥夺了。
4.3 箭头函数的使用边界
结合已经讲过的规则，我给箭头函数的使用场景做一个清晰的划分：
适合使用箭头函数：
- 函数式编程里的回调，比如 map、filter、forEach。
- 定时器、事件回调、Promise 链里希望继承外层 this 的地方。
- 不需要动态 this 的纯函数。
不适合使用箭头函数：
- 对象的方法定义。
- 构造函数，箭头函数没有 prototype，也不能 new。
- 原型链上的方法。
- 需要利用 arguments 对象的旧式函数场景（箭头函数没有自己的 arguments）。
注意：bind / call / apply 对箭头函数是无效的。因为箭头函数根本没有自己的 this，你强制传一个对象给它，它还是会往外层找。这既是它的优势，也是它的局限。
5. 判断 this 的实操套路：拿到一段代码怎么快速定位
读别人代码或 debug 时，怎么快速判断 this？我给你一套五步判定法，按顺序问下去，基本不会出错。
5.1 五步判定法
| 步骤 | 先问自己 | 结论 |
|---|---|---|
| 1 | 箭头函数还是普通函数？ | 箭头函数：this 从外层词法作用域找，判断结束 |
| 2 | 是用 new 调用的吗？ | 是：this 指向新创建的对象 |
| 3 | 用了 call / apply / bind 吗？ | 用了：this 指向显式传入的对象 |
| 4 | 是通过对象点语法调用的吗？ | 是：this 指向点左侧的宿主对象 |
| 5 | 以上都不满足？ | 裸调用：严格模式 this 为 undefined，非严格模式为全局对象 |
这五步一定要按顺序执行。第一问要把箭头函数这个特例先排除掉，因为它不参与后面任何动态规则；第二问的 new 优先级最高；第三问的显式绑定次之；第四问的隐式绑定再次；最后才轮到默认绑定。
5.2 实战演练：四道高频代码题
光说不练假把式，我们用三道实际题目走一遍完整判定流程。
题目一：方法引用赋值
var name = 'GlobalName'; const objName = { name: 'ObjName', get: function () { return this.name; } }; const fn = objName.get; console.log(fn());解析：不是箭头函数，没有 new，没有 call/apply/bind，不是点调用，就一个裸调用。走默认绑定。非严格模式下，this 指向全局对象，全局 var name 挂在全局对象上，输出 GlobalName；严格模式下 this 是 undefined，取 name 直接报错。
题目二：方法交换之后
const objA1 = { name: 'A1', show: function () { console.log(this.name); } }; const objB1 = { name: 'B1', show: objA1.show }; objB1.show(); // B1解析：不是箭头函数，没有 new，没有显式绑定。调用是 objB1.show()，点语法，this 指向点左侧的 objB1。函数虽然定义在 objA1 里，但 JavaScript 根本不认识“定义在哪个对象里”这回事，真正认识的是“调用时从哪个对象身上取出来”。输出 B1。
题目三：定时器里的普通函数
var name = 'GlobalName'; const objTimer = { name: 'ObjTimer', run: function () { setTimeout(function () { console.log(this.name); }, 100); } }; objTimer.run();解析：外层 objTimer.run() 把 run 的 this 指到了 objTimer，但 setTimeout 里的回调是普通函数，它被定时器机制裸调用，不继承 run 的 this。所以按默认绑定处理。非严格模式输出 GlobalName（浏览器环境），严格模式相同位置则报错。
题目四：定时器里的箭头函数
const objTimer2 = { name: 'ObjTimer2', run: function () { setTimeout(() => { console.log(this.name); }, 100); } }; objTimer2.run();解析：第一步先看是不是箭头函数——是。那么 this 从定义处的外层作用域找。箭头函数定义在 run 内部，run 是普通函数，run 被 objTimer2.run() 调用，所以 run 的 this 指向 objTimer2。箭头函数捕获了这个 this，输出 ObjTimer2。
四道题走完你会发现，判断流程只要严格执行，几乎是条件反射，根本不需要死记硬背。
5.3 日常编码里防 this 翻车的三个习惯
判断 this 是一回事，写完代码不翻车又是另一回事。分享三个我实际工作里一直在用的习惯。
第一个习惯：凡是回调函数，先问一句“这里面的 this 我到底想不想保留外层”。想保留就用箭头函数，不想保留再考虑普通函数。不要顺手写完就不管。
第二个习惯：在函数式调用链里需要保底时，直接用 bind 提前绑定。比如上面 counter 那个例子，事件监听、订阅发布这些地方，bind 是最稳的保险。
第三个习惯：有时为了可读性，我会在对象方法内部先存一个const self = this，旧的写法会存var that = this，原理都一样：用一个普通变量把当前 this 引用固定下来，然后回调里全部用 self。这个方法在普通函数回调场景里非常直接，不过有了箭头函数之后，我大多数情况直接用箭头函数了。
最后说两句
我现在写代码养成了一个习惯：写完任何回调，先停下来想一秒，这个函数被调用时，宿主是谁，调用方式是什么。this 这件事并不难，难的是每次都能保持这个意识。只要你在写代码时带着“调用现场决定 this”这个认知，再配合前面那五步判定法，绝大多数 this 相关的坑都可以绕开。
这篇聊完了 this 的绑定规则，下一部分我会继续把 this 绑定丢失的各种修复模式、bind 的底层实现原理，以及面试中常见的 this 综合题串起来讲。如果你在自己项目里也遇到过特别诡异的 this 问题，也欢迎在评论区一起讨论，说不定下一个坑就在某行定时器回调里。
