为什么JavaScript中this指向会变化？动态绑定特性详解

作者：函数茶馆

时间：2026-10-30

深入解析JavaScript中this动态绑定的核心机制，对比词法作用域与运行时上下文，系统剖析默认绑定、隐式绑定、显式绑定与new绑定的判定优先级与常见丢失场景。

文章目录

很多初学者接触 JavaScript 时，最容易困惑的现象之一就是：同一个对象里的方法，直接调用能正常取到属性，一旦赋值给一个外部变量或传进 setTimeout，this 突然就变成了 undefined 或全局对象 window。造成这种现象的根源在于：JavaScript 的普通函数中，this 的指向并不是在函数定义时静态决定的，而是在函数被实际调用时动态绑定的。本文将通过底层内存模型、四条核心绑定规则以及常见陷阱场景，彻底讲透 this 动态绑定的底层逻辑与判定机制。

一、核心根源：函数独立存储与执行上下文解耦

要理解 this 为什么会变，首先需要了解 JavaScript 引擎在内存中如何存放对象和函数。不同于以类为严格边界的传统面向对象语言，JavaScript 的函数是“头等公民”（First-class Object），本身就是独立保存在堆内存中的对象实体。

当我们在一个对象字面量中定义方法时，例如 const user = { name: "Alice", show() { ... } }，对象 user 的 show 属性并不是直接把函数的代码块包裹在自己内部，而是仅仅保存了一个指向堆内存中该函数对象的地址指针。因此，函数和声明它的对象在物理存储上是解耦的。

为什么JavaScript中this指向会变化？动态绑定特性详解 — 图 1：JavaScript 中函数对象与宿主对象的解耦关系及调用点差异

当执行引擎进入函数体执行代码时，会为其创建**执行上下文（Execution Context）**。执行上下文中包含变量环境、词法环境以及 this 绑定。this 本质上是引擎在创建执行上下文时塞入的一个特殊参数，它的值取决于**当前函数是如何被调用的（Call-site）**，而不是它写在谁的字面量里。

二、判定 this 指向的四项推导步骤

在面对一段包含普通函数调用的代码时，读者可以通过下面四个循序渐进的步骤准确推导出 this 的指向：

1. 默认绑定（Default Binding）

当函数独立调用（即不带任何对象修饰前缀，如 fn()）时，触发默认绑定规则：

非严格模式：this 自动指向全局对象（浏览器环境下为 window，Node.js 环境下为 global）。
严格模式（"use strict"）：全局对象不会被默认填充，this 保持为 undefined。

function showInfo() {
  console.log(this);
}

showInfo(); // 浏览器非严格模式下输出: Window

function showInfoStrict() {
  "use strict";
  console.log(this);
}

showInfoStrict(); // 输出: undefined

2. 隐式绑定（Implicit Binding）

当函数作为某个对象的属性被调用时（即形如 obj.fn()），调用的上下文对象会被隐式绑定到函数的 this 上。如果有连续的点号链式调用，如 a.b.c.fn()，this 只指向离函数调用最近的最后一层对象（即 c）。

const department = {
  name: "研发部",
  manager: {
    name: "李四",
    getName() {
      return this.name;
    }
  }
};

// 只有紧挨调用位置的 manager 成为 this
console.log(department.manager.getName()); // 输出: "李四"

3. 显式绑定（Explicit Binding）与硬绑定

通过 JavaScript 内置的原型方法 call()、apply() 或 bind()，我们可以显式强行指定函数执行时的 this：

fn.call(target, arg1, arg2)：以 target 为 this 立即执行函数，参数逐个传入。
fn.apply(target, [args])：以 target 为 this 立即执行函数，参数以数组形式传入。
fn.bind(target)：返回一个永久锁定 this 为 target 的新函数包装（硬绑定），无论后续如何调用，其 this 均不可被隐式或二次 bind 篡改。

4. new 绑定

使用 new 关键字调用函数时，引擎在底层完成了以下四个关键步骤：

在内存中开辟空间，创建一个崭新的空普通对象。
将这个新对象的内部原型 [[Prototype]] 连接到构造函数的 prototype 对象。
将函数的 this 绑定到刚刚创建的新对象上，并执行构造函数体。
如果构造函数没有显式返回非原始类型对象，则默认返回刚刚创建的这个新对象。

三、常见陷阱：隐式绑定丢失与解决方案

在日常业务开发中，绝大多数 this 相关的 Bug 都是由“隐式绑定丢失”引起的。开发者误以为函数写在对象中就永远绑在该对象上，而忽视了调用的实际形式。

注意：ECMAScript 规范中的 Reference Record 视角

从底层规范来看，当执行 user.show() 时，user.show 计算出的不是单纯的函数指针，而是一个 Reference Record（引用记录），其内部由 base（基对象 user）、referencedName（属性名 "show"）和 strict 标志构成。括号 () 操作符调用时，引擎会检查该引用记录并将 base 提取为 this。而一旦执行 const fn = user.show，赋值操作触发了 GetValue 解引用，fn 仅保留了裸函数指针，失去了原有的 base 信息，因而再次调用时只能触发默认绑定。

四、规则优先级与箭头函数机制

当多个规则同时碰撞时，引擎会按照严格的优先级顺序裁决：

优先级等级	绑定规则	典型调用语法	this 最终指向	是否会被其他规则覆盖
0（词法固定）	箭头函数	`const f = () => this.x;`	外层包含环境的 this	绝对不可覆盖（call/apply/bind/new 均无效）
1（最高运行时）	new 构造绑定	`new Foo()`	新创建的实例对象	优先级高于 bind 包装函数
2（显式优先）	显式 / 硬绑定	`fn.call(ctx)` / `fn.bind(ctx)()`	指定的上下文对象	高于隐式绑定，无法被 call 再次二次修改
3（中等）	隐式绑定	`obj.method()`	前缀宿主对象	容易在传递、解构或赋值后丢失
4（保底）	默认绑定	`standaloneFn()`	严格模式 undefined / 非严格 window	作为无任何修饰时的兜底行为

需要特别区分的是 ES6 箭头函数。箭头函数完全放弃了普通函数的动态绑定模型，它没有独立的 [[Construct]] 方法，没有自己的 this、arguments、super 或 new.target。它在定义阶段像普通局部变量一样，直接沿外层的**词法作用域链（Lexical Scope）**向上查找并捕获外层执行上下文中的 this。因此，任何对箭头函数使用 call 或 bind 传入新 this 的操作都会被静默忽略。

五、总结

回顾开头的核心问题：为什么 JavaScript 中 this 指向会变化？

本质原因在于普通函数没有固化的宿主归属，它在内存中是独立的对象。执行引擎必须等到每一次函数被实际调用的那一瞬间，观察其调用点（Call-site）的调用形式，才能决定本次执行上下文中的 this 到底指派给谁。要想写出健壮、可控的代码，日常开发应牢记以下三条准则：

看调用点而非声明点：普通函数的 this 永远由圆括号 () 左侧的修饰形式决定，不要被函数写在哪个对象字面量内所误导。
防御隐式丢失：凡是将对象方法作为参数传入 setTimeout、事件监听器或 Promise 链式调用时，优先使用箭头函数或 bind 提前固化目标上下文。
明确词法与动态的选型边界：在需要继承外层环境上下文（如异步回调、React 组件内部方法）时选用箭头函数；在需要根据不同调用者动态切换行为（如对象原型链方法、类中的多态方法）时使用普通函数。