上周給幾個(gè)準(zhǔn)備校招的朋友過(guò)了一遍手寫(xiě) apply發(fā)現(xiàn)一個(gè)很有意思的現(xiàn)象凡是能順利寫(xiě)出來(lái)的都是真正想通了 this 綁定的人凡是卡住的基本都被“怎么讓這個(gè)函數(shù)用我指定的 this 去調(diào)用”這句話(huà)繞暈了。這道題在面試?yán)锍霈F(xiàn)頻率高不是因?yàn)樗y而是它把 JavaScript 的函數(shù)調(diào)用機(jī)制、原型鏈、參數(shù)處理、異常清理全部串在了一塊。這篇文章就拿 call 當(dāng)對(duì)照組把 apply 從最小實(shí)現(xiàn)到健壯版本逐步拆開(kāi)。我不繞彎子直接給你看完整結(jié)論apply 和 call 的區(qū)別只有參數(shù)傳入方式不同其余機(jī)制完全同源。理解了這一點(diǎn)手寫(xiě) apply 的難度會(huì)瞬間下降一個(gè)量級(jí)。文章里我會(huì)把每一行代碼為什么這么寫(xiě)、常見(jiàn)邊界怎么處理、動(dòng)手測(cè)試會(huì)遇到哪些坑都展開(kāi)講適合正在準(zhǔn)備面試的開(kāi)發(fā)者也適合想弄明白 this 到底怎么工作的人。1. 動(dòng)手之前先搞清楚 this 到底是怎么決定的1.1 四條綁定規(guī)則重點(diǎn)先看“方法調(diào)用”JavaScript 里的 this 不是在定義函數(shù)時(shí)確定的而是在函數(shù)被調(diào)用的一瞬間由調(diào)用方式?jīng)Q定。日常見(jiàn)到的 this 綁定規(guī)則可以濃縮成四種默認(rèn)綁定直接裸調(diào)fn()非嚴(yán)格模式下 this 指向全局對(duì)象嚴(yán)格模式下是undefined。隱式綁定通過(guò)對(duì)象屬性調(diào)用obj.fn()this 指向obj。顯式綁定用fn.call(obj)、fn.apply(obj)、fn.bind(obj)手動(dòng)指定。new 綁定構(gòu)造函數(shù)被new調(diào)用時(shí)this 指向新創(chuàng)建的對(duì)象。四條規(guī)則的優(yōu)先級(jí)是new 顯式綁定 隱式綁定 默認(rèn)綁定。這四條里手寫(xiě) apply 真正用到的是“隱式綁定”。有個(gè)現(xiàn)象很多人天天見(jiàn)卻沒(méi)回過(guò)味來(lái)obj.method()之所以 this 指向 obj是因?yàn)楹瘮?shù)調(diào)用時(shí)點(diǎn)號(hào)左邊的對(duì)象會(huì)作為基準(zhǔn)把 this 綁定到它身上。這不是什么魔法而是 JS 語(yǔ)言規(guī)范對(duì)“成員表達(dá)式調(diào)用”的固定處理。既然引擎面對(duì)obj.method()會(huì)把 this 指向 obj那我們能不能反過(guò)來(lái)用這個(gè)機(jī)制把任何一個(gè)函數(shù)臨時(shí)變成某個(gè)對(duì)象的屬性再用obj.fn()的形式調(diào)用this 是不是就自然等于那個(gè)對(duì)象了這就是手寫(xiě) apply 的底層邏輯。1.2 手寫(xiě) apply 的本質(zhì)把函數(shù)“借”給對(duì)象當(dāng)方法用一次理解了隱式綁定apply 的實(shí)現(xiàn)思路其實(shí)一句話(huà)就能說(shuō)清把被調(diào)用的函數(shù)臨時(shí)掛到指定對(duì)象上當(dāng)作對(duì)象的方法調(diào)用一次調(diào)用完立刻刪除這個(gè)臨時(shí)屬性。寫(xiě)得更流程化一點(diǎn)拿到目標(biāo)函數(shù)它此時(shí)是this。把目標(biāo)函數(shù)賦值到context對(duì)象上例如context.fn this。用context.fn(...args)的方式調(diào)用this 自動(dòng)就是context。拿到返回值后刪除context.fn這個(gè)臨時(shí)屬性。把返回值拋給調(diào)用者。這個(gè)過(guò)程可以類(lèi)比成“借鄰居的廚房做一頓飯”你手里有烤箱目標(biāo)函數(shù)鄰居家有廚房context 對(duì)象你把烤箱搬進(jìn)鄰居家、固定在臺(tái)面上context.fn this做完菜、取走菜拿到 return 值再把烤箱搬走delete 臨時(shí)屬性。有一個(gè)細(xì)節(jié)必須留意整個(gè)過(guò)程中臨時(shí)掛上去的那個(gè)屬性不能被原對(duì)象已有的屬性“撞車(chē)”也不能污染原對(duì)象。所以后來(lái) ES6 時(shí)代我們普遍用Symbol生成唯一 key而不是隨便起一個(gè)字符串名字。這個(gè)是后話(huà)第 3 章會(huì)專(zhuān)門(mén)展開(kāi)?，F(xiàn)在再回頭看為什么手寫(xiě) apply 要寫(xiě)在Function.prototype上。因?yàn)?apply 是所有函數(shù)共用的能力掛在原型上任何一個(gè)函數(shù)都可以通過(guò)fn.myApply(...)訪(fǎng)問(wèn)到此時(shí)方法內(nèi)部的this就是調(diào)用它的那個(gè)函數(shù)。如果你想放在普通函數(shù)里也行但那就無(wú)法做到“任何函數(shù)都能直接用”所以原型擴(kuò)展是唯一合理位置。2. call 與 apply 的差異一個(gè)傳參數(shù)列表一個(gè)傳參數(shù)數(shù)組2.1 原生行為對(duì)比代碼幾乎一樣就差一手參數(shù)展開(kāi)很多人會(huì)把 call 和 apply 當(dāng)成兩個(gè)孤立的 API 去背其實(shí)它們的內(nèi)部骨架完全一致。用同一個(gè)加法函數(shù)舉例function sum(a, b, c) { return a b c; } // call參數(shù)一個(gè)個(gè)列出來(lái) sum.call(null, 1, 2, 3); // 6 // apply參數(shù)放在數(shù)組或類(lèi)數(shù)組里 sum.apply(null, [1, 2, 3]); // 6用表格看幾點(diǎn)核心對(duì)比對(duì)比維度callapply手寫(xiě)時(shí)關(guān)注點(diǎn)thisArg 綁定支持支持兩者一致處理 null/undefined 的方式相同參數(shù)傳入形式不定長(zhǎng)參數(shù)列表數(shù)組 / 類(lèi)數(shù)組對(duì)象apply 多做一步“展開(kāi)數(shù)組”是否立即執(zhí)行是是返回值都來(lái)自原函數(shù)的 return典型場(chǎng)景參數(shù)個(gè)數(shù)固定參數(shù)動(dòng)態(tài)生成、存在數(shù)組里ES6 之前 apply 幾乎無(wú)法被替代在 ES5 時(shí)代apply 有一個(gè)殺手級(jí)場(chǎng)景把一個(gè)數(shù)組元素批量展開(kāi)傳給函數(shù)。Math.max.apply(null, [1, 2, 3])是當(dāng)年取數(shù)組最大值的標(biāo)準(zhǔn)寫(xiě)法因?yàn)镸ath.max不接收數(shù)組、只接收不定長(zhǎng)參數(shù)而 apply 恰好能把數(shù)組“拆”成一個(gè)個(gè)參數(shù)送進(jìn)去。同樣的場(chǎng)景還有arr1.push.apply(arr1, arr2)。到了 ES6展開(kāi)運(yùn)算符出來(lái)之后這兩個(gè)場(chǎng)景都能直接寫(xiě)成Math.max(...[1, 2, 3])和arr1.push(...arr2)。所以現(xiàn)在 apply 在日常代碼里的出鏡率確實(shí)低了不少但面試題依然愛(ài)考因?yàn)樗嫉牟皇恰澳銜?huì)不會(huì)用”而是“你是否理解函數(shù)調(diào)用的本質(zhì)”。2.2 為什么“基于 call 對(duì)比”是吃透 apply 的最短路徑這里有個(gè)很關(guān)鍵的理解call 本質(zhì)上可以被 apply 實(shí)現(xiàn)反之則不行至少在 ES5 下不行。先看正向推導(dǎo)。手寫(xiě)一個(gè) myCall 只需要一行Function.prototype.myCall function (context, ...rest) { return this.myApply(context, rest); };為什么能這么寫(xiě)因?yàn)?rest 參數(shù)收集到的本身就是數(shù)組把它直接作為 apply 的第二個(gè)參數(shù)就完成了“參數(shù)列表 → 參數(shù)數(shù)組”的轉(zhuǎn)換。反過(guò)來(lái)假如先手寫(xiě) call再想從 call 推導(dǎo)出 apply就卡住了call 接收的是arg1, arg2, arg3...這種獨(dú)立參數(shù)你當(dāng)然可以用arguments拿到偽數(shù)組但問(wèn)題是 ES5 沒(méi)有展開(kāi)運(yùn)算符你無(wú)法把一個(gè)數(shù)組“拆”成獨(dú)立參數(shù)傳給函數(shù)。也就是說(shuō)apply 比 call 多繞了一道“參數(shù)數(shù)組展開(kāi)”這個(gè)操作在 ES6 之前沒(méi)有語(yǔ)法層面的原生支持只能靠 apply 自己實(shí)現(xiàn)。所以標(biāo)題說(shuō)“5 分鐘吃透”的底氣從這里來(lái)你只要記住 call 的 this 綁定機(jī)制apply 只是在參數(shù)處理上多了一個(gè)數(shù)組展開(kāi)動(dòng)作其余完全沒(méi)有區(qū)別。當(dāng)你把差異定位到這一點(diǎn)手寫(xiě) apply 就不是背代碼而是順理成章地把 call 的實(shí)現(xiàn)延伸一下。3. 手寫(xiě) myApply從最小實(shí)現(xiàn)到健壯版3.1 最小實(shí)現(xiàn)核心邏輯只有幾行先把核心邏輯跑通。有一版“最小實(shí)現(xiàn)”長(zhǎng)這樣Function.prototype.myApply function (context, args) { context context null ? globalThis : Object(context); const fnKey Symbol(臨時(shí)方法); context[fnKey] this; const result context[fnKey](...args); delete context[fnKey]; return result; };這段代碼已經(jīng)能 work 于大部分常規(guī)情況指定 this、傳數(shù)組參數(shù)、返回原函數(shù)結(jié)果、清理臨時(shí)屬性。但注意它還遠(yuǎn)不夠健壯。至少存在三個(gè)明顯問(wèn)題如果args不是數(shù)組比如傳了undefined或者類(lèi)數(shù)組對(duì)象...args行為就會(huì)偏離原生 apply。如果原函數(shù)執(zhí)行過(guò)程中拋出異常delete context[fnKey]永遠(yuǎn)不會(huì)執(zhí)行臨時(shí)屬性殘留。如果調(diào)用 myApply 的this根本不是函數(shù)代碼不會(huì)給出明確報(bào)錯(cuò)。這些問(wèn)題不是考試刁難而是真實(shí)環(huán)境里遲早會(huì)撞上的邊界。所以下面給出完整版。3.2 健壯版逐行說(shuō)明“為什么這么寫(xiě)”Function.prototype.myApply function (context, argsArray) { // 1. 保證調(diào)用者是一個(gè)函數(shù) if (typeof this ! function) { throw new TypeError(this is not callable); } // 2. 處理 thisArgnull/undefined 指向全局對(duì)象原始類(lèi)型裝箱 const ctx context null ? globalThis : Object(context); // 3. 生成唯一 key避免覆蓋原對(duì)象已有屬性 const fnKey Symbol(臨時(shí)方法); // 4. 把當(dāng)前函數(shù)掛到目標(biāo)對(duì)象上 ctx[fnKey] this; // 5. 參數(shù)數(shù)組標(biāo)準(zhǔn)化null/undefined 視為無(wú)參類(lèi)數(shù)組轉(zhuǎn)為真數(shù)組 let argsList; if (argsArray null) { argsList []; } else if (typeof argsArray object || typeof argsArray function) { argsList Array.from(argsArray); } else { throw new TypeError(CreateListFromArrayLike called on non-object); } // 6. 調(diào)用原函數(shù)無(wú)論是否拋錯(cuò)都要清理臨時(shí)屬性 try { return ctx[fnKey](...argsList); } finally { delete ctx[fnKey]; } };逐段拆解第一步的類(lèi)型檢查。Function.prototype.myApply這個(gè)方法本身可能被任何值調(diào)用比如你把一個(gè)普通對(duì)象當(dāng)成函數(shù)來(lái)用const fake {}; fake.myApply(...)此時(shí)方法內(nèi)部的this是{}不是函數(shù)。原生 apply 面對(duì)這種情況會(huì)拋TypeError我們手寫(xiě)版也應(yīng)該給出一致的行為。這也解釋了為什么很多手寫(xiě)題會(huì)包含typeof this ! function判斷——它不是可有可無(wú)的防御代碼而是為了向原生行為對(duì)齊。第二步的 context 處理。這里用了context null這種寫(xiě)法注意是寬松等于它一次性覆蓋了context null和context undefined兩種情況。為什么它們要指向全局對(duì)象因?yàn)樵?apply 的非嚴(yán)格模式語(yǔ)義就是如此顯式傳入 null 或 undefined 時(shí)this 默認(rèn)綁定全局對(duì)象。globalThis是 ES2020 之后跨環(huán)境的通用全局對(duì)象在瀏覽器里是window在 Node 里是global。Object(context)這一步解決的是原始類(lèi)型問(wèn)題。如果你myApply(hello, ...)Object(hello)會(huì)返回一個(gè) String 包裝對(duì)象這樣屬性才能掛上去。這一步不是過(guò)度設(shè)計(jì)如果你不加字符串、數(shù)字、布爾值這些原始類(lèi)型會(huì)讓你踩進(jìn)一個(gè)隱蔽的坑第 4 章會(huì)專(zhuān)門(mén)演示。第三步的 Symbol key。為什么不用__fn__這種字符串兩個(gè)原因。第一普通字符串可能和對(duì)象已有的屬性撞車(chē)比如對(duì)象本身就有__fn__屬性那你就把人家覆蓋了。第二Symbol 每次創(chuàng)建都是全新的、唯一的不可能和已有屬性撞名字還能保證delete時(shí)刪的一定是自己剛掛上去的那個(gè)屬性。順帶補(bǔ)充一個(gè)歷史背景ES5 時(shí)代沒(méi)有 Symbol那時(shí)候手寫(xiě) call/apply 的 polyfill 通常用隨機(jī)字符串模擬const key __tempFn_ Date.now() _ Math.random();這種做法只能“大概率不沖突”并不能絕對(duì)保證。Symbol 出來(lái)后這個(gè)隱患才算徹底解決。所以現(xiàn)在做手寫(xiě)題用 Symbol 是比隨機(jī)字符串更正確的方案。第五步的參數(shù)處理。原生 apply 的第二個(gè)參數(shù)規(guī)范層面的定義是“數(shù)組或類(lèi)數(shù)組對(duì)象”也就是要有l(wèi)ength屬性和數(shù)字下標(biāo)。arguments對(duì)象、DOM 節(jié)點(diǎn)列表、{ 0: a, 1: b, length: 2 }這類(lèi)結(jié)構(gòu)原生 apply 都能處理。Array.from恰好能把類(lèi)數(shù)組轉(zhuǎn)成真數(shù)組這樣后面展開(kāi)時(shí)就能直接使用...argsList。這里要特別提一下Array.from對(duì)字符串也有效但原生 apply 接收原始字符串會(huì)拋TypeError。所以完整版里先用typeof argsArray object || typeof argsArray function做了前置校驗(yàn)把字符串、數(shù)字這類(lèi)原始值擋在門(mén)外行為才能和原生對(duì)齊。第六步的 try/finally。這是很多手寫(xiě)教程不講、但實(shí)際價(jià)值很高的細(xì)節(jié)。如果原函數(shù)執(zhí)行到一半拋錯(cuò)沒(méi)有 finally 的情況下delete ctx[fnKey]會(huì)跳過(guò)臨時(shí)屬性會(huì)永遠(yuǎn)留在那個(gè)對(duì)象上。用try/finally保證無(wú)論函數(shù)是否正常返回清理動(dòng)作都會(huì)執(zhí)行。你可以在控制臺(tái)這樣驗(yàn)證殘留問(wèn)題const obj {}; function boom() { throw new Error(xx); } // 沒(méi)有 finally 的實(shí)現(xiàn) try { boom.myApplyNoFinally(obj, []); } catch (e) {} console.log(Object.getOwnPropertySymbols(obj)); // 能看到殘留的 Symbol 屬性有 finally 的版本再測(cè)結(jié)果會(huì)是空數(shù)組。3.3 為什么不直接寫(xiě)context[fnKey](...args)而要多包一層有人可能會(huì)問(wèn)既然 args 本來(lái)就是數(shù)組Array.from不是多余嗎這里必須考慮到 apply 的第二個(gè)參數(shù)不一定是數(shù)組。真實(shí)的調(diào)用可能是add.myApply(obj, arguments); // 函數(shù)內(nèi)部拿到的 arguments 類(lèi)數(shù)組 add.myApply(obj, { 0: 1, 1: 2, length: 2 }); add.myApply(obj, undefined); // 不傳第二個(gè)參數(shù)如果只寫(xiě)...args參數(shù)為 undefined 時(shí)直接展開(kāi)是允許的結(jié)果相當(dāng)于無(wú)參調(diào)用但遇到?jīng)]有l(wèi)ength的對(duì)象時(shí)展開(kāi)行為就不受控了。為了對(duì)原生行為負(fù)責(zé)參數(shù)標(biāo)準(zhǔn)化的步驟不該省。4. 實(shí)測(cè)中的三個(gè)坑手寫(xiě)版與原生 apply 差在哪4.1 坑 1context 是凍結(jié)對(duì)象賦值會(huì)失敗這是手寫(xiě)方案和原生方案最本質(zhì)的差別說(shuō)句大實(shí)話(huà)手寫(xiě)版在某些極端情況下不可能 100% 等同原生。原生 apply 是引擎內(nèi)部操作不需要真的往對(duì)象上掛屬性我們的模擬方案必須寫(xiě)屬性那就繞不開(kāi)對(duì)象是否可擴(kuò)展、是否凍結(jié)的問(wèn)題。const frozenCtx Object.freeze({ x: 1 }); function getX() { return this.x; } getX.apply(frozenCtx); // 原生1正常工作 getX.myApply(frozenCtx, []); // 手寫(xiě)嚴(yán)格模式下拋 TypeError原因很簡(jiǎn)單ctx[fnKey] this試圖給凍結(jié)對(duì)象新增屬性嚴(yán)格模式下直接報(bào)錯(cuò)。想完全模擬原生行為就得徹底換思路比如用WeakMap做映射、把函數(shù)和 context 關(guān)聯(lián)起來(lái)不往對(duì)象上掛任何屬性。這種實(shí)現(xiàn)更接近原生的“旁路”思路但底層原理就不再是“臨時(shí)借用方法調(diào)用”了。作為面試和原理理解知道這個(gè)邊界就足夠了——真實(shí)業(yè)務(wù)里你不會(huì)給凍結(jié)對(duì)象調(diào) apply。4.2 坑 2原始類(lèi)型 context 不裝箱屬性根本掛不住這個(gè)坑比上一個(gè)隱蔽得多?？催@段常見(jiàn)錯(cuò)誤寫(xiě)法Function.prototype.badApply function (context, args) { const key Symbol(fn); context[key] this; // 假設(shè) context 是 hello return context[key](...args); };當(dāng)你執(zhí)行someFn.badApply(hello)時(shí)hello是一個(gè)原始字符串。第一行的context[key] this確實(shí)會(huì)執(zhí)行但這里有個(gè)微妙的機(jī)制點(diǎn)運(yùn)算符訪(fǎng)問(wèn)原始值時(shí)會(huì)臨時(shí)創(chuàng)建一個(gè)包裝對(duì)象屬性實(shí)際上賦值到了這個(gè)臨時(shí)對(duì)象上。到了第二行再訪(fǎng)問(wèn)context[key]時(shí)字符串又臨時(shí)創(chuàng)建了一個(gè)新的包裝對(duì)象這個(gè)新對(duì)象上沒(méi)有你剛掛的屬性于是調(diào)用直接失敗。這在非嚴(yán)格模式下不會(huì)報(bào)錯(cuò)但結(jié)果永遠(yuǎn)是undefined is not a function而且特別難排查。解決辦法就是前面說(shuō)的Object(context)先把原始值裝箱成同一個(gè)包裝對(duì)象然后在同一個(gè)對(duì)象上完成賦值、調(diào)用、刪除。const ctx context null ? globalThis : Object(context);Object(hello)返回的是字符串包裝對(duì)象后續(xù)所有屬性操作都在這個(gè)對(duì)象上問(wèn)題自然解除。4.3 坑 3第二個(gè)參數(shù)不是數(shù)組行為就跑偏原生 apply 對(duì)第二個(gè)參數(shù)有一套完整的類(lèi)型校驗(yàn)null/undefined 接受數(shù)組和類(lèi)數(shù)組對(duì)象接受其他類(lèi)型拋TypeError。手寫(xiě)版很容易把校驗(yàn)漏掉。比如你傳一個(gè)數(shù)字5給 apply 的第二個(gè)參數(shù)原生直接報(bào)錯(cuò)手寫(xiě)版如果簡(jiǎn)單寫(xiě)成context[fnKey](...args)...5會(huì)靜默展開(kāi)成空參數(shù)列表沒(méi)有任何異常提示。這類(lèi)行為差異在單元測(cè)試?yán)锖苋菀茁┑羲酝暾胬锴爸玫膖ypeof argsArray檢查是必要的。還有一個(gè)容易忽略的類(lèi)數(shù)組邊界Array.from會(huì)把字符串轉(zhuǎn)成字符數(shù)組但原生 apply 對(duì)原始字符串是拒絕的。完整版用typeof argsArray object || typeof argsArray function把字符串擋在外面才算和原生對(duì)齊。4.4 附帶提醒不要直接改寫(xiě) Function.prototype.apply練習(xí)歸練習(xí)生產(chǎn)環(huán)境里不要去覆蓋原生Function.prototype.apply。很多框架內(nèi)部的工具函數(shù)、第三方庫(kù)的兼容層都依賴(lài)原生行為你覆蓋之后輕則行為不一致重則導(dǎo)致運(yùn)行時(shí)報(bào)錯(cuò)。想驗(yàn)證自己的實(shí)現(xiàn)掛一個(gè)獨(dú)立名字的myApply最安全。如果你真要寫(xiě) polyfill也要嚴(yán)格對(duì)齊規(guī)范并且把它放在業(yè)務(wù)代碼加載之前同時(shí)保留對(duì)原生方法的引用以便降級(jí)。不過(guò)說(shuō)實(shí)話(huà)以現(xiàn)在瀏覽器的兼容性apply polyfill 的應(yīng)用場(chǎng)景已經(jīng)非常小了它更多是一個(gè)學(xué)習(xí)道具。5. 一舉三得從 myApply 瞬間推導(dǎo) call 和 bind5.1 call真的只需要一行前面已經(jīng)提過(guò)myCall 可以基于 myApply 直接實(shí)現(xiàn)Function.prototype.myCall function (context, ...rest) { return this.myApply(context, rest); };這里能成立的原因不復(fù)雜myApply 的第二個(gè)參數(shù)是數(shù)組而 rest 收集到的正好是真數(shù)組。你甚至可以認(rèn)為 call 就是 apply 的“語(yǔ)法糖”——只是把“整理數(shù)組”這一步交給了調(diào)用者。實(shí)測(cè)一下const obj { base: 10 }; function add(a, b) { return this.base a b; } console.log(add.myCall(obj, 1, 2)); // 13 console.log(add.myApply(obj, [1, 2])); // 13兩個(gè)結(jié)果都是 13。這就很有意思你已經(jīng)在這篇文章里一口氣手寫(xiě)了兩道高頻面試題。5.2 bind理解原理不追求當(dāng)場(chǎng)手寫(xiě)完整版bind 和 call/apply 的最大區(qū)別是不立即執(zhí)行它返回一個(gè)新函數(shù)等調(diào)用時(shí)再把參數(shù)合并好傳進(jìn)去。最小實(shí)現(xiàn)長(zhǎng)這樣Function.prototype.myBind function (context, ...presetArgs) { const fn this; return function (...laterArgs) { return fn.apply(context, presetArgs.concat(laterArgs)); }; };可以看到bind 內(nèi)部調(diào)用了 apply 完成最終調(diào)用。所以如果你把 apply 吃透了bind 的思路也就不難理解。但要注意完整版 bind 還涉及“返回的函數(shù)可以被 new 調(diào)用此時(shí) this 綁定失效”以及原型鏈處理復(fù)雜度明顯更高。面試一般不會(huì)要求現(xiàn)場(chǎng)完整手寫(xiě) bind能把最小實(shí)現(xiàn)講明白、說(shuō)出和 apply 的關(guān)系已經(jīng)足夠說(shuō)明你掌握了這個(gè)家族的核心機(jī)制。5.3 自己驗(yàn)證 myApply一套可以直接跑的測(cè)試用例寫(xiě)完之后怎么確認(rèn)自己沒(méi)寫(xiě)錯(cuò)我建議至少跑一遍下面這些用例// 1. 基本功能this 綁定 數(shù)組傳參 const obj { base: 10 }; function add(a, b) { return this.base a b; } console.log(add.myApply(obj, [1, 2])); // 13 // 2. 不傳第二個(gè)參數(shù)不報(bào)錯(cuò)等價(jià)于無(wú)參調(diào)用 function getContext() { return this; } console.log(getContext.myApply(obj) obj); // true // 3. null / undefined context非嚴(yán)格模式下 this 指向全局對(duì)象 function checkThis() { return typeof this; } console.log(checkThis.myApply(null)); // object console.log(checkThis.myApply(undefined)); // object // 4. 類(lèi)數(shù)組對(duì)象作為第二個(gè)參數(shù) console.log(add.myApply(obj, { 0: 1, 1: 2, length: 2 })); // 13 // 5. 原函數(shù)拋錯(cuò)時(shí)臨時(shí)屬性仍然清干凈 function boom() { throw new Error(boom); } try { boom.myApply(obj, []); } catch (e) {} console.log(Object.getOwnPropertySymbols(obj)); // [] // 6. 非函數(shù)調(diào)用 myApply 時(shí)拋 TypeError const notFunc {}; try { notFunc.myApply(obj, []); } catch (e) { console.log(e instanceof TypeError); // true }這六組用例基本覆蓋了核心行為、邊界條件和異常清理。你在本地環(huán)境跑一遍全綠就說(shuō)明這個(gè)手寫(xiě)版立住了。最后分享一個(gè)我反復(fù)跟人講過(guò)的體會(huì)手寫(xiě) apply 這件事最大的收獲不是“記住了一段模板代碼”而是你因此把 this 綁定的直覺(jué)練出來(lái)了。我現(xiàn)在看代碼看到fn()就知道 this 大概率是全局或 undefined看到obj.fn()就知道 this 必然是 obj這些都是當(dāng)年反復(fù)手寫(xiě) call/apply 之后才自然形成的條件反射。建議你在跑完上面測(cè)試之后順手用同樣的思路把手寫(xiě) call、手寫(xiě) bind 也各實(shí)現(xiàn)一遍原理類(lèi)知識(shí)早晚會(huì)從“背過(guò)答案”變成“長(zhǎng)在身上”。