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