十年前我剛學(xué) JavaScript 的時(shí)候就在面試題里遇見過“說說 call、apply、bind 的區(qū)別”。當(dāng)時(shí)我背得滾瓜爛熟call 傳參數(shù)列表、apply 傳數(shù)組、bind 返回新函數(shù)?？烧娴巾?xiàng)目里一用還是會(huì)被 this 整得云里霧里。后來帶過不少人發(fā)現(xiàn)這個(gè)問題幾乎是前端面試的必考題也是區(qū)分“背答案”和“真理解”的試金石。這篇不是給你再抄一遍標(biāo)準(zhǔn)答案而是想把這個(gè)知識(shí)點(diǎn)從頭到尾拆透先說清楚這三個(gè)方法到底在解決什么底層問題再講三者的本質(zhì)差異接著用邊界情況、手寫實(shí)現(xiàn)來檢驗(yàn)理解是否到位最后結(jié)合真實(shí)項(xiàng)目聊一聊怎么選型。不管是準(zhǔn)備面試、閱讀源碼還是日常開發(fā)里遇到 this 丟失這篇都應(yīng)該能幫上忙。1. 從 this 之謎說起這三個(gè)方法究竟在解決什么問題1.1 this 是調(diào)用時(shí)決定的不是定義時(shí)決定的很多初學(xué)者對(duì) call、apply、bind 的困惑根源在于對(duì) this 的理解停留在“指這個(gè)對(duì)象”這樣模糊的層面。要真正搞清楚這三個(gè)方法的作用必須先接受 JavaScript 里一個(gè)非常重要的設(shè)計(jì)函數(shù)的 this 是在調(diào)用時(shí)被決定的而不是在定義時(shí)被決定的。這是什么意思看一個(gè)最簡單的例子const user { name: 小明, sayHi() { console.log(大家好我是${this.name}); } }; user.sayHi(); // 大家好我是小明 const fn user.sayHi; fn(); // 大家好我是undefined同樣一個(gè)函數(shù)在user.sayHi()這種形式下調(diào)用時(shí)因?yàn)樗亲鳛閡ser這個(gè)對(duì)象的方法被調(diào)用的JavaScript 引擎會(huì)把 this 指向user。但當(dāng)我把方法解構(gòu)賦值給變量fn然后用fn()這種方式調(diào)用時(shí)這已經(jīng)變成了一個(gè)普通的函數(shù)調(diào)用此時(shí) this 不再指向user而是指向全局對(duì)象瀏覽器里是 window——在嚴(yán)格模式下甚至是 undefined。我在帶新人時(shí)經(jīng)常會(huì)用一個(gè)生活化的類比this 就像“現(xiàn)場指揮”。函數(shù)定義的時(shí)候誰也不知道指揮是誰只有在函數(shù)真正開始執(zhí)行的那一刻JavaScript 引擎才根據(jù)“你是怎么調(diào)用它的”來確定 this。是obj.method()這樣的形式調(diào)用this 就是 obj是裸調(diào)用method()this 就可能是全局對(duì)象或者 undefined。這就是動(dòng)態(tài) this 的本質(zhì)。1.2 三個(gè)方法解決的就是“this 丟失”的問題理解了 this 是調(diào)用時(shí)決定的自然就能推導(dǎo)出一個(gè)結(jié)論在某些情況下this會(huì)“丟”。最常見的場景就是事件回調(diào)、定時(shí)器、異步任務(wù)、以及把方法解構(gòu)出來單獨(dú)使用。比如const user { name: 小明, sayHi() { console.log(大家好我是${this.name}); } }; setTimeout(user.sayHi, 1000); // 1秒后輸出大家好我是undefinedsetTimeout會(huì)在 1 秒后把user.sayHi這個(gè)函數(shù)作為回調(diào)調(diào)用此時(shí)它是一個(gè)普通的函數(shù)調(diào)用this 丟了。這就是 JS 開發(fā)中非常經(jīng)典的“回調(diào)丟失 this”問題。call、apply、bind這三個(gè)方法核心作用就是在函數(shù)調(diào)用時(shí)顯式地指定 this 的指向所以它們統(tǒng)稱為“顯式綁定”。有了它們我們可以強(qiáng)行告訴引擎“這個(gè)函數(shù)執(zhí)行的時(shí)候this 就給我指向這個(gè)對(duì)象別再給我去猜了。”1.3 動(dòng)態(tài) this 不是 bug而是特性有朋友可能會(huì)問為什么 JavaScript 不采用靜態(tài) this這樣不就永遠(yuǎn)不會(huì)丟了嗎這其實(shí)和 JavaScript 的設(shè)計(jì)哲學(xué)有關(guān)。動(dòng)態(tài) this 給了函數(shù)極大的復(fù)用能力——同一個(gè)函數(shù)可以給不同的對(duì)象“借用”這是原型鏈繼承、混入mixin模式、函數(shù)式編程里很常見的手段。正因?yàn)?this 是靈活的才需要 call、apply、bind 這樣的工具去控制它。這個(gè)背景理解到位之后再看三個(gè)方法的具體區(qū)別就比較順了它們本質(zhì)上都是“改變 this 指向”的工具只是在使用方式、執(zhí)行時(shí)機(jī)上有差異。接下來我們就逐個(gè)擊破。2. call、apply、bind 三兄弟的分工與本質(zhì)區(qū)別2.1 一張表看清楚三者的核心差異先上一個(gè)對(duì)比表把核心差異串起來后面再逐個(gè)展開對(duì)比維度callapplybind執(zhí)行時(shí)機(jī)立即執(zhí)行立即執(zhí)行返回新函數(shù)調(diào)用時(shí)才執(zhí)行傳參方式逐個(gè)列出數(shù)組或類數(shù)組整體傳入逐個(gè)列出可分兩次傳返回值原函數(shù)的執(zhí)行結(jié)果原函數(shù)的執(zhí)行結(jié)果綁定了 this 的新函數(shù)是否修改原函數(shù)不改不改不改但新函數(shù) this 被永久綁定經(jīng)典場景借用方法、臨時(shí)換 this參數(shù)不確定、數(shù)組傳參事件綁定、柯里化、預(yù)置參數(shù)從表格能看出來call 和 apply 是一對(duì)孿生兄弟它們唯一的區(qū)別就是傳參方式而 bind 完全不是一個(gè)路數(shù)它不立即執(zhí)行函數(shù)而是返回一個(gè)新函數(shù)把 this 和參數(shù)“存起來”留到以后調(diào)用。來一段直觀的代碼感受三者差異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的時(shí)候傳入了userB和28返回了一個(gè)新函數(shù)greetBob等到真正調(diào)用時(shí)再傳剩余參數(shù)深圳。這就是它和 call/apply 最大的不同——不立即執(zhí)行先綁定留待后用。2.2 call 的典型用法借用方法與臨時(shí)換主call 最典型的場景是“借用方法”。JavaScript 里很多方法不是某個(gè)類型私有的而是可以“借”給其他對(duì)象用的。最經(jīng)典的例子是用數(shù)組的方法處理偽數(shù)組比如函數(shù)的argumentsfunction list() { // 傳統(tǒng)寫法借用數(shù)組的 slice 方法把 arguments 變成真正的數(shù)組 const args Array.prototype.slice.call(arguments); return args.join(-); } console.log(list(a, b, c)); // a-b-c在我剛?cè)胄心菚?huì)兒Array.prototype.slice.call(arguments)幾乎算是必背代碼。現(xiàn)在有了Array.from和展開運(yùn)算符這種寫法不常見了但在某些說老不老、說新不新的環(huán)境里你依然能在源碼中遇到它。它的核心邏輯就是arguments不是數(shù)組沒有slice方法但我可以把數(shù)組的slice方法借過來通過 call 把 this 指向arguments讓它去“切割”這個(gè)偽數(shù)組再返回一個(gè)真正的數(shù)組。call 的第二個(gè)典型場景是“臨時(shí)換主”。比如你在兩個(gè)對(duì)象之間復(fù)用某個(gè)邏輯const logger { prefix: 【日志】, log(message) { console.log(this.prefix message); } }; const errorLogger { prefix: 【錯(cuò)誤】 }; logger.log(系統(tǒng)啟動(dòng)成功); // 【日志】系統(tǒng)啟動(dòng)成功 logger.log.call(errorLogger, 磁盤空間不足); // 【錯(cuò)誤】磁盤空間不足這里我們復(fù)用了logger.log的邏輯但臨時(shí)把 this 換成了errorLogger不用再寫一遍同結(jié)構(gòu)的函數(shù)。在繼承和混入模式里Parent.method.call(this, ...)這種寫法也經(jīng)常出現(xiàn)目的就是在當(dāng)前實(shí)例上執(zhí)行父類的初始化邏輯。2.3 apply 的特殊之處參數(shù)以數(shù)組形式整體傳遞apply 和 call 唯一的區(qū)別就是參數(shù)形式apply 接受一個(gè)數(shù)組或類數(shù)組對(duì)象作為第二個(gè)參數(shù)整體傳給函數(shù)。最經(jīng)典的例子是用Math.max求數(shù)組的最大值const numbers [10, 5, 78, 33, 99, 1]; const max Math.max.apply(null, numbers); console.log(max); // 99Math.max接收的是多個(gè)參數(shù)Math.max(10, 5, 78)不是數(shù)組。如果數(shù)組元素?cái)?shù)量不確定沒辦法一個(gè)個(gè)列出來apply 就派上用場了——它把整個(gè)數(shù)組“鋪開”作為參數(shù)列表傳進(jìn)去。ES6 之后我們有了更優(yōu)雅的寫法Math.max(...numbers)但底層思路是一樣的。apply 的另一個(gè)不可替代價(jià)值在于“參數(shù)轉(zhuǎn)發(fā)”。寫一個(gè)通用的包裝函數(shù)時(shí)參數(shù)個(gè)數(shù)不確定收集到的是一整個(gè)數(shù)組想原封不動(dòng)傳給目標(biāo)函數(shù)用 call 就麻煩了因?yàn)槟悴恢烙卸嗌賯€(gè)參數(shù)。這時(shí)候 apply 是最自然的function wrap(fn) { return function(...args) { console.log(即將調(diào)用函數(shù)參數(shù)個(gè)數(shù), args.length); return fn.apply(this, args); // 把收集到的數(shù)組整體轉(zhuǎn)發(fā) }; }防抖、節(jié)流、柯里化封裝這類高階函數(shù)里fn.apply(this, args)幾乎是標(biāo)配。2.4 bind 的獨(dú)門絕技鎖定 this 而不立即執(zhí)行bind 做的事情可以理解為“給函數(shù)定制一個(gè)永久性的調(diào)用環(huán)境”它把 this 和部分參數(shù)固定下來返回一個(gè)全新的函數(shù)。這個(gè)新函數(shù)什么時(shí)候調(diào)用、在哪里調(diào)用、怎么調(diào)用this 都不會(huì)變了。最常見的應(yīng)用是事件回調(diào)class Counter { constructor() { this.count 0; this.button document.querySelector(#btn); } setup() { // 如果不 bind點(diǎn)擊事件觸發(fā)時(shí) this 會(huì)指向 button 元素而不是 Counter 實(shí)例 this.button.addEventListener(click, this.increment.bind(this)); } increment() { this.count; console.log(this.count); } }沒有 bind 的話事件系統(tǒng)調(diào)用回調(diào)時(shí)會(huì)把 button 作為 thisthis.count就變成 undefined 了。bind(this)把 increment 方法“綁定”到當(dāng)前實(shí)例上事件觸發(fā)時(shí)依然能找到正確的 this。bind 還有個(gè)很實(shí)用的順帶能力預(yù)置參數(shù)這也是柯里化的一種形態(tài)。寫一個(gè)通用的請(qǐng)求函數(shù)再用 bind 生成特定接口的專屬函數(shù)function request(api, params) { console.log(請(qǐng)求接口${api}參數(shù), params); } // 預(yù)置第一個(gè)參數(shù)之后只需要傳 params const getUserInfo request.bind(null, /api/user/info); const getOrderList request.bind(null, /api/order/list); getUserInfo({ id: 1 }); getOrderList({ page: 2 });這個(gè)模式在事件綁定、定時(shí)器傳參、函數(shù)式編程里都很常見。bind 的名字也起得很形象把函數(shù)“綁”在一個(gè)對(duì)象上綁定后就再也拿不下來了。3. 背著答案也容易翻車幾個(gè)邊界情況與易錯(cuò)點(diǎn)3.1 手寫實(shí)現(xiàn)把三個(gè)方法的內(nèi)部邏輯拆給你看我?guī)н^的學(xué)員里能把答案背得一字不差的很多但讓他們手寫一個(gè)簡易的 bind不少人就卡殼了。其實(shí)手寫實(shí)現(xiàn)這三個(gè)方法是檢驗(yàn)理解程度的最好方式也是面試?yán)锍Ｒ姷倪M(jìn)階題。我們逐個(gè)來。先看 call 的實(shí)現(xiàn)思路。核心就三步把目標(biāo)函數(shù)臨時(shí)掛到指定的 this 對(duì)象上、用這個(gè)對(duì)象去調(diào)用函數(shù)、調(diào)用完把臨時(shí)屬性刪掉Function.prototype.myCall function(context, ...args) { // context 為空時(shí)的處理非嚴(yán)格模式下 context 拿不到就指向全局對(duì)象 context context ?? globalThis; // 用 Symbol 生成一個(gè)臨時(shí)鍵避免覆蓋 context 上的原有屬性 const fnKey Symbol(tempFn); // 把當(dāng)前函數(shù)掛到 context 上此時(shí)函數(shù)的 this 就是 context 了 context[fnKey] this; // 通過對(duì)象方法調(diào)用的方式調(diào)用函數(shù)args 自動(dòng)按位置傳參 const result context[fnKey](...args); // 調(diào)用完刪除臨時(shí)屬性防止污染目標(biāo)對(duì)象 delete context[fnKey]; return result; };這個(gè)實(shí)現(xiàn)我加了三個(gè)細(xì)節(jié)Symbol 鍵避免命名沖突、調(diào)用完 delete 清理現(xiàn)場、context 為空時(shí)回退到全局對(duì)象。理解了 call 的本質(zhì)——“讓函數(shù)成為目標(biāo)對(duì)象的一個(gè)臨時(shí)方法”——你就能明白為什么 call 能把 this 指過去。apply 的實(shí)現(xiàn)和 call 幾乎一樣唯一的區(qū)別是參數(shù)第二步是數(shù)組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 稍微繞一點(diǎn)它不立即執(zhí)行而是返回一個(gè)新函數(shù)等新函數(shù)調(diào)用時(shí)再把綁定的 this 和參數(shù)合到一起傳給原函數(shù)Function.prototype.myBind function(context, ...bindArgs) { const originalFn this; return function(...callArgs) { // 合并 preArgs 和 調(diào)用時(shí)傳入的參數(shù) return originalFn.apply(context, [...bindArgs, ...callArgs]); }; };這個(gè)版本包含了柯里化的效果bind 時(shí)傳的參數(shù)和調(diào)用時(shí)傳的參數(shù)會(huì)拼在一起作為最終參數(shù)。一般的面試問到 bind 實(shí)現(xiàn)這個(gè)版本基本能過關(guān)。但要注意一點(diǎn)標(biāo)準(zhǔn)的 bind 返回的函數(shù)如果被當(dāng)作構(gòu)造函數(shù)用new調(diào)用this 會(huì)被新對(duì)象覆蓋new 綁定的優(yōu)先級(jí)比顯式綁定更高嚴(yán)格版實(shí)現(xiàn)要考慮這個(gè)情況。面試?yán)锬苤鲃?dòng)說出這一點(diǎn)水平立刻就拉開了。3.2 箭頭函數(shù)與 new兩個(gè)繞不過去的優(yōu)先級(jí)問題先說 new 和顯式綁定的優(yōu)先級(jí)。JavaScript 的 this 綁定規(guī)則中有個(gè)鐵律new 綁定優(yōu)先級(jí)高于顯式綁定。什么意思看這段代碼const obj { name: 對(duì)象 }; 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 時(shí)this 被綁到了 objobj.name 變成了小明。第二次用 bind 之后再 new發(fā)生了一件有趣的事雖然 BoundPerson 的 this 被永久綁定到了 obj但new BoundPerson創(chuàng)建了一個(gè)新對(duì)象 p函數(shù)執(zhí)行時(shí) this 指向了 p而不是 obj。這就是 new 綁定的優(yōu)先權(quán)。第二個(gè)繞不過去的點(diǎn)是箭頭函數(shù)。箭頭函數(shù)最大的特點(diǎn)之一就是不綁定自己的 this——它沒有自己的 this 綁定內(nèi)部的 this 直接繼承外層作用域。這意味著const obj { name: 箭頭函數(shù)測試, normal: function() { console.log(this.name); }, arrow: () { console.log(this.name); } }; obj.normal(); // 箭頭函數(shù)測試this 是 obj obj.arrow(); // undefinedthis 是外層作用域的 this比如 window箭頭函數(shù)的 this 是定義時(shí)就確定好的所以你再怎么 call、apply、bind 它都改不了const arrowFn () { console.log(this); // 這里 this 永遠(yuǎn)等于定義時(shí)所在作用域的 this }; arrowFn.call({ name: 試著改我 }); // 輸出仍然是原本的 this改不動(dòng)這也是為什么現(xiàn)代開發(fā)中箭頭函數(shù)越來越流行——它天然避免了 this 丟失問題。但要注意它并不能完全替代 bind因?yàn)橛行﹫鼍靶枰罢{(diào)用時(shí)才確定 this”比如事件監(jiān)聽、對(duì)象方法、原型方法這些場景用箭頭函數(shù)反而會(huì)踩坑。3.3 嚴(yán)格模式下的意外null 與 undefined 的 this 處理差異還有一個(gè)細(xì)節(jié)很多人寫代碼時(shí)沒注意給 call/apply/bind 傳null或undefined作為第一個(gè)參數(shù)時(shí)this 的指向在嚴(yán)格模式和非嚴(yán)格模式下完全不同。在非嚴(yán)格模式下如果第一個(gè)參數(shù)是 null 或 undefinedthis 會(huì)被自動(dòng)替換為全局對(duì)象瀏覽器中的 window而在嚴(yán)格模式下文件開頭寫use strict或者在 ES Module 里this 就是你傳進(jìn)去的 null 或 undefined不會(huì)替換。function showThis() { console.log(this 是, this); } showThis.call(null); // 非嚴(yán)格模式this 是 window全局對(duì)象 // 嚴(yán)格模式this 是 null這就是為什么很多庫的源碼里會(huì)看到“借 null 求最大值”的寫法Math.max.apply(null, arr)。非嚴(yán)格模式下 null 會(huì)被替換成全局對(duì)象而Math.max內(nèi)部根本不依賴 this 的值所以傳什么都沒關(guān)系。但如果你寫的庫要在嚴(yán)格模式下運(yùn)行或者你自己習(xí)慣用嚴(yán)格模式就得小心這個(gè)差異了。我給的建議是永遠(yuǎn)不要依賴“默認(rèn)綁定”這條隱式規(guī)則。要么顯式傳入一個(gè)明確的目標(biāo)對(duì)象要么用??給個(gè)兜底值不要賭運(yùn)行環(huán)境是非嚴(yán)格模式。我自己封裝函數(shù)時(shí)習(xí)慣性地在開頭寫context context ?? globalThis這樣無論什么模式行為都一樣。4. 真實(shí)項(xiàng)目里的選型經(jīng)驗(yàn)什么時(shí)候該用哪個(gè)4.1 我的個(gè)人使用頻率排序與理由如果問我在真實(shí)項(xiàng)目里哪個(gè)用得多我的排序是bind 最多call 次之a(chǎn)pply 最少。這不是拍腦袋說的而是由實(shí)際場景決定的bind 用在“預(yù)綁定 this 稍后調(diào)用”的場景最多。事件回調(diào)、定時(shí)器、防抖節(jié)流函數(shù)、React 類組件的方法綁定……這些場景都是先把函數(shù)準(zhǔn)備好等某個(gè)事件發(fā)生后再調(diào)用this 不能在調(diào)用時(shí)臨時(shí)指定必須在注冊(cè)回調(diào)前就鎖定。所以 bind 的使用頻率最高。call 用在“借用方法”和“臨時(shí)換 this”的場景。雖然 ES6 之后很多借用操作有了更現(xiàn)代的原生寫法但在閱讀老代碼、維護(hù)既有系統(tǒng)時(shí)call 的痕跡還很重。apply 用得最少因?yàn)檎归_運(yùn)算符和剩余參數(shù)吸收了大量它原本的陣地。但它并沒有消失只要涉及“參數(shù)整體轉(zhuǎn)發(fā)”就繞不開它。4.2 一段實(shí)際代碼里的三種用法復(fù)盤與其干巴巴地說選型不如看一段綜合了三種用法的代碼。假設(shè)我們?cè)趯懸粋€(gè)簡單的工具庫里面有個(gè)log方法能把數(shù)組參數(shù)格式化成字符串并加上前綴const logger { prefix: [LOG], formatAndLog(array) { const formatted Array.prototype.join.call(array, - ); console.log(this.prefix formatted); } }; function logWithFixedPrefix(prefix, ...items) { // bind 預(yù)置 prefix 參數(shù)生成一個(gè)專屬 logger const specialLogger { prefix }; const boundLog logger.formatAndLog.bind(specialLogger); boundLog(items); } logWithFixedPrefix([ERROR], 磁盤滿, 內(nèi)存不足, CPU高);展開看這里發(fā)生了什么Array.prototype.join.call(array, - )join 本來是數(shù)組的方法通過 call 借給它用。雖然數(shù)組本身就有 join 方法但這里展示的是“借方法”的通用模式類數(shù)組對(duì)象也能借。logger.formatAndLog.bind(specialLogger)把 formatAndLog 的 this 鎖定到 specialLogger 上這樣無論什么時(shí)候調(diào)用 boundLogthis 都穩(wěn)定指向 specialLoggerprefix 就能正確讀取。如果你想把一組參數(shù)整體交給一個(gè)函數(shù)而參數(shù)個(gè)數(shù)不確定那就是 apply 出場的時(shí)機(jī)function callWithSpread(fn, context, argsArray) { return fn.apply(context, argsArray); }這三種方法放在一個(gè)任務(wù)里就能明顯感覺出來call 是“借別人的工具給當(dāng)前對(duì)象用”apply 是“參數(shù)打包整體投遞”bind 是“先鎖定身份再放出去干活”。方向完全不同選型的依據(jù)就是看你卡在哪個(gè)環(huán)節(jié)。4.3 面試官最愛問的追問區(qū)別之外的三連問既然提到了面試我把我作為面試官經(jīng)常追問的三個(gè)問題也列出來供大家自查第一問bind 支持柯里化嗎支持。bind 不只是綁定 this還能預(yù)置參數(shù)。你可以在 bind 時(shí)傳一部分參數(shù)調(diào)用返回的新函數(shù)時(shí)傳剩余參數(shù)最終參數(shù)按順序拼接。這正是手寫 bind 時(shí)[...bindArgs, ...callArgs]這個(gè)合并動(dòng)作的意義。第二問已經(jīng) bind 過的函數(shù)還能用 call 再改變它的 this 嗎不能。bind 返回的新函數(shù)內(nèi)部實(shí)現(xiàn)是靠 apply/call 去調(diào)用原函數(shù)但它自己并不關(guān)心你后續(xù)是不是又用了 call。舉個(gè)例子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因?yàn)閎oundGreet內(nèi)部已經(jīng)把 this 寫死了你在外面再怎么 call 都只是調(diào)用這個(gè)“被綁定過的新函數(shù)”新函數(shù)內(nèi)部還是按時(shí)objA執(zhí)行的。第三問三個(gè)方法會(huì)不會(huì)修改原函數(shù)都不會(huì)。原函數(shù)定義之后它的代碼和 this 綁定行為不會(huì)改變。call/apply 只是在“某一次調(diào)用”時(shí)臨時(shí)改變了 thisbind 是生成一個(gè)新函數(shù)原函數(shù)始終是原樣。這三個(gè)追問其實(shí)就是對(duì)“永久綁定”“臨時(shí)換 this”“不修改原函數(shù)”這些關(guān)鍵性質(zhì)的具體化測試能回答清楚說明不是只背了定義而是真的理解了內(nèi)部機(jī)制。5. 站在今天的 JavaScript 里重新審視這三個(gè)方法5.1 箭頭函數(shù)普及后bind 的使用場景被壓縮了多少ES6 之后箭頭函數(shù)成了很多場景下替代 bind 的方案。因?yàn)榧^函數(shù)不綁定自己的 this而是繼承外層作用域的 this所以如果你在寫回調(diào)時(shí)能保證外層 this 就是想要的目標(biāo)直接用箭頭函數(shù)就夠了class Counter { constructor() { this.count 0; } setup() { // 傳統(tǒng)寫法 document.querySelector(#btn).addEventListener(click, this.increment.bind(this)); // 箭頭函數(shù)寫法 document.querySelector(#btn).addEventListener(click, (e) this.increment(e)); } increment() { this.count; } }箭頭函數(shù)寫法更干凈也不需要額外創(chuàng)建綁定函數(shù)。但注意它并沒有完全取代 bind如果回調(diào)函數(shù)本身需要被解構(gòu)出來獨(dú)立使用或者你拿到的是一個(gè)現(xiàn)有的函數(shù)引用而不是箭頭函數(shù)字面量bind 依然不可替代。比如別人傳給你一個(gè)寫好的函數(shù)你想讓它 this 指過去除了 bind 沒有別的辦法。5.2 現(xiàn)代替代語法對(duì) apply 經(jīng)典場景的沖擊展開運(yùn)算符確實(shí)改變了 apply 的地盤。以前Math.max.apply(null, arr)幾乎是唯一的解法現(xiàn)在Math.max(...arr)一行搞定以前Array.prototype.slice.call(arguments)轉(zhuǎn)數(shù)組現(xiàn)在Array.from(arguments)和[...arguments]都更直觀。那 apply 是不是可以退休了并不是。有兩個(gè)場景它依然有獨(dú)特價(jià)值一是“參數(shù)個(gè)數(shù)完全不受控”的轉(zhuǎn)發(fā)場景工具函數(shù)里經(jīng)常需要把收到的參數(shù)數(shù)組整體傳給另一個(gè)函數(shù)直接fn.apply(this, args)最穩(wěn)妥二是某些特殊環(huán)境里展開運(yùn)算符對(duì)超大數(shù)組可能會(huì)觸發(fā)參數(shù)數(shù)量上限的問題apply 也有它的邊界它們本質(zhì)上是同一類限制但如果你在維護(hù)兼容舊環(huán)境的代碼apply 的可控性會(huì)更好。5.3 框架源碼里的 call/apply/bind為什么它們?nèi)允腔以谧x一些框架和庫的源碼時(shí)經(jīng)?？吹竭@三個(gè)方法的身影。拿 React 早期的類組件來說this.handleClick.bind(this)幾乎是每個(gè)組件里都要寫的。Vue 的工具函數(shù)里也少不了Array.prototype.slice.call這種借方法的技巧。事件系統(tǒng)、發(fā)布訂閱、函數(shù)式工具庫到處都是 bind 和 apply 的影子。這三個(gè)方法在 JavaScript 的地基里扎得很深因?yàn)樗鼈冎苯雨P(guān)聯(lián)著 this 機(jī)制這個(gè)核心設(shè)計(jì)。理解了它們很多源碼里看起來“怪異”的寫法都會(huì)變得順理成章。比如看到toArray(list)返回Array.prototype.slice.call(list)你就知道這是把類數(shù)組轉(zhuǎn)正看到fn.apply(this, args)你就知道這是參數(shù)轉(zhuǎn)發(fā)看到.bind(this)你就知道作者在鎖定調(diào)用上下文。我個(gè)人在帶團(tuán)隊(duì)時(shí)的經(jīng)驗(yàn)是想驗(yàn)證一個(gè)人是不是真的理解了這三個(gè)方法別問他區(qū)別讓他手寫一個(gè)簡易版 bind再解釋為什么 bind 過的函數(shù)再用 call 改不了 this。能把它拆明白說明對(duì)調(diào)用鏈、this 綁定優(yōu)先級(jí)、柯里化都有了直觀的體感。如果只是背答案建議打開控制臺(tái)把本文里的代碼段逐個(gè)跑一遍再把 bind 的簡易版實(shí)現(xiàn)自己寫出來這個(gè)知識(shí)點(diǎn)才算真正長在你身上。