十年前我刚学 JavaScript 的时候，就在面试题里遇见过“说说 call、apply、bind 的区别”。当时我背得滚瓜烂熟：call 传参数列表、apply 传数组、bind 返回新函数。可真到项目里一用，还是会被 this 整得云里雾里。后来带过不少人，发现这个问题几乎是前端面试的必考题，也是区分“背答案”和“真理解”的试金石。
这篇不是给你再抄一遍标准答案，而是想把这个知识点从头到尾拆透：先说清楚这三个方法到底在解决什么底层问题，再讲三者的本质差异，接着用边界情况、手写实现来检验理解是否到位，最后结合真实项目聊一聊怎么选型。不管是准备面试、阅读源码，还是日常开发里遇到 this 丢失，这篇都应该能帮上忙。
1. 从 this 之谜说起：这三个方法究竟在解决什么问题
1.1 this 是调用时决定的，不是定义时决定的
很多初学者对 call、apply、bind 的困惑，根源在于对 this 的理解停留在“指这个对象”这样模糊的层面。要真正搞清楚这三个方法的作用，必须先接受 JavaScript 里一个非常重要的设计：函数的 this 是在调用时被决定的，而不是在定义时被决定的。
这是什么意思？看一个最简单的例子：
const user = { name: '小明', sayHi() { console.log(`大家好，我是${this.name}`); } }; user.sayHi(); // 大家好，我是小明 const fn = user.sayHi; fn(); // 大家好，我是undefined同样一个函数，在user.sayHi()这种形式下调用时，因为它是作为user这个对象的方法被调用的，JavaScript 引擎会把 this 指向user。但当我把方法解构赋值给变量fn，然后用fn()这种方式调用时，这已经变成了一个普通的函数调用，此时 this 不再指向user，而是指向全局对象（浏览器里是 window）——在严格模式下甚至是 undefined。
我在带新人时经常会用一个生活化的类比：this 就像“现场指挥”。函数定义的时候，谁也不知道指挥是谁；只有在函数真正开始执行的那一刻，JavaScript 引擎才根据“你是怎么调用它的”来确定 this。是obj.method()这样的形式调用，this 就是 obj；是裸调用method()，this 就可能是全局对象或者 undefined。这就是动态 this 的本质。
1.2 三个方法解决的就是“this 丢失”的问题
理解了 this 是调用时决定的，自然就能推导出一个结论：在某些情况下，this会“丢”。最常见的场景就是事件回调、定时器、异步任务、以及把方法解构出来单独使用。比如：
const user = { name: '小明', sayHi() { console.log(`大家好，我是${this.name}`); } }; setTimeout(user.sayHi, 1000); // 1秒后输出：大家好，我是undefinedsetTimeout会在 1 秒后把user.sayHi这个函数作为回调调用，此时它是一个普通的函数调用，this 丢了。这就是 JS 开发中非常经典的“回调丢失 this”问题。
call、apply、bind这三个方法，核心作用就是在函数调用时显式地指定 this 的指向，所以它们统称为“显式绑定”。有了它们，我们可以强行告诉引擎：“这个函数执行的时候，this 就给我指向这个对象，别再给我去猜了。”
1.3 动态 this 不是 bug，而是特性
有朋友可能会问：为什么 JavaScript 不采用静态 this？这样不就永远不会丢了吗？这其实和 JavaScript 的设计哲学有关。动态 this 给了函数极大的复用能力——同一个函数，可以给不同的对象“借用”，这是原型链继承、混入（mixin）模式、函数式编程里很常见的手段。正因为 this 是灵活的，才需要 call、apply、bind 这样的工具去控制它。
这个背景理解到位之后，再看三个方法的具体区别，就比较顺了：它们本质上都是“改变 this 指向”的工具，只是在使用方式、执行时机上有差异。接下来我们就逐个击破。
2. call、apply、bind 三兄弟的分工与本质区别
2.1 一张表看清楚三者的核心差异
先上一个对比表，把核心差异串起来，后面再逐个展开：
| 对比维度 | call | apply | bind |
|---|---|---|---|
| 执行时机 | 立即执行 | 立即执行 | 返回新函数，调用时才执行 |
| 传参方式 | 逐个列出 | 数组（或类数组）整体传入 | 逐个列出，可分两次传 |
| 返回值 | 原函数的执行结果 | 原函数的执行结果 | 绑定了 this 的新函数 |
| 是否修改原函数 | 不改 | 不改 | 不改，但新函数 this 被永久绑定 |
| 经典场景 | 借用方法、临时换 this | 参数不确定、数组传参 | 事件绑定、柯里化、预置参数 |
从表格能看出来，call 和 apply 是一对孪生兄弟，它们唯一的区别就是传参方式；而 bind 完全不是一个路数，它不立即执行函数，而是返回一个新函数，把 this 和参数“存起来”，留到以后调用。
来一段直观的代码感受三者差异：
const userA = { name: 'Alice' }; const userB = { name: 'Bob' }; function greet(age, city) { console.log(`我是${this.name}，今年${age}岁，来自${city}`); } greet.call(userA, 25, '北京'); // 我是Alice，今年25岁，来自北京 greet.apply(userB, [30, '上海']); // 我是Bob，今年30岁，来自上海 const greetBob = greet.bind(userB, 28); greetBob('深圳'); // 我是Bob，今年28岁，来自深圳注意最后一行的用法：bind的时候传入了userB和28，返回了一个新函数greetBob，等到真正调用时再传剩余参数'深圳'。这就是它和 call/apply 最大的不同——不立即执行，先绑定留待后用。
2.2 call 的典型用法：借用方法与临时换主
call 最典型的场景是“借用方法”。JavaScript 里，很多方法不是某个类型私有的，而是可以“借”给其他对象用的。
最经典的例子是用数组的方法处理伪数组（比如函数的arguments）：
function list() { // 传统写法：借用数组的 slice 方法把 arguments 变成真正的数组 const args = Array.prototype.slice.call(arguments); return args.join('-'); } console.log(list('a', 'b', 'c')); // a-b-c在我刚入行那会儿，Array.prototype.slice.call(arguments)几乎算是必背代码。现在有了Array.from和展开运算符，这种写法不常见了，但在某些说老不老、说新不新的环境里，你依然能在源码中遇到它。它的核心逻辑就是：arguments不是数组，没有slice方法，但我可以把数组的slice方法借过来，通过 call 把 this 指向arguments，让它去“切割”这个伪数组，再返回一个真正的数组。
call 的第二个典型场景是“临时换主”。比如你在两个对象之间复用某个逻辑：
const logger = { prefix: '【日志】', log(message) { console.log(this.prefix + message); } }; const errorLogger = { prefix: '【错误】' }; logger.log('系统启动成功'); // 【日志】系统启动成功 logger.log.call(errorLogger, '磁盘空间不足'); // 【错误】磁盘空间不足这里我们复用了logger.log的逻辑，但临时把 this 换成了errorLogger，不用再写一遍同结构的函数。在继承和混入模式里，Parent.method.call(this, ...)这种写法也经常出现，目的就是在当前实例上执行父类的初始化逻辑。
2.3 apply 的特殊之处：参数以数组形式整体传递
apply 和 call 唯一的区别就是参数形式：apply 接受一个数组（或类数组对象）作为第二个参数，整体传给函数。
最经典的例子是用Math.max求数组的最大值：
const numbers = [10, 5, 78, 33, 99, 1]; const max = Math.max.apply(null, numbers); console.log(max); // 99Math.max接收的是多个参数（Math.max(10, 5, 78)），不是数组。如果数组元素数量不确定，没办法一个个列出来，apply 就派上用场了——它把整个数组“铺开”作为参数列表传进去。ES6 之后我们有了更优雅的写法Math.max(...numbers)，但底层思路是一样的。
apply 的另一个不可替代价值在于“参数转发”。写一个通用的包装函数时，参数个数不确定，收集到的是一整个数组，想原封不动传给目标函数，用 call 就麻烦了，因为你不知道有多少个参数。这时候 apply 是最自然的：
function wrap(fn) { return function(...args) { console.log('即将调用函数，参数个数：', args.length); return fn.apply(this, args); // 把收集到的数组整体转发 }; }防抖、节流、柯里化封装这类高阶函数里，fn.apply(this, args)几乎是标配。
2.4 bind 的独门绝技：锁定 this 而不立即执行
bind 做的事情可以理解为“给函数定制一个永久性的调用环境”：它把 this 和部分参数固定下来，返回一个全新的函数。这个新函数什么时候调用、在哪里调用、怎么调用，this 都不会变了。
最常见的应用是事件回调：
class Counter { constructor() { this.count = 0; this.button = document.querySelector('#btn'); } setup() { // 如果不 bind，点击事件触发时 this 会指向 button 元素，而不是 Counter 实例 this.button.addEventListener('click', this.increment.bind(this)); } increment() { this.count++; console.log(this.count); } }没有 bind 的话，事件系统调用回调时会把 button 作为 this，this.count就变成 undefined 了。bind(this)把 increment 方法“绑定”到当前实例上，事件触发时依然能找到正确的 this。
bind 还有个很实用的顺带能力：预置参数（这也是柯里化的一种形态）。写一个通用的请求函数，再用 bind 生成特定接口的专属函数：
function request(api, params) { console.log(`请求接口：${api}，参数：`, params); } // 预置第一个参数，之后只需要传 params const getUserInfo = request.bind(null, '/api/user/info'); const getOrderList = request.bind(null, '/api/order/list'); getUserInfo({ id: 1 }); getOrderList({ page: 2 });这个模式在事件绑定、定时器传参、函数式编程里都很常见。bind 的名字也起得很形象：把函数“绑”在一个对象上，绑定后就再也拿不下来了。
3. 背着答案也容易翻车：几个边界情况与易错点
3.1 手写实现：把三个方法的内部逻辑拆给你看
我带过的学员里，能把答案背得一字不差的很多，但让他们手写一个简易的 bind，不少人就卡壳了。其实手写实现这三个方法，是检验理解程度的最好方式，也是面试里常见的进阶题。我们逐个来。
先看 call 的实现思路。核心就三步：把目标函数临时挂到指定的 this 对象上、用这个对象去调用函数、调用完把临时属性删掉：
Function.prototype.myCall = function(context, ...args) { // context 为空时的处理：非严格模式下 context 拿不到就指向全局对象 context = context ?? globalThis; // 用 Symbol 生成一个临时键，避免覆盖 context 上的原有属性 const fnKey = Symbol('tempFn'); // 把当前函数挂到 context 上，此时函数的 this 就是 context 了 context[fnKey] = this; // 通过对象方法调用的方式调用函数，args 自动按位置传参 const result = context[fnKey](...args); // 调用完删除临时属性，防止污染目标对象 delete context[fnKey]; return result; };这个实现我加了三个细节：Symbol 键避免命名冲突、调用完 delete 清理现场、context 为空时回退到全局对象。理解了 call 的本质——“让函数成为目标对象的一个临时方法”——你就能明白为什么 call 能把 this 指过去。
apply 的实现和 call 几乎一样，唯一的区别是参数第二步是数组：
Function.prototype.myApply = function(context, argsArray = []) { context = context ?? globalThis; const fnKey = Symbol('tempFn'); context[fnKey] = this; const result = context[fnKey](...argsArray); delete context[fnKey]; return result; };bind 稍微绕一点，它不立即执行，而是返回一个新函数，等新函数调用时再把绑定的 this 和参数合到一起传给原函数：
Function.prototype.myBind = function(context, ...bindArgs) { const originalFn = this; return function(...callArgs) { // 合并 preArgs 和 调用时传入的参数 return originalFn.apply(context, [...bindArgs, ...callArgs]); }; };这个版本包含了柯里化的效果：bind 时传的参数和调用时传的参数会拼在一起作为最终参数。一般的面试问到 bind 实现，这个版本基本能过关。但要注意一点：标准的 bind 返回的函数如果被当作构造函数用new调用，this 会被新对象覆盖（new 绑定的优先级比显式绑定更高），严格版实现要考虑这个情况。面试里能主动说出这一点，水平立刻就拉开了。
3.2 箭头函数与 new：两个绕不过去的优先级问题
先说 new 和显式绑定的优先级。JavaScript 的 this 绑定规则中有个铁律：new 绑定优先级高于显式绑定。什么意思？看这段代码：
const obj = { name: '对象' }; function Person(name) { this.name = name; } Person.call(obj, '小明'); console.log(obj.name); // 小明，this 指向了 obj const BoundPerson = Person.bind(obj); const p = new BoundPerson('小红'); console.log(p.name); // 小红，p 才是 this，不是 obj第一次 call 时，this 被绑到了 obj，obj.name 变成了小明。第二次用 bind 之后再 new，发生了一件有趣的事：虽然 BoundPerson 的 this 被永久绑定到了 obj，但new BoundPerson创建了一个新对象 p，函数执行时 this 指向了 p，而不是 obj。这就是 new 绑定的优先权。
第二个绕不过去的点是箭头函数。箭头函数最大的特点之一就是不绑定自己的 this——它没有自己的 this 绑定，内部的 this 直接继承外层作用域。这意味着：
const obj = { name: '箭头函数测试', normal: function() { console.log(this.name); }, arrow: () => { console.log(this.name); } }; obj.normal(); // 箭头函数测试，this 是 obj obj.arrow(); // undefined，this 是外层作用域的 this（比如 window）箭头函数的 this 是定义时就确定好的，所以你再怎么 call、apply、bind 它都改不了：
const arrowFn = () => { console.log(this); // 这里 this 永远等于定义时所在作用域的 this }; arrowFn.call({ name: '试着改我' }); // 输出仍然是原本的 this，改不动这也是为什么现代开发中箭头函数越来越流行——它天然避免了 this 丢失问题。但要注意，它并不能完全替代 bind，因为有些场景需要“调用时才确定 this”，比如事件监听、对象方法、原型方法，这些场景用箭头函数反而会踩坑。
3.3 严格模式下的意外：null 与 undefined 的 this 处理差异
还有一个细节，很多人写代码时没注意：给 call/apply/bind 传null或undefined作为第一个参数时，this 的指向在严格模式和非严格模式下完全不同。
在非严格模式下，如果第一个参数是 null 或 undefined，this 会被自动替换为全局对象（浏览器中的 window）；而在严格模式下（文件开头写"use strict"或者在 ES Module 里），this 就是你传进去的 null 或 undefined，不会替换。
function showThis() { console.log('this 是：', this); } showThis.call(null); // 非严格模式：this 是 window（全局对象） // 严格模式：this 是 null这就是为什么很多库的源码里会看到“借 null 求最大值”的写法：Math.max.apply(null, arr)。非严格模式下 null 会被替换成全局对象，而Math.max内部根本不依赖 this 的值，所以传什么都没关系。但如果你写的库要在严格模式下运行，或者你自己习惯用严格模式，就得小心这个差异了。
我给的建议是：永远不要依赖“默认绑定”这条隐式规则。要么显式传入一个明确的目标对象，要么用??给个兜底值，不要赌运行环境是非严格模式。我自己封装函数时，习惯性地在开头写context = context ?? globalThis，这样无论什么模式行为都一样。
4. 真实项目里的选型经验：什么时候该用哪个
4.1 我的个人使用频率排序与理由
如果问我在真实项目里哪个用得多，我的排序是：bind 最多，call 次之，apply 最少。这不是拍脑袋说的，而是由实际场景决定的：
- bind 用在“预绑定 this + 稍后调用”的场景最多。事件回调、定时器、防抖节流函数、React 类组件的方法绑定……这些场景都是先把函数准备好，等某个事件发生后再调用，this 不能在调用时临时指定，必须在注册回调前就锁定。所以 bind 的使用频率最高。
- call 用在“借用方法”和“临时换 this”的场景。虽然 ES6 之后很多借用操作有了更现代的原生写法，但在阅读老代码、维护既有系统时，call 的痕迹还很重。
- apply 用得最少，因为展开运算符和剩余参数吸收了大量它原本的阵地。但它并没有消失，只要涉及“参数整体转发”就绕不开它。
4.2 一段实际代码里的三种用法复盘
与其干巴巴地说选型，不如看一段综合了三种用法的代码。假设我们在写一个简单的工具库，里面有个log方法，能把数组参数格式化成字符串并加上前缀：
const logger = { prefix: '[LOG]', formatAndLog(array) { const formatted = Array.prototype.join.call(array, ' -> '); console.log(this.prefix + formatted); } }; function logWithFixedPrefix(prefix, ...items) { // bind 预置 prefix 参数，生成一个专属 logger const specialLogger = { prefix }; const boundLog = logger.formatAndLog.bind(specialLogger); boundLog(items); } logWithFixedPrefix('[ERROR]', '磁盘满', '内存不足', 'CPU高');展开看这里发生了什么：
Array.prototype.join.call(array, ' -> ')：join 本来是数组的方法，通过 call 借给它用。虽然数组本身就有 join 方法，但这里展示的是“借方法”的通用模式，类数组对象也能借。logger.formatAndLog.bind(specialLogger)：把 formatAndLog 的 this 锁定到 specialLogger 上，这样无论什么时候调用 boundLog，this 都稳定指向 specialLogger，prefix 就能正确读取。- 如果你想把一组参数整体交给一个函数而参数个数不确定，那就是 apply 出场的时机：
function callWithSpread(fn, context, argsArray) { return fn.apply(context, argsArray); }这三种方法放在一个任务里，就能明显感觉出来：call 是“借别人的工具给当前对象用”，apply 是“参数打包整体投递”，bind 是“先锁定身份再放出去干活”。方向完全不同，选型的依据就是看你卡在哪个环节。
4.3 面试官最爱问的追问：区别之外的三连问
既然提到了面试，我把我作为面试官经常追问的三个问题也列出来，供大家自查：
第一问：bind 支持柯里化吗？支持。bind 不只是绑定 this，还能预置参数。你可以在 bind 时传一部分参数，调用返回的新函数时传剩余参数，最终参数按顺序拼接。这正是手写 bind 时[...bindArgs, ...callArgs]这个合并动作的意义。
第二问：已经 bind 过的函数，还能用 call 再改变它的 this 吗？不能。bind 返回的新函数内部实现是靠 apply/call 去调用原函数，但它自己并不关心你后续是不是又用了 call。举个例子：
const objA = { name: 'A' }; const objB = { name: 'B' }; function greet() { console.log(this.name); } const boundGreet = greet.bind(objA); boundGreet(); // A boundGreet.call(objB); // 仍然是 A，不是 B因为boundGreet内部已经把 this 写死了，你在外面再怎么 call 都只是调用这个“被绑定过的新函数”，新函数内部还是按时objA执行的。
第三问：三个方法会不会修改原函数？都不会。原函数定义之后，它的代码和 this 绑定行为不会改变。call/apply 只是在“某一次调用”时临时改变了 this，bind 是生成一个新函数，原函数始终是原样。
这三个追问其实就是对“永久绑定”“临时换 this”“不修改原函数”这些关键性质的具体化测试，能回答清楚，说明不是只背了定义，而是真的理解了内部机制。
5. 站在今天的 JavaScript 里重新审视这三个方法
5.1 箭头函数普及后，bind 的使用场景被压缩了多少
ES6 之后，箭头函数成了很多场景下替代 bind 的方案。因为箭头函数不绑定自己的 this，而是继承外层作用域的 this，所以如果你在写回调时能保证外层 this 就是想要的目标，直接用箭头函数就够了：
class Counter { constructor() { this.count = 0; } setup() { // 传统写法 document.querySelector('#btn').addEventListener('click', this.increment.bind(this)); // 箭头函数写法 document.querySelector('#btn').addEventListener('click', (e) => this.increment(e)); } increment() { this.count++; } }箭头函数写法更干净，也不需要额外创建绑定函数。但注意它并没有完全取代 bind：如果回调函数本身需要被解构出来独立使用，或者你拿到的是一个现有的函数引用而不是箭头函数字面量，bind 依然不可替代。比如别人传给你一个写好的函数，你想让它 this 指过去，除了 bind 没有别的办法。
5.2 现代替代语法对 apply 经典场景的冲击
展开运算符确实改变了 apply 的地盘。以前Math.max.apply(null, arr)几乎是唯一的解法，现在Math.max(...arr)一行搞定；以前Array.prototype.slice.call(arguments)转数组，现在Array.from(arguments)和[...arguments]都更直观。
那 apply 是不是可以退休了？并不是。有两个场景它依然有独特价值：一是“参数个数完全不受控”的转发场景，工具函数里经常需要把收到的参数数组整体传给另一个函数，直接fn.apply(this, args)最稳妥；二是某些特殊环境里，展开运算符对超大数组可能会触发参数数量上限的问题，apply 也有它的边界（它们本质上是同一类限制），但如果你在维护兼容旧环境的代码，apply 的可控性会更好。
5.3 框架源码里的 call/apply/bind：为什么它们仍是基石
我在读一些框架和库的源码时，经常看到这三个方法的身影。拿 React 早期的类组件来说，this.handleClick.bind(this)几乎是每个组件里都要写的。Vue 的工具函数里，也少不了Array.prototype.slice.call这种借方法的技巧。事件系统、发布订阅、函数式工具库，到处都是 bind 和 apply 的影子。
这三个方法在 JavaScript 的地基里扎得很深，因为它们直接关联着 this 机制这个核心设计。理解了它们，很多源码里看起来“怪异”的写法都会变得顺理成章。比如看到toArray(list)返回Array.prototype.slice.call(list)，你就知道这是把类数组转正；看到fn.apply(this, args)，你就知道这是参数转发；看到.bind(this)，你就知道作者在锁定调用上下文。
我个人在带团队时的经验是：想验证一个人是不是真的理解了这三个方法，别问他区别，让他手写一个简易版 bind，再解释为什么 bind 过的函数再用 call 改不了 this。能把它拆明白，说明对调用链、this 绑定优先级、柯里化都有了直观的体感。如果只是背答案，建议打开控制台，把本文里的代码段逐个跑一遍，再把 bind 的简易版实现自己写出来，这个知识点才算真正长在你身上。
