前端面試前臨時(shí)抱佛腳背了五十道題結(jié)果面試官隨口一句“那你講講閉包到底閉的是什么”就把人問懵了——這種場(chǎng)面我見過太多次了。作為在前端崗位干了些年、也坐在面試官這側(cè)篩過不少候選人的人說實(shí)話90%的面試翻車都不是死在框架 API 上而是死在 JS 語言本身的這幾個(gè)核心點(diǎn)上。誰也沒真統(tǒng)計(jì)過“90%”這個(gè)數(shù)字但以我觀察到的面試記錄來看反復(fù)出現(xiàn)的大概率就是這 12 個(gè)點(diǎn)作用域與閉包、this 指向、原型鏈與繼承、手寫 new、事件循環(huán)、Promise 與異常處理、setTimeout 的坑、深淺拷貝、數(shù)組方法、字符串與 URL 處理、事件委托、防抖與節(jié)流。這篇文章我按底層邏輯把它們歸成六組來聊每組解決一類問題。你會(huì)發(fā)現(xiàn)很多題表面問法不同本質(zhì)上考的卻是同一套東西作用域鏈、調(diào)用棧、對(duì)象模型、事件機(jī)制。下面直接開講。1. 作用域、閉包與 this 指向面試第一階段最常翻車的三道連環(huán)題1.1 作用域鏈與閉包從計(jì)數(shù)器題看本質(zhì)先看一段幾乎所有前端都寫過的代碼function createCounter() { let count 0; return function () { count; return count; }; } const counter createCounter(); console.log(counter()); // 1 console.log(counter()); // 2面試官問你“為什么兩次執(zhí)行結(jié)果不一樣count 明明在函數(shù)內(nèi)部怎么沒被重置”這就是閉包在起作用。要解釋清楚得分三層說。第一JS 里作用域分全局、函數(shù)、塊級(jí)三種而且變量的可訪問范圍在代碼編寫時(shí)就確定了這叫詞法作用域。第二函數(shù) createCounter 執(zhí)行時(shí)內(nèi)部 return 的函數(shù)雖然沒立即執(zhí)行但它把 createCounter 的整個(gè)作用域鏈“打包帶走”了。第三count 變量并不會(huì)在 createCounter 執(zhí)行結(jié)束后被銷毀因?yàn)檫€有另一個(gè)函數(shù)在引用它這個(gè)引用關(guān)系讓 count 一直活在內(nèi)存里。我面試時(shí)特別喜歡追問一句“你覺得閉包是閉住了什么”很多人答“閉住了變量”其實(shí)更準(zhǔn)確的說法是“閉住了對(duì)變量所在詞法環(huán)境的引用”。同一份作用域可以被多個(gè)閉包共享這才是后面 for 循環(huán)坑的根源。比如這個(gè)經(jīng)典題for (var i 0; i 3; i) { setTimeout(function () { console.log(i); }, 0); } // 輸出3 3 3var 聲明的 i 是函數(shù)級(jí)變量三個(gè) setTimeout 回調(diào)閉住的不是 i 的值而是同一個(gè) i 的引用。等到定時(shí)器執(zhí)行時(shí)循環(huán)早跑完了i 已經(jīng)變成 3。解決方案不外乎兩種把 var 改成 let讓每一輪循環(huán)生成獨(dú)立的塊級(jí)作用域或者用 IIFE 把 i 作為參數(shù)傳進(jìn)一個(gè)獨(dú)立的函數(shù)作用域。閉包的實(shí)際應(yīng)用場(chǎng)景比很多人想象的多防抖節(jié)流函數(shù)內(nèi)部的狀態(tài)保存、模塊化隔離私有變量、組件庫(kù)中讓數(shù)據(jù)對(duì)外只讀等。面試官讓你“寫一個(gè)實(shí)際使用的閉包場(chǎng)景”最穩(wěn)妥的回答不是背定義而是直接寫一個(gè)防抖或節(jié)流函數(shù)把閉包對(duì)持久狀態(tài)的控制展示出來。還有一個(gè)追問頻率很高的點(diǎn)“閉包會(huì)不會(huì)造成內(nèi)存泄漏”答案是“不合理使用才會(huì)”。閉包真正持有的不是變量值而是整個(gè)作用域鏈如果你不小心把一個(gè)超大對(duì)象掛在閉包能訪問的位置該對(duì)象就一直不會(huì)被回收。我之前排查過一個(gè)后臺(tái)系統(tǒng)卡頓的問題最后定位就是一個(gè)可以無限滾動(dòng)的表格里事件回調(diào)閉包了整行數(shù)據(jù)對(duì)象表格數(shù)據(jù)列表在內(nèi)存里越攢越多。1.2 this 指向的四條綁定規(guī)則與箭頭函數(shù)的例外this 是秋招面試第二高發(fā)區(qū)的重災(zāi)區(qū)。很多人喜歡背口訣“誰調(diào)用指向誰”這口訣只對(duì)了一半真正標(biāo)準(zhǔn)說法是“看調(diào)用位置的綁定模式”一共有四種。默認(rèn)綁定函數(shù)直接調(diào)用this 指向全局對(duì)象嚴(yán)格模式下是 undefined。function say() { console.log(this); } say(); // window嚴(yán)格模式下是 undefined隱式綁定通過對(duì)象屬性調(diào)用時(shí)this 指向該對(duì)象。這里有個(gè)經(jīng)典陷阱——把方法拆出來單獨(dú)調(diào)用綁定就丟了const obj { name: obj, getName: function () { console.log(this.name); }, }; const fn obj.getName; fn(); // undefined因?yàn)榇藭r(shí)是普通函數(shù)調(diào)用 obj.getName(); // obj符合隱式綁定顯式綁定call、apply、bind 都能強(qiáng)制指定 this。區(qū)別在于 call 和 apply 會(huì)立即執(zhí)行函數(shù)bind 只返回一個(gè)綁定了 this 的新函數(shù)。new 綁定構(gòu)造函數(shù)通過 new 調(diào)用時(shí)this 指向新建的對(duì)象優(yōu)先級(jí)最高。四條規(guī)則的優(yōu)先級(jí)順序是new 顯式綁定 隱式綁定 默認(rèn)綁定。箭頭函數(shù)是最大的例外它自己沒有 thisthis 是在定義時(shí)從外層作用域繼承的。這個(gè)特性非常容易被組合進(jìn)面試題里const obj { name: obj, wait: function () { setTimeout(function () { console.log(this.name); // undefined普通函數(shù)有自己的 this }, 0); }, waitArrow: function () { setTimeout(() { console.log(this.name); // obj箭頭函數(shù)從 waitArrow 的詞法作用域拿到 this }, 0); }, }; obj.wait(); obj.waitArrow();為什么普通函數(shù)會(huì)輸出 undefined因?yàn)?setTimeout 內(nèi)部對(duì)回調(diào)是直接調(diào)用this 落入默認(rèn)綁定瀏覽器環(huán)境下指向 windowwindow.name 不是 obj。箭頭函數(shù)則是“我不管 setTimeout 怎么調(diào)我我的 this 在定義時(shí)就固定為外層 waitArrow 的 this”。React 類組件里事件回調(diào)丟失 this 的經(jīng)典坑本質(zhì)就是隱式綁定丟失解法也是箭頭函數(shù)或 bind。1.3 面試官追問模式閉包 this 的組合輸出題單獨(dú)的閉包題和單獨(dú)的 this 題都難不倒大家組合起來就容易翻車。比如我面試時(shí)經(jīng)常給候選人出這樣的題目let count 0; const obj { count: 10, fn: function () { let count 100; const inner () { console.log(this.count, count); }; inner(); }, }; obj.fn(); // 輸出什么先看箭頭函數(shù) inner它沒有自己的 thisthis 從定義它的外層函數(shù) fn 那里繼承。fn 由 obj.fn() 調(diào)用是隱式綁定所以 fn 的 this 是 obj于是 this.count 是 10。再看 count 變量inner 自身沒有局部變量 count沿作用域鏈向上找先找到 fn 里的 let count 100所以輸出 100。結(jié)果就是 10 100。這道題一次性考了三個(gè)知識(shí)點(diǎn)箭頭函數(shù) this 的詞法傳導(dǎo)、隱式綁定規(guī)則、作用域鏈查找順序。多數(shù)背答案的候選人會(huì)在這里卡住因?yàn)樗麄兛赡馨?this 和變量查找混為一談?wù)`以為 inner 里訪問 this.count 也應(yīng)該先看 fn 內(nèi)部。我的建議是準(zhǔn)備面試時(shí)多做這種組合型的輸出題并且養(yǎng)成“先畫作用域鏈再畫 this 綁定最后再執(zhí)行”的習(xí)慣而不是憑直覺寫答案。另一道常見組合題是“構(gòu)造函數(shù)里 setTimeout 里用 function 和箭頭函數(shù)補(bǔ) this”本質(zhì)上和圖里的邏輯一樣只是換了一層殼。2. 原型鏈、繼承與 ES6 class背熟和真正理解的差別2.1 原型鏈的本質(zhì)與 instanceof 的實(shí)現(xiàn)原理JS 的對(duì)象繼承機(jī)制和 Java 的類繼承完全是兩碼事。每個(gè)普通函數(shù)都有 prototype 屬性這個(gè)屬性指向一個(gè)對(duì)象通過該函數(shù) new 出來的實(shí)例會(huì)有一個(gè)內(nèi)部原型指針指向這個(gè) prototype 對(duì)象。這個(gè)指針在瀏覽器里可以通過proto訪問但更規(guī)范的說法是 Object.getPrototypeOf。所謂原型鏈就是從一個(gè)對(duì)象出發(fā)沿proto一路往上找的過程。比如數(shù)組 arrarr.proto是 Array.prototypeArray.prototype.proto是 Object.prototypeObject.prototype.proto是 null鏈條結(jié)束。instanceof 運(yùn)算符的底層邏輯就是沿原型鏈找a instanceof B等價(jià)于“B.prototype 是否出現(xiàn)在 a 的整條原型鏈上”。我經(jīng)常讓候選人手寫一個(gè) instanceof目的是看他是否理解原型鏈function myInstanceof(left, right) { let proto Object.getPrototypeOf(left); while (proto) { if (proto right.prototype) return true; proto Object.getPrototypeOf(proto); } return false; }注意一個(gè)很容易鉆進(jìn)去的彎數(shù)組實(shí)例直接測(cè) instanceof Object 也會(huì)返回 true因?yàn)殒湕l沒斷能一路摸到 Object.prototype。這恰恰說明 JS 里“一切皆對(duì)象”不是一句口號(hào)而是由原型鏈這個(gè)物理結(jié)構(gòu)保證的。hasOwnProperty 和 in 是原型鏈上一組容易混的兄弟hasOwnProperty 只看自身屬性in 會(huì)連原型鏈上的屬性一起算。面試題經(jīng)常問“for...in 遍歷對(duì)象如何只拿自身屬性”答案就是配合 hasOwnProperty 做過濾。Object.keys 則天生只返回自身可枚舉屬性不需要過濾。2.2 組合繼承、寄生組合繼承與 class 語法糖原型鏈繼承本身有個(gè)大坑就是引用類型屬性會(huì)被所有實(shí)例共享。經(jīng)典例子function Parent() { this.list []; } function Child() {} Child.prototype new Parent(); const a new Child(); a.list.push(1); const b new Child(); console.log(b.list); // [1]被影響了這題考過無數(shù)次原因在于 Child.prototype 指向了一個(gè) Parent 實(shí)例而 list 是掛在實(shí)例上的屬性被所有 Child 實(shí)例共享。解決方案是組合繼承function Parent(name) { this.name name; this.list []; } Parent.prototype.say function () { console.log(this.name); }; function Child(name, age) { Parent.call(this, name); this.age age; } Child.prototype new Parent(); Child.prototype.constructor Child;組合繼承的問題在于 Parent 被調(diào)用了兩次一次在 Parent.call(this)一次在 new Parent() 作為 Child.prototype。第一次把屬性放到了子實(shí)例上第二次把屬性放到了原型上。結(jié)果子實(shí)例同時(shí)擁有自己的屬性原型上還殘留一份共享的屬性副本雖然訪問沒問題但冗余了?，F(xiàn)代面試題更喜歡問寄生組合繼承因?yàn)樗乃悸泛?class extends 編譯出來的 ES5 結(jié)果非常接近function Child(name, age) { Parent.call(this, name); this.age age; } Child.prototype Object.create(Parent.prototype); Child.prototype.constructor Child;Object.create(Parent.prototype) 創(chuàng)建一個(gè)以父類原型為原型的新對(duì)象子類實(shí)例沿原型鏈既能找到 Parent.prototype 的方法又不會(huì)觸發(fā)父構(gòu)造函數(shù)去生成冗余屬性。class 的 extends、super、static 關(guān)鍵字本質(zhì)都是這套原型邏輯之上的語法糖而不是什么新機(jī)制。我在面試時(shí)一般不會(huì)問“你背一下寄生組合繼承的代碼”而是直接給一段 class 繼承代碼問它在 ES5 環(huán)境下大概被編譯成什么結(jié)構(gòu)。能答出“子類原型通過 Object.create 關(guān)聯(lián)父類原型實(shí)例屬性通過 super() 里的函數(shù)調(diào)用完成”這句話就說明真的把原型鏈和繼承打通了。2.3 手寫 new 的過程一道很多人卡住的送分題手寫 new 是面試?yán)锉稽c(diǎn)單率極高的題因?yàn)樗芡瑫r(shí)考察 this、原型鏈和對(duì)象操作三類知識(shí)。new 一個(gè)構(gòu)造函數(shù)發(fā)生的四件事分別是創(chuàng)建一個(gè)空對(duì)象把空對(duì)象內(nèi)部原型指向構(gòu)造函數(shù)的 prototype讓構(gòu)造函數(shù)內(nèi)部的 this 指向這個(gè)新對(duì)象并執(zhí)行構(gòu)造函數(shù)根據(jù)構(gòu)造函數(shù)返回值類型決定最終返回什么。編碼實(shí)現(xiàn)function myNew(fn, ...args) { const obj Object.create(fn.prototype); const result fn.apply(obj, args); return result (typeof result object || typeof result function) ? result : obj; }最后一步是關(guān)鍵。JavaScript 語言規(guī)范規(guī)定如果構(gòu)造函數(shù)返回的是對(duì)象類型new 表達(dá)式會(huì)返回那個(gè)對(duì)象如果返回的是基本類型或沒有返回值則忽略它返回創(chuàng)建出來的 obj。這一條也直接解釋了為什么構(gòu)造函數(shù)里如果主動(dòng) return 一個(gè)對(duì)象會(huì)導(dǎo)致 new 出來的實(shí)例不是你的預(yù)期對(duì)象。還有一種追問方式是“如果不寫 new直接用構(gòu)造函數(shù)會(huì)怎樣”。比如function Person(name) { this.name name; } Person(張三); // 在嚴(yán)格模式下 this 是 undefined直接報(bào)錯(cuò)不寫 new 時(shí)Person 就是普通函數(shù)調(diào)用this 落入默認(rèn)綁定。嚴(yán)格模式下是 undefined試圖給 undefined 掛 name 屬性直接拋錯(cuò)非嚴(yán)格模式下 this 指向 windowname 會(huì)被掛到 window 上。這種題在團(tuán)隊(duì)代碼 review 場(chǎng)景里很常見所以答案要背得清清楚楚構(gòu)造函數(shù)必須用 new 調(diào)用或者內(nèi)部加 instanceof 判斷做保護(hù)。3. 異步編程事件循環(huán)、Promise 與 setTimeout 的那些坑3.1 宏任務(wù)與微任務(wù)的執(zhí)行順序現(xiàn)在幾乎每面必問事件循環(huán)。我怎么把這事講得讓新手也能記住一句話先同步再微任務(wù)最后宏任務(wù)整個(gè)隊(duì)列一輪一輪跑。JS 是單線程語言同一時(shí)刻主線程只能干一件事。遇到 setTimeout、DOM 事件回調(diào)這些異步任務(wù)時(shí)瀏覽器會(huì)先把它們交給對(duì)應(yīng)的線程或隊(duì)列等到當(dāng)前調(diào)用棧空了再回來處理。但異步任務(wù)內(nèi)部還要分類Promise.then、queueMicrotask 這類屬于微任務(wù)優(yōu)先級(jí)比 setTimeout、事件回調(diào)這類宏任務(wù)更高。執(zhí)行規(guī)則是每一次宏任務(wù)跑完后先把當(dāng)前所有微任務(wù)隊(duì)列清空再取下一個(gè)宏任務(wù)。經(jīng)典輸出題console.log(script start); setTimeout(() { console.log(setTimeout); }, 0); Promise.resolve() .then(() { console.log(promise 1); }) .then(() { console.log(promise 2); }); console.log(script end);輸出順序是 script start、script end、promise 1、promise 2、setTimeout。processconsole.log 是同步任務(wù)按順序執(zhí)行setTimeout 被放進(jìn)了宏任務(wù)隊(duì)列Promise.then 進(jìn)入了微任務(wù)隊(duì)列主線程同步代碼跑完調(diào)用棧清空瀏覽器開始清空微任務(wù)隊(duì)列promise 1 和 promise 2 依次輸出微任務(wù)清空后才從宏任務(wù)隊(duì)列里取出 setTimeout。還有一個(gè)小細(xì)節(jié)promise 2 的 then 是在 promise 1 的回調(diào)執(zhí)行中才注冊(cè)進(jìn)去的但因?yàn)樗€是微任務(wù)仍然排在宏任務(wù)前面。關(guān)于 async/await 也有個(gè)高頻誤區(qū)。請(qǐng)記住await 后面的代碼相當(dāng)于被包進(jìn)了 Promise.then 的回調(diào)里屬于微任務(wù)。所謂“await 會(huì)讓出線程”不是指去執(zhí)行宏任務(wù)而是指先把控制權(quán)還給事件循環(huán)讓微任務(wù)有機(jī)會(huì)先行。小技巧面試被問輸出順序時(shí)直接拿“同步代碼 → 整條微任務(wù)鏈 → 下一個(gè)宏任務(wù)”這個(gè)順序推演比死記例子穩(wěn)得多。我還建議自己動(dòng)手跑幾個(gè) Node 環(huán)境的輸出題注意 Node 的 process.nextTick 比 Promise.then 還優(yōu)先這是瀏覽器環(huán)境沒有的差異也是 Node 方向面試的潛在考點(diǎn)。3.2 Promise 鏈?zhǔn)秸{(diào)用與異常處理Promise 的本質(zhì)是一個(gè)狀態(tài)機(jī)只有三種狀態(tài)pending、fulfilled、rejected。狀態(tài)一旦從 pending 轉(zhuǎn)換出去就不可逆這是設(shè)計(jì)上最重要的特性也是“為什么 Promise 只能被 resolve 一次”的答案。then 方法永遠(yuǎn)返回一個(gè)新的 Promise這是鏈?zhǔn)秸{(diào)用的基礎(chǔ)。如果你在 then 里返回一個(gè)普通值它會(huì)作為下一個(gè) then 的入?yún)⑷绻惴祷匾粋€(gè) Promise下一個(gè) then 會(huì)等待這個(gè) Promise 落定后再取它的值。返回值穿透是很多新人的盲區(qū)Promise.resolve(a) .then() .then((v) console.log(v)); // a中間的 then 沒有傳回調(diào)值會(huì)被原樣透?jìng)鞯较乱粋€(gè) then。這在小冊(cè)子題里出現(xiàn)過不止一次。異常處理是另一個(gè)高頻考點(diǎn)。常見的誤解是“加了 catch 就萬事大吉”其實(shí)要看你把 catch 放在哪里Promise.reject(err);注意一個(gè)沒有被捕獲的 rejected Promise 在某些環(huán)境下會(huì)直接報(bào) UnhandledPromiseRejection。更隱蔽的是鏈?zhǔn)嚼锏?catch 位置promise .then(fn1) .catch(fn2) .then(fn3);如果 fn1 拋錯(cuò)fn2 能捕獲到并且捕獲后返回 undefined后續(xù)的 fn3 依然會(huì)執(zhí)行。如果 fn2 也拋錯(cuò)那么 fn3 不會(huì)執(zhí)行。這跟 try/catch 的“捕獲后繼續(xù)往下走”直覺是一致的但很多人面試時(shí)會(huì)答錯(cuò)。Promise 靜態(tài)方法里Promise.all 是“全部成功才算成功一個(gè)失敗立即失敗”Promise.race 是“第一個(gè)落定的結(jié)果獲勝不管成功失敗”Promise.allSettled 是“等所有都落定逐個(gè)返回狀態(tài)和值永遠(yuǎn)不 reject”。實(shí)際開發(fā)中并行請(qǐng)求用 all超時(shí)控制用 race批量上報(bào)不關(guān)心成敗用 allSettled這個(gè)選擇能直接體現(xiàn)工程經(jīng)驗(yàn)。手寫 Promise.all 也是常見題核心邏輯實(shí)現(xiàn)一下function promiseAll(promises) { return new Promise((resolve, reject) { const result []; let count 0; promises.forEach((p, index) { Promise.resolve(p) .then((value) { result[index] value; count; if (count promises.length) resolve(result); }) .catch(reject); }); }); }注意兩點(diǎn)不能用數(shù)組 push 直接收集結(jié)果因?yàn)椴l(fā)完成順序不確定必須按 index 占位空數(shù)組要直接 resolve否則永遠(yuǎn)卡在 pending。3.3 setTimeout 返回值與異步陷阱setTimeout 這個(gè) API 表面簡(jiǎn)單但面試能挖出的坑一點(diǎn)都不少。第一個(gè)是返回值問題瀏覽器環(huán)境下setTimeout 返回一個(gè)正整數(shù) ID從 1 開始遞增同一頁面中不會(huì)重復(fù)用于傳給 clearTimeout 取消定時(shí)器。所以熱搜里“setTimeout 返回值的范圍有 0 存在么”的答案是瀏覽器環(huán)境中 ID 從 1 開始取循環(huán)回繞前不會(huì)有 0一般情況下拿不到 0。Node.js 環(huán)境則不太一樣返回的是一個(gè) Timeout 對(duì)象不是數(shù)字這也是區(qū)分瀏覽器和 Node 環(huán)境的一個(gè)細(xì)節(jié)點(diǎn)。第二個(gè)高頻坑是 setTimeout(0) 并不等于立即執(zhí)行。它的真實(shí)含義是“當(dāng)前任務(wù)執(zhí)行完后再把這個(gè)回調(diào)推進(jìn)任務(wù)隊(duì)列”只要當(dāng)前調(diào)用棧里還有同步代碼它就得排隊(duì)。把 setTimeout 和前面的事件循環(huán)放在一起理解這就是“最少等 4ms”這個(gè)民間說法的來源——瀏覽器對(duì)嵌套層級(jí)過高的 setTimeout 還會(huì)做額外的時(shí)間鉗制。第三個(gè)坑是大延時(shí)問題。setTimeout 的延時(shí)參數(shù)最大臨界值大約是 2147483647ms差不多是 24.8 天。如果超過這個(gè)值定時(shí)器會(huì)立刻執(zhí)行相當(dāng)于延時(shí)失效。我確實(shí)在業(yè)務(wù)中見過有人給一個(gè)自動(dòng)刷新邏輯寫了 30 天的定時(shí)器結(jié)果 setTimeout 沒按預(yù)期工作排查了半天才想到是這個(gè)原因。第四個(gè)是 this 陷阱和回調(diào)陷阱這在業(yè)務(wù)代碼中經(jīng)常踩。寫法類似const obj { name: obj, init() { setTimeout(function () { console.log(this.name); // undefined }, 100); }, }; obj.init();普通函數(shù)在 setTimeout 內(nèi)部調(diào)用時(shí)this 指向全局對(duì)象或 undefined。解決方法和之前說的一樣用箭頭函數(shù)或提前 const self this。工程上我還有一個(gè)習(xí)慣需要在組件銷毀時(shí)清理的定時(shí)器務(wù)必把 id 存起來離開頁面時(shí) clearTimeout。否則定時(shí)器回調(diào)里如果引用了 DOM 或組件狀態(tài)輕則內(nèi)存泄漏重則報(bào)錯(cuò)。高頻地創(chuàng)建 setTimeintervals 而不清理是我排查線上內(nèi)存問題時(shí)見過最多的模式之一。4. 數(shù)據(jù)操作能力深淺拷貝、數(shù)組高階方法與字符串實(shí)用判斷4.1 深拷貝為什么 JSON.parse(JSON.stringify()) 只能拿來湊合如果面試官問深淺拷貝最常見的回答是“淺拷貝只拷貝第一層深拷貝全部層用 JSON.parse(JSON.stringify()) 就行了”。這個(gè)答案最多拿及格分因?yàn)?JSON 方案有一堆你未必意識(shí)到的坑。先看代碼const obj { name: test, age: 30, address: { city: beijing, }, fn: function () {}, date: new Date(), regex: /test/, symbol: Symbol(s), }; const jsonCopy JSON.parse(JSON.stringify(obj)); console.log(jsonCopy); // fn、symbol、regex 丟失date 變成字符串JSON.stringify 在遇到 undefined、函數(shù)、Symbol 時(shí)會(huì)把它們丟棄Date 會(huì)被轉(zhuǎn)成字符串正則會(huì)被轉(zhuǎn)成空對(duì)象NaN 和 Infinity 會(huì)變成 null。最致命的是循環(huán)引用一構(gòu)造對(duì)象就拋 “Converting circular structure to JSON” 錯(cuò)誤。面試官讓你手寫深拷貝時(shí)核心點(diǎn)在于實(shí)現(xiàn)“遞歸 處理多數(shù)據(jù)類型 解決循環(huán)引用”。一個(gè)能拿高分的版本function deepClone(target, map new WeakMap()) { if (target null || typeof target ! object) return target; if (map.has(target)) return map.get(target); const result Array.isArray(target) ? [] : {}; map.set(target, result); for (const key of Reflect.ownKeys(target)) { result[key] deepClone(target[key], map); } return result; }用 WeakMap 記錄拷貝過的源對(duì)象遇到同一個(gè)引用直接取回既解決了循環(huán)引用也保證了“兩個(gè)屬性指向同一個(gè)對(duì)象時(shí)拷貝后仍然指向同一個(gè)對(duì)象”的結(jié)構(gòu)一致性?，F(xiàn)代瀏覽器也提供了原生 structuredClone API它支持 ArrayBuffer、Map、Set、Date 等類型也能處理循環(huán)引用。但面試時(shí)手寫是為了看你是否理解對(duì)象模型不要拿“我用 structuredClone”當(dāng)萬能答案。順帶說說深淺拷貝的邊界使用場(chǎng)景不同。淺拷貝適合那些只有一層數(shù)據(jù)的配置對(duì)象展開運(yùn)算符就夠了深拷貝適合復(fù)雜嵌套的響應(yīng)式數(shù)據(jù)。但深拷貝有成本能淺則淺是我做性能優(yōu)化時(shí)的一個(gè)重要原則。4.2 數(shù)組高頻方法map、filter、find、reduce 及手寫實(shí)現(xiàn)數(shù)組方法是前端面試?yán)镄詢r(jià)比最高的一類題它能很直接地區(qū)分“會(huì)寫業(yè)務(wù)”和“理解數(shù)據(jù)處理”兩種候選人。mmp、filter、find、reduce 這四個(gè)是出鏡率最高的面試官一般先問區(qū)別再讓你手寫。map 和 forEach 的區(qū)別是第一道關(guān)卡。map 返回一個(gè)新數(shù)組forEach 返回 undefinedmap 適合做數(shù)據(jù)變形forEach 適合執(zhí)行副作用。很多人面試時(shí)還會(huì)把 forEach 當(dāng)遍歷萬能工具其實(shí)當(dāng)你想中途退出循環(huán)時(shí)forEach 是做不到的它沒有 break 機(jī)制。正確的做法是用 some 返回 true 來提前結(jié)束或者直接改 for 循環(huán)。reduce 是地基。手寫一個(gè) reduce 能看懂你對(duì)數(shù)組協(xié)議、初始值、空數(shù)組邊界是否清楚Array.prototype.myReduce function (callback, initialValue) { const arr this; let acc initialValue; let startIndex 0; if (initialValue undefined) { if (arr.length 0) { throw new TypeError(Reduce of empty array with no initial value); } acc arr[0]; startIndex 1; } for (let i startIndex; i arr.length; i) { acc callback(acc, arr[i], i, arr); } return acc; };注意兩個(gè)考察點(diǎn)第一不傳初始值時(shí)reduce 會(huì)把數(shù)組第一個(gè)元素作為初始值并從下標(biāo) 1 開始遍歷第二數(shù)組為空且不傳初始值時(shí)reduce 會(huì)直接拋 TypeError這也是模型里規(guī)定的行為。實(shí)際面試題里reduce 常見的應(yīng)用有數(shù)組求和、統(tǒng)計(jì)次數(shù)、扁平化嵌套數(shù)組、按某字段分組、map 和 filter 組合實(shí)現(xiàn)等。我建議你熟練到可以閉眼寫出來這些場(chǎng)景因?yàn)楹芏喙久嬖嚥恢粏栆槐?reduce面試官會(huì)順著你寫的代碼繼續(xù)追問“如果數(shù)組有空洞呢”。JS 的數(shù)組方法對(duì)稀疏數(shù)組的處理各有不同map 會(huì)保留空洞forEach 會(huì)跳過空洞reduce 同樣跳過。能把這個(gè)差異講清楚屬于加分項(xiàng)。4.3 字符串處理包含判斷、忽略大小寫、URL 驗(yàn)證熱搜詞里“js 判斷字符串是否包含”和“js 忽略大小寫”出現(xiàn)頻率非常高說明即使是基礎(chǔ) API在實(shí)際業(yè)務(wù)里也存在大量使用誤區(qū)。判斷包含最常用的四個(gè)方法indexOf、includes、startsWith、endsWith。用表格看得更清楚方法判斷語義返回值大小寫敏感indexOf(a)查找子串位置找到返回下標(biāo)否則 -1是includes(a)是否包含子串booleantrue / false是startsWith(a)是否以子串開頭boolean是endsWith(a)是否以子串結(jié)尾boolean是很多新人還用 indexOf ! -1 判斷包含其實(shí) includes 就是更語義化的替代還不會(huì)出現(xiàn)“indexOf 找不到時(shí)返回 -1但 -1 也是 falsy 之外的數(shù)導(dǎo)致條件判斷出錯(cuò)”的混淆。忽略大小寫判斷的核心原則是“統(tǒng)一比對(duì)標(biāo)準(zhǔn)”。最簡(jiǎn)單可靠的做法是比對(duì)前把兩個(gè)字符串都轉(zhuǎn)成大寫或小寫function includesIgnoreCase(str, search) { return str.toUpperCase().includes(search.toUpperCase()); }不建議用 toLowerCase 還是 toUpperCase 糾結(jié)只要兩邊一致就行。如果想做更精細(xì)的規(guī)則比如只忽略 ASCII 大小寫而保留非英文字符差異可以用正則加 /i 標(biāo)志/hello/i.test(str)。但正則方案要小心特殊字符轉(zhuǎn)義日常場(chǎng)景統(tǒng)一大小寫是更穩(wěn)妥的選擇。URL 驗(yàn)證是另一個(gè)高頻需求。最省事的方案是用 URL 構(gòu)造函數(shù)function isValidUrl(url) { try { new URL(url); return true; } catch { return false; } }new URL 能在解析失敗時(shí)拋錯(cuò)所以用 try/catch 包一層就能完成基本校驗(yàn)。但要注意它比較寬松像http://這樣有協(xié)議頭但不完整的地址也能通過解析。正則方案更可控比如常見的return /^https?:\/\/([\w-]\.)[\w-]/i.test(url)。實(shí)際業(yè)務(wù)中我一般按需求拆只想判斷“是不是合法 URL”用 URL 構(gòu)造函數(shù)想要“必須是 http/https 且?guī)в蛎庇谜齽t。5. 高頻業(yè)務(wù)場(chǎng)景事件委托、防抖節(jié)流實(shí)戰(zhàn)細(xì)節(jié)5.1 事件委托從冒泡聊到動(dòng)態(tài)列表性能優(yōu)化事件機(jī)制在 JS 里分兩個(gè)方向理解傳播三階段和綁定方式。標(biāo)準(zhǔn)規(guī)定事件傳播分捕獲、目標(biāo)、冒泡三個(gè)過程捕獲是從 window 往下走到目標(biāo)元素冒泡是從目標(biāo)元素往上走回到 window。addEventListener 的第三個(gè)參數(shù)設(shè)為 true 就會(huì)讓回調(diào)在捕獲階段觸發(fā)設(shè)為 false 則在冒泡階段觸發(fā)默認(rèn)是 false。事件委托利用的就是冒泡機(jī)制與其給子元素逐個(gè)綁定事件不如把事件綁定在它們的共同父元素上讓事件通過冒泡到達(dá)父元素再統(tǒng)一處理。典型場(chǎng)景是動(dòng)態(tài)列表const list document.getElementById(list); list.addEventListener(click, (e) { const target e.target.closest(li); if (!target) return; console.log(target.dataset.id); });e.target 是真正點(diǎn)擊的元素e.currentTarget 是綁定事件的元素也就是父容器。很多人把兩者混用導(dǎo)致事件委托里判斷失效。還有一個(gè)高頻細(xì)節(jié)children 節(jié)點(diǎn)是動(dòng)態(tài)渲染的如果給每個(gè)子節(jié)點(diǎn)都綁定事件每次增刪都要重新綁定用委托就只要綁定父節(jié)點(diǎn)一次新節(jié)點(diǎn)自動(dòng)繼承事件性能和代碼維護(hù)成本都更優(yōu)。也別忘了 JS 里有些事件根本不冒泡。scroll、resize、mouseenter、blur 這類事件無法通過委托方式統(tǒng)一處理。如果遇到用 mouseover 替代 mouseenter 的舊代碼還要額外處理“子元素進(jìn)出導(dǎo)致誤觸發(fā)”的問題。這個(gè)點(diǎn)我在業(yè)務(wù) review 時(shí)經(jīng)常強(qiáng)調(diào)。順便說一句React 17 之前的事件系統(tǒng)是在根容器上統(tǒng)一委托的17 之后改為向原生事件對(duì)齊委托點(diǎn)從 document 換到了 root 容器。面試如果聊到 React 事件機(jī)制能補(bǔ)上這段演變會(huì)很明顯體現(xiàn)出你讀過源碼或者至少跟蹤過技術(shù)動(dòng)態(tài)。5.2 防抖與節(jié)流原理、場(chǎng)景、手寫與區(qū)別防抖和節(jié)流是面試手寫題里命中率最高的兩道之一而且經(jīng)常放在一起問因?yàn)閮烧叨忌婕案哳l觸發(fā)場(chǎng)景的頻控。先用一個(gè)生活中的類比區(qū)分防抖像電梯關(guān)門。有人進(jìn)來電梯門就重新打開直到最后一個(gè)人進(jìn)來后等了一會(huì)兒再關(guān)。節(jié)流像水龍頭滴水。不管水流多大滴水頻率固定每過一段時(shí)間必然會(huì)滴下一滴。防抖是“高頻觸發(fā)中只執(zhí)行最后一次”。典型的場(chǎng)景是搜索框輸入用戶連續(xù)打字時(shí)不需要每敲一個(gè)字就請(qǐng)求一次接口而是在用戶停下來后的 300ms 內(nèi)再發(fā)請(qǐng)求。實(shí)現(xiàn)如下function debounce(fn, wait, immediate) { let timer null; return function (...args) { const callNow immediate !timer; clearTimeout(timer); timer setTimeout(() { timer null; if (!immediate) fn.apply(this, args); }, wait); if (callNow) fn.apply(this, args); }; }immediate 參數(shù)控制“首次觸發(fā)是否立即執(zhí)行”。如果你在做提交按鈕防重復(fù)點(diǎn)擊immediate 為 true 更合適第一次點(diǎn)擊立即執(zhí)行后續(xù)點(diǎn)擊被攔截直到 wait 過后才恢復(fù)。節(jié)流是“固定時(shí)間間隔內(nèi)只執(zhí)行一次”保證最小執(zhí)行頻率。常見場(chǎng)景是滾動(dòng)加載、拖拽、縮放。實(shí)現(xiàn)也有兩種模式// 時(shí)間戳版 function throttle(fn, delay) { let last 0; return function (...args) { const now Date.now(); if (now - last delay) { last now; fn.apply(this, args); } }; }時(shí)間戳版保證首次執(zhí)行能立即生效但最后一次觸發(fā)可能被“吃掉”定時(shí)器版則會(huì)在最后一次補(bǔ)執(zhí)行兩者各有取舍。業(yè)務(wù)中做滾動(dòng)加載一般用時(shí)間戳版做動(dòng)畫末尾收尾則定時(shí)器版更好。兩個(gè)版本都建議親手寫一遍因?yàn)槊嬖嚬俸芸赡軙?huì)追問“節(jié)流結(jié)束前最后一次觸發(fā)你們?cè)趺刺幚怼?。手寫防抖?jié)流時(shí)最容易翻車的地方有兩個(gè)一是忘記在內(nèi)部函數(shù)里用 fn.apply(this, args) 保證上下文否則外部通過對(duì)象調(diào)用時(shí)會(huì)丟失 this二是事件對(duì)象 e 的透?jìng)魅绻话褏?shù)轉(zhuǎn)發(fā)給 fn拿不到 event 對(duì)象做 stopPropagation 之類操作。這兩點(diǎn)我在代碼 review 里幾乎每次都能看到。5.3 ES Module 與 CommonJS模塊化的核心差異模塊化雖然不在上面 12 個(gè)點(diǎn)清單里卻是任何現(xiàn)代前端項(xiàng)目都繞不開的面試題。ES Module 和 CommonJS 的差異本質(zhì)上體現(xiàn)了兩種設(shè)計(jì)哲學(xué)靜態(tài) vs 動(dòng)態(tài)。ES Module 的 import/export 是靜態(tài)的寫在代碼頂層在解析階段就能確定依賴關(guān)系所以工具可以在打包時(shí)做 tree shaking刪除沒被引用的導(dǎo)出。CommonJS 的 require 是動(dòng)態(tài)的可以在 if 條件里寫 require也可以把 require 寫在函數(shù)內(nèi)部因?yàn)樗沁\(yùn)行時(shí)執(zhí)行的函數(shù)調(diào)用。這就是“為什么 import 不能寫在條件塊里而 require 可以”的原因。依賴循環(huán)的問題也有體現(xiàn)。CommonJS 遇到循環(huán)依賴時(shí)某個(gè)模塊可能拿到另一個(gè)模塊未執(zhí)行完的部分導(dǎo)出ES Module 則通過“活綁定”的方式在模塊間保持引用有效性最終執(zhí)行時(shí)拿到的值可能已更新。這個(gè)差異在前端筆試題里反復(fù)被考到給一個(gè)循環(huán)依賴代碼執(zhí)行并輸出運(yùn)行時(shí)結(jié)果。想保證答對(duì)關(guān)鍵是要能畫出模塊的執(zhí)行順序先執(zhí)行誰、打印誰、exports 里此刻有誰。Tree shaking 還有一個(gè)日常相關(guān)的體現(xiàn)從組件庫(kù)里按需引入。像 antd 這類大型組件庫(kù)用import { Button } from antd配合打包器的 tree shaking只打包用到的部分如果項(xiàng)目用了 CommonJS 格式的第三方庫(kù)tree shaking 往往失效。這也是為什么現(xiàn)在新庫(kù)都優(yōu)先輸出 ESM 產(chǎn)物。面試官如果追問“那 Node.js 現(xiàn)在支持 ESM 嗎”答案是支持但 package.json 的 type 字段和 .mjs / .cjs 后綴決定了解析方式Node 環(huán)境下兩者可以共存。能把“為什么需要 babel 和打包器”到“Node 原生如何處理這兩種規(guī)范”串起來講一遍就是一道很完整的模塊化大通關(guān)。6. 加分題新語法邊界、內(nèi)存管理與工程細(xì)節(jié)6.1 可選鏈、空值合并、解構(gòu)與展開的實(shí)戰(zhàn)邊界ES6 新語法也是面試常青樹但考的是使用邊界不是你見過哪些 API。這幾個(gè)最容易踩坑的點(diǎn)值得單獨(dú)拿出來說?？蛇x鏈操作符 ?. 很香但用多了會(huì)產(chǎn)生“防御性編程副作用”。比如user?.address?.city一旦 user 為 null 就不會(huì)拋錯(cuò)直接返回 undefined。問題在于本該暴露的 bug 也被吞掉了。比如調(diào)用一個(gè)對(duì)象的方法合理預(yù)期對(duì)象一定存在如果它不存在應(yīng)該立刻報(bào)錯(cuò)而不是讓后面所有邏輯靜默失效。我在團(tuán)隊(duì)里定的規(guī)則是外部不可控?cái)?shù)據(jù)接口返回值、localStorage 解析結(jié)果可以用 ?.內(nèi)部業(yè)務(wù)代碼里不要濫用。空值合并運(yùn)算符 ?? 和 || 的區(qū)別是面試官非常愛挖的點(diǎn)。||對(duì) falsy 值生效也就是遇到 0、、NaN、false 都取右邊??只對(duì) null 和 undefined 生效。比如const a 0; console.log(a || 10); // 10 console.log(a ?? 10); // 0業(yè)務(wù)中如果你有一個(gè)“count 為 0 時(shí)也要展示 0”的需求用||做兜底就會(huì)把 0 替換成默認(rèn)值這就是 bug 源。寫出“dont use || when you mean ??”這個(gè)意識(shí)比記住語法更重要。解構(gòu)賦值默認(rèn)值有隱藏陷阱默認(rèn)值只在屬性值是 undefined 時(shí)生效null 不會(huì)被默認(rèn)值覆蓋const { name 默認(rèn) } { name: null }; console.log(name); // null不是 默認(rèn)展開運(yùn)算符的邊界是“它只淺拷貝一層”。{ ...obj }復(fù)制完第一層后嵌套對(duì)象依然是同一引用。這正好呼應(yīng)深淺拷貝那節(jié)deep clone 的需求永遠(yuǎn)不能被展開運(yùn)算符替代。很多新人寫完const newObj { ...oldObj }就以為 newObj 完全獨(dú)立了結(jié)果修改 newObj.a.b 時(shí)把 oldObj.a.b 也改了。6.2 垃圾回收與內(nèi)存泄漏低頻但能拉開差距的題這一組題出現(xiàn)頻率不高但一旦出現(xiàn)面試官往往想通過它篩掉多數(shù)人。JS 引擎的垃圾回收主流算法是標(biāo)記清除從根對(duì)象出發(fā)遍歷所有可達(dá)對(duì)象打上標(biāo)記剩下的沒標(biāo)記的就是垃圾統(tǒng)一回收。老一代瀏覽器里的引用計(jì)數(shù)算法已經(jīng)被淘汰因?yàn)闆]法解決循環(huán)引用。面試常見的四個(gè)內(nèi)存泄漏場(chǎng)景每個(gè)都很具體第一個(gè)是隱式全局變量。在函數(shù)內(nèi)給未聲明變量賦值它會(huì)變成全局變量永遠(yuǎn)留在 window 上。嚴(yán)格模式能防住這個(gè)。第二個(gè)是定時(shí)器未清理。setInterval 的回調(diào)里如果引用了大量數(shù)據(jù)又沒在生命周期銷毀時(shí) clearInterval數(shù)據(jù)會(huì)一直駐留。第三個(gè)是事件監(jiān)聽器泄漏。SPA 頁面頻繁銷毀和掛載組件如果組件銷毀時(shí)沒有 removeEventListener舊組件就通過事件回調(diào)被長(zhǎng)期持有。第四個(gè)是分離的 DOM 節(jié)點(diǎn)。你移除了一個(gè) DOM 節(jié)點(diǎn)但 JS 變量還持有它的引用節(jié)點(diǎn)就無法被回收。怎么規(guī)避記憶一個(gè)簡(jiǎn)單原則誰創(chuàng)建、誰回收。在 useEffect 里設(shè)置的定時(shí)器和綁定的監(jiān)聽器都在清理函數(shù)里取消解綁。閉包里的臨時(shí)數(shù)據(jù)只要不再被引用就能釋放問題往往出在“引用沒斷”而不是“閉包本身有毒”。WeakMap 和 WeakSet 的存在本來就是為了解決內(nèi)存回收問題WeakMap 的 key 是弱引用不阻止垃圾回收。做對(duì)象級(jí)的存取時(shí)比如給 DOM 元素掛緩存數(shù)據(jù)用 WeakMap 能避免緩存數(shù)據(jù)跟著元素一起殘留。最后提一個(gè)和性能相關(guān)的延伸場(chǎng)景前端用 Web Worker 做大文件上傳其實(shí)就是把耗時(shí)任務(wù)放到獨(dú)立線程避免主線程阻塞。這個(gè)方向在面試中經(jīng)常被作為“異步優(yōu)化”的進(jìn)階題背后邏輯還是事件循環(huán)和內(nèi)存管理那套體系主線程空閑才能保證 UI 流暢復(fù)雜的計(jì)算任務(wù)外包給 Worker數(shù)據(jù)交換通過 postMessage 完成。把這套思路講清楚比背十個(gè) API 更能證明你的工程基礎(chǔ)扎實(shí)。真到面試的時(shí)候我自己的習(xí)慣是每題先想“這次面試官真正想問的是什么”再組織回答。閉包問的是引用關(guān)系this 問的是調(diào)用點(diǎn)Promise 問的是任務(wù)隊(duì)列原型鏈問的是對(duì)象模型。把這幾個(gè)底層模型在腦子里串成一張網(wǎng)比硬背一百道題都有用。這也是我平時(shí)帶新人時(shí)最常強(qiáng)調(diào)的一點(diǎn)——碰到不會(huì)的題別慌先把它往已懂的原理上靠從根上推理八九不離十。