“前端筆試”這四個(gè)字對(duì)于2020年那會(huì)兒的應(yīng)屆生來(lái)說(shuō)基本等同于“八股文面試”的同義詞。但其實(shí)回過(guò)頭看像樂(lè)信這種體量、業(yè)務(wù)又偏金融科技的公司前端筆試題反而不是純粹考背書(shū)的它更看重你能不能把手上的JS和CSS用明白能不能用工程化的思路去解決一個(gè)看似簡(jiǎn)單的頁(yè)面問(wèn)題。我花了點(diǎn)時(shí)間把這類校招筆試題的常見(jiàn)套路、出題邏輯以及背后真正想考察的能力點(diǎn)重新梳理了一遍結(jié)合我自己當(dāng)年刷題和后來(lái)面人的經(jīng)驗(yàn)寫(xiě)成這篇詳細(xì)點(diǎn)的拆解。無(wú)論是正在準(zhǔn)備校招的應(yīng)屆生還是想查漏補(bǔ)缺的初級(jí)前端希望這份復(fù)盤能幫到你。1. 筆試想考什么從樂(lè)信的招聘畫(huà)像倒推考點(diǎn)很多同學(xué)準(zhǔn)備筆試有個(gè)誤區(qū)拿到題就刷刷完就忘完全沒(méi)去想過(guò)“出題人到底想考察什么”。校招筆試題不像社招那樣直接考察項(xiàng)目經(jīng)驗(yàn)和解決復(fù)雜問(wèn)題的能力它更像一個(gè)漏斗先篩掉基礎(chǔ)不扎實(shí)、代碼習(xí)慣差、思維模式有硬傷的人。樂(lè)信2020年前端筆試的題型分布其實(shí)很能反映當(dāng)時(shí)主流互聯(lián)網(wǎng)公司對(duì)校招生的期望畫(huà)像。從整體結(jié)構(gòu)來(lái)看這套筆試題可以拆成四大塊計(jì)算機(jī)基礎(chǔ)與網(wǎng)絡(luò)、JavaScript語(yǔ)言特性與手寫(xiě)代碼、瀏覽器與前端工程化、框架應(yīng)用與場(chǎng)景設(shè)計(jì)。其中JavaScript和網(wǎng)絡(luò)是占分最大的兩塊。為什么這兩塊占大頭因?yàn)榍岸诉@個(gè)崗位往上走的瓶頸從來(lái)不是CSS寫(xiě)得多漂亮而是你對(duì)語(yǔ)言本身的理解深度以及對(duì)瀏覽器這個(gè)運(yùn)行環(huán)境的掌控能力。尤其是JavaScript校招筆試題特別喜歡在“原型鏈”“異步”“閉包”“作用域”這幾個(gè)經(jīng)典考點(diǎn)上做文章。這些東西不是背下來(lái)就行而是要通過(guò)寫(xiě)代碼的方式考察你能否跳出API層面看到語(yǔ)言設(shè)計(jì)背后的邏輯。再往深一層說(shuō)樂(lè)信的業(yè)務(wù)是金融科技前端要處理大量表單、交易狀態(tài)、數(shù)據(jù)可視化圖表。所以筆試?yán)镆欢〞?huì)出現(xiàn)跟“異步流程控制”“數(shù)據(jù)不可變”“性能優(yōu)化”“邊界情況處理”相關(guān)的題目。這些考點(diǎn)不是單純?yōu)榱穗y為你而是為了模擬真實(shí)業(yè)務(wù)里可能出現(xiàn)的狀態(tài)管理混亂、接口競(jìng)態(tài)、大數(shù)據(jù)量渲染卡頓等問(wèn)題。還有個(gè)容易被忽略的點(diǎn)就是筆試題的“時(shí)間密度”。2020年這套題我記得總時(shí)長(zhǎng)大概在90到120分鐘之間題量卻不小。如果你對(duì)某個(gè)知識(shí)點(diǎn)不熟在那兒卡了10分鐘后面的題基本就寫(xiě)不完了。這就考察了一個(gè)很重要的能力在有限時(shí)間內(nèi)如何合理分配精力先拿穩(wěn)拿分、再攻難題。很多同學(xué)栽在筆試題上不是不會(huì)做而是時(shí)間沒(méi)分配好前面一道手寫(xiě)題寫(xiě)了40分鐘后面兩道框架題直接放棄。所以準(zhǔn)備這類筆試題我的建議是不要只刷題要“帶題復(fù)習(xí)”?？吹揭坏李}先想它對(duì)應(yīng)哪個(gè)知識(shí)模塊再想這個(gè)模塊在真實(shí)業(yè)務(wù)里解決什么問(wèn)題最后才是寫(xiě)代碼。這樣才能把知識(shí)串成體系而不是碎片。2. JavaScript異步與手寫(xiě)代碼最容易被拉開(kāi)差距的板塊JavaScript的異步和手寫(xiě)代碼是前端筆試?yán)锢_(kāi)差距的關(guān)鍵。有的同學(xué)能拿滿分有的同學(xué)看起來(lái)什么都懂一動(dòng)手寫(xiě)就漏洞百出。這一章我挑幾個(gè)樂(lè)信筆試?yán)锍霈F(xiàn)頻率最高、也最容易出錯(cuò)的類型詳細(xì)講一下解題思路和踩坑點(diǎn)。2.1 事件循環(huán)與宏任務(wù)/微任務(wù)的執(zhí)行順序這幾乎是前端筆試必考的一類題樂(lè)信2020年也不例外。題目通常給出一段包含setTimeout、Promise、async/await的代碼讓你寫(xiě)出輸出順序。這類題的核心考點(diǎn)就是瀏覽器的事件循環(huán)機(jī)制。你得徹底理解一個(gè)事實(shí)JavaScript是單線程的但瀏覽器不是。JS主線程執(zhí)行代碼時(shí)遇到異步任務(wù)不會(huì)傻等而是會(huì)把它們交給瀏覽器的其他線程去處理等結(jié)果準(zhǔn)備好之后再把回調(diào)放進(jìn)任務(wù)隊(duì)列。主線程空閑了再?gòu)娜蝿?wù)隊(duì)列里取任務(wù)執(zhí)行。任務(wù)隊(duì)列又分宏任務(wù)macrotask和微任務(wù)microtask。宏任務(wù)setTimeout、setInterval、I/O、UI渲染、事件回調(diào)微任務(wù)Promise.then/catch/finally、MutationObserver、async/await后面的代碼執(zhí)行順序的規(guī)則是先執(zhí)行一個(gè)宏任務(wù)整個(gè)script其實(shí)也算一個(gè)宏任務(wù)執(zhí)行完這個(gè)宏任務(wù)之后會(huì)清空當(dāng)前所有的微任務(wù)。等微任務(wù)清空了如果需要渲染就渲染然后再?gòu)暮耆蝿?wù)隊(duì)列里取下一個(gè)宏任務(wù)執(zhí)行。只看這句話可能還是會(huì)亂我拆個(gè)例子console.log(1); setTimeout(() { console.log(2); Promise.resolve().then(() { console.log(3); }); }, 0); Promise.resolve() .then(() { console.log(4); setTimeout(() { console.log(5); }, 0); }) .then(() { console.log(6); }); console.log(7); // 輸出順序是什么解這類題有個(gè)固定的思維路徑第一步執(zhí)行同步代碼輸出1和7。 第二步分析異步任務(wù)setTimeout回調(diào)進(jìn)宏任務(wù)隊(duì)列記為macro1Promise.resolve().then()進(jìn)微任務(wù)隊(duì)列記為micro1第三步同步代碼執(zhí)行完清空微任務(wù)隊(duì)列先執(zhí)行micro1輸出4然后micro1的then鏈把6也加入微任務(wù)隊(duì)列繼續(xù)執(zhí)行輸出6。同時(shí)micro1內(nèi)部又注冊(cè)了一個(gè)setTimeout進(jìn)宏任務(wù)隊(duì)列記為macro2第四步微任務(wù)清空后取第一個(gè)宏任務(wù)macro1執(zhí)行輸出2它內(nèi)部的Promise.resolve().then()創(chuàng)建了微任務(wù)micro2執(zhí)行輸出3第五步宏任務(wù)macro1執(zhí)行完再清空微任務(wù)micro2已執(zhí)行完然后取下一個(gè)宏任務(wù)macro2輸出5最終輸出順序就是1, 7, 4, 6, 2, 3, 5。這里最容易錯(cuò)的地方是把micro1內(nèi)部注冊(cè)的setTimeout當(dāng)成宏任務(wù)macro1之后的處理。實(shí)際上微任務(wù)執(zhí)行是“全部清空”的你在微任務(wù)里往宏任務(wù)隊(duì)列塞任務(wù)得等當(dāng)前所有微任務(wù)清空之后才輪到它。筆試題里還有一個(gè)常見(jiàn)變體就是async/awaitasync function async1() { console.log(async1 start); await async2(); console.log(async1 end); } async function async2() { console.log(async2); } console.log(script start); async1(); console.log(script end);這里只要記住await的語(yǔ)義await后面的代碼相當(dāng)于被放到了.then()里也就是微任務(wù)。所以上面代碼輸出是script start async1 start async2 script end async1 endasync1 end放在最后因?yàn)閍wait等待async2()執(zhí)行完但async2()本身是同步執(zhí)行完的執(zhí)行完async2之后async1函數(shù)體剩余部分就被推遲到微任務(wù)里了。實(shí)戰(zhàn)小貼士遇到async/await的題先把a(bǔ)wait翻譯成Promise.then再執(zhí)行就不容易錯(cuò)。2.2 手寫(xiě)Promise.all / 手寫(xiě)防抖節(jié)流手寫(xiě)題是筆試題里的重頭戲。樂(lè)信2020年筆試?yán)锍霈F(xiàn)過(guò)手寫(xiě)Promise.all還有手寫(xiě)防抖函數(shù)。這類題看似簡(jiǎn)單但要在紙上寫(xiě)得又快又對(duì)還是需要平時(shí)練過(guò)。先看手寫(xiě)Promise.all。這道題的核心考點(diǎn)是你對(duì)Promise構(gòu)造器、resolve/reject的調(diào)用時(shí)機(jī)、以及異步任務(wù)收集的理解。function myPromiseAll(promises) { return new Promise((resolve, reject) { if (!Array.isArray(promises)) { throw new TypeError(promises must be an array); } const results new Array(promises.length); let count 0; if (promises.length 0) { resolve(results); return; } promises.forEach((promise, index) { Promise.resolve(promise) .then((value) { results[index] value; count 1; if (count promises.length) { resolve(results); } }) .catch((err) { reject(err); }); }); }); }這里有三個(gè)容易踩的坑第一空數(shù)組的情況。Promise.all([])返回的應(yīng)該是一個(gè)已經(jīng)resolve的 Promise結(jié)果是空數(shù)組。很多人寫(xiě)的時(shí)候沒(méi)做這個(gè)判斷直接進(jìn)去循環(huán)count 永遠(yuǎn)是0永遠(yuǎn)不會(huì)觸發(fā) resolve整個(gè) Promise 就掛起了。第二Promise.resolve(promise)這一步很關(guān)鍵。因?yàn)閭魅氲臄?shù)組里可能混有普通值而不是 Promise 實(shí)例。Promise.all的特性是會(huì)把數(shù)組里的非 Promise 值直接當(dāng)作已決議的值處理所以包一層Promise.resolve是最穩(wěn)妥的做法。第三結(jié)果的順序必須和輸入順序一致而不是完成的先后順序。所以不能用results.push(value)而是要用results[index] value這種方式按索引賦值。如果你用 push一旦前面某個(gè) Promise 卡住后面先完成的就會(huì)占錯(cuò)位置。再看手寫(xiě)防抖函數(shù)。防抖的核心思路是在事件被觸發(fā)后延遲wait毫秒再執(zhí)行回調(diào)如果在這段時(shí)間內(nèi)又被觸發(fā)就重新計(jì)時(shí)。典型的應(yīng)用場(chǎng)景是搜索框輸入、窗口 resize。function debounce(fn, wait 300, immediate false) { let timer null; let isInvoked false; return function (...args) { const context this; if (timer) { clearTimeout(timer); } if (immediate !isInvoked) { fn.apply(context, args); isInvoked true; return; } timer setTimeout(() { fn.apply(context, args); isInvoked false; timer null; }, wait); }; }這里有個(gè)容易被忽略的點(diǎn)this的綁定。如果你在debounce內(nèi)部直接調(diào)用fn(...args)那么this就會(huì)指向undefined嚴(yán)格模式下或全局對(duì)象非嚴(yán)格模式下。所以必須用fn.apply(context, args)把原函數(shù)的this傳進(jìn)去。這是閉包加高階函數(shù)題目里最常見(jiàn)的考點(diǎn)。至于節(jié)流throttle核心思路是控制執(zhí)行頻率保證在一段時(shí)間內(nèi)至少執(zhí)行一次。跟防抖的區(qū)別在于防抖是“最后一擊”節(jié)流是“勻速釋放”。筆試?yán)镞@兩者常被拿來(lái)對(duì)比考概念手寫(xiě)的話用時(shí)間戳版本比較不容易出錯(cuò)function throttle(fn, interval 300) { let lastTime 0; return function (...args) { const context this; const now Date.now(); if (now - lastTime interval) { fn.apply(context, args); lastTime now; } }; }時(shí)間戳版的缺點(diǎn)是第一次會(huì)立即執(zhí)行最后一次觸發(fā)不會(huì)執(zhí)行因?yàn)殚g隔不夠就丟掉了。面試時(shí)如果能答出這個(gè)缺點(diǎn)并補(bǔ)充一個(gè)定時(shí)器版本的實(shí)現(xiàn)會(huì)是個(gè)很好的加分點(diǎn)。2.3 深拷貝與類型判斷手寫(xiě)深拷貝也是筆試?？?。樂(lè)信2020年筆試?yán)锍霈F(xiàn)過(guò)一道拷對(duì)象數(shù)據(jù)、要求不改變?cè)磾?shù)據(jù)的題本質(zhì)上就是在考察深拷貝。深拷貝的考點(diǎn)其實(shí)分三層第一層基礎(chǔ)版本能處理對(duì)象和數(shù)組用遞歸實(shí)現(xiàn)第二層考慮循環(huán)引用用WeakMap或Map保存已拷貝的對(duì)象第三層考慮Date、RegExp、Function、Map、Set等特殊類型筆試一般不會(huì)要求非常完整的版本但至少要做到安全處理循環(huán)引用否則一遇到循環(huán)引用就爆棧。function deepClone(target, map new WeakMap()) { if (target null || typeof target ! object) { return target; } if (target instanceof Date) { return new Date(target); } if (target instanceof RegExp) { return new RegExp(target.source, target.flags); } if (map.has(target)) { return map.get(target); } const cloneTarget Array.isArray(target) ? [] : {}; map.set(target, cloneTarget); Reflect.ownKeys(target).forEach((key) { cloneTarget[key] deepClone(target[key], map); }); return cloneTarget; }這里用Reflect.ownKeys而不是Object.keys是為了連不可枚舉屬性和 Symbol 鍵也能拷貝到。但筆試如果用這個(gè)方法需要對(duì)Reflect比較熟悉所以平時(shí)得練過(guò)。關(guān)于類型判斷有一個(gè)經(jīng)久不衰的面試題typeof和Object.prototype.toString的區(qū)別。筆試?yán)锟赡軙?huì)給你一堆變量讓你判斷類型。typeof只有幾個(gè)返回值undefined、boolean、string、number、bigint、symbol、object、function。它的局限是null返回object數(shù)組、對(duì)象、正則都返回object沒(méi)法區(qū)分具體類型。最穩(wěn)妥的方式是Object.prototype.toString.call(target)它返回類似[object Array]、[object Date]這樣的字符串。這個(gè)方法基本能區(qū)分所有內(nèi)置類型。筆試?yán)锶绻枰_判斷類型建議封裝一個(gè)getType函數(shù)function getType(target) { return Object.prototype.toString.call(target).slice(8, -1).toLowerCase(); }slice(8, -1)會(huì)去掉[object 前綴和最后的]得到Array、Date這樣的字符串。這個(gè)函數(shù)在手寫(xiě)深拷貝的時(shí)候非常實(shí)用可以作為類型分支判斷的依據(jù)。3. HTTP與瀏覽器緩存看似基礎(chǔ)實(shí)則細(xì)節(jié)密集如果說(shuō) JavaScript 手寫(xiě)題是拉開(kāi)分?jǐn)?shù)差距的“主觀題”那 HTTP 和瀏覽器相關(guān)的題就是決定你能不能過(guò)線的“客觀題”。這部分分?jǐn)?shù)拿起來(lái)相對(duì)容易因?yàn)樗目键c(diǎn)非常固定。但失分點(diǎn)也很集中主要是概念混淆比如把緩存策略的Cache-Control和Expires搞混把ETag和Last-Modified的驗(yàn)證邏輯搞反。3.1 強(qiáng)緩存與協(xié)商緩存的完整鏈路關(guān)于瀏覽器緩存只要記住一句話強(qiáng)緩存是“不問(wèn)你直接用”協(xié)商緩存是“問(wèn)一下再用”。這個(gè)“問(wèn)一下”就是發(fā)一次 HTTP 請(qǐng)求帶上驗(yàn)證字段讓服務(wù)器判斷資源有沒(méi)有變。強(qiáng)緩存相關(guān)的頭部主要是Expires和Cache-Control。Expires是 HTTP/1.0 時(shí)代的產(chǎn)物是一個(gè)絕對(duì)時(shí)間。但因?yàn)榉?wù)器時(shí)間和客戶端時(shí)間可能不一致所以現(xiàn)在基本不用了。Cache-Control是 HTTP/1.1 引入的用相對(duì)時(shí)間max-age來(lái)控制比如Cache-Control: max-age3600表示資源在3600秒內(nèi)可以直接用緩存不用發(fā)請(qǐng)求。如果Cache-Control和Expires同時(shí)存在Cache-Control的優(yōu)先級(jí)更高。協(xié)商緩存的核心機(jī)制是當(dāng)強(qiáng)緩存過(guò)期后瀏覽器帶著驗(yàn)證字段去問(wèn)服務(wù)器資源有沒(méi)有更新服務(wù)器根據(jù)字段判斷Last-Modified/If-Modified-Since服務(wù)器返回資源最后修改的時(shí)間下次請(qǐng)求時(shí)瀏覽器把這個(gè)時(shí)間放到If-Modified-Since頭里服務(wù)器比對(duì)。如果資源沒(méi)變返回304 Not Modified瀏覽器繼續(xù)用緩存。ETag/If-None-MatchETag是資源內(nèi)容生成的唯一標(biāo)識(shí)通常是對(duì)文件內(nèi)容做哈希資源變了標(biāo)識(shí)就變。瀏覽器下次請(qǐng)求時(shí)帶上If-None-Match服務(wù)器比對(duì)。如果一致返回304。這兩個(gè)字段有個(gè)優(yōu)先級(jí)問(wèn)題ETag的優(yōu)先級(jí)高于Last-Modified。因?yàn)長(zhǎng)ast-Modified只能精確到秒如果同一秒內(nèi)文件被修改了但沒(méi)有內(nèi)容變化或者修改后又改回去了Last-Modified就沒(méi)法精確感知而ETag是內(nèi)容哈希更準(zhǔn)確。筆試題里常見(jiàn)的坑是讓你設(shè)計(jì)一套緩存策略適合一個(gè)版本化資源比如app.js?v1.0.0和一個(gè)非版本化資源比如index.html。正確的做法是版本化資源使用強(qiáng)緩存設(shè)置超長(zhǎng)的max-age比如一年。因?yàn)槲募麕1.0.0只要版本變了URL 就變了永遠(yuǎn)不會(huì)命中舊緩存。index.html使用協(xié)商緩存或者設(shè)置成no-cache。因?yàn)?HTML 是入口文件如果它被強(qiáng)緩存了用戶可能永遠(yuǎn)拿不到最新的 JS/CSS 引用。所以 HTML 必須每次“問(wèn)一下”服務(wù)器拿到最新的資源引用。這個(gè)思路在真實(shí)業(yè)務(wù)里非常重要。當(dāng)年踩過(guò)的坑是上線后用戶打開(kāi)頁(yè)面還是舊版本排查半天發(fā)現(xiàn)index.html被設(shè)置了Cache-Control: max-age86400瀏覽器走強(qiáng)緩存壓根沒(méi)有問(wèn)服務(wù)器要新頁(yè)面。3.2 從URL輸入到頁(yè)面展示中間發(fā)生了什么幾乎是前端筆試必考的開(kāi)放題。樂(lè)信2020年筆試也有一道類似的不過(guò)問(wèn)得更具體從輸入U(xiǎn)RL到頁(yè)面展示中間經(jīng)過(guò)了哪些步驟哪些步驟可能成為性能瓶頸這道題的標(biāo)準(zhǔn)鏈路是URL 解析判斷是搜索詞還是合法 URL補(bǔ)全協(xié)議頭DNS 解析把域名解析成 IP。這里涉及瀏覽器 DNS 緩存、操作系統(tǒng) DNS 緩存、本地 hosts 文件、LDNS 遞歸查詢建立 TCP 連接三次握手確認(rèn)雙方收發(fā)能力正常發(fā)送 HTTP 請(qǐng)求瀏覽器發(fā)起請(qǐng)求可能帶緩存驗(yàn)證走協(xié)商緩存服務(wù)器處理請(qǐng)求并返回涉及負(fù)載均衡、后端處理、資源組裝瀏覽器接收響應(yīng)處理狀態(tài)碼、響應(yīng)頭觸發(fā)緩存策略解析 HTML 構(gòu)建 DOM 樹(shù)解析 CSS 構(gòu)建 CSSOM 樹(shù)渲染合并 DOM 和 CSSOM 成渲染樹(shù)進(jìn)行布局Layout和繪制Paint加載子資源遇到script、link、img等標(biāo)簽繼續(xù)發(fā)起請(qǐng)求筆試答這道題盡量別只寫(xiě)骨架最好在幾個(gè)關(guān)鍵節(jié)點(diǎn)加上一句“為什么”。比如在 DNS 解析那里說(shuō)明為什么用 CDN 可以加速——因?yàn)?CDN 廠商會(huì)在 DNS 層面做智能解析讓你就近訪問(wèn)節(jié)點(diǎn)在 TCP 連接那里說(shuō)明為什么 HTTP/2 有優(yōu)勢(shì)——因?yàn)樗梢栽谝粋€(gè) TCP 連接上多路復(fù)用多個(gè)請(qǐng)求減少了多次連接的開(kāi)銷。樂(lè)信這道題還有個(gè)追問(wèn)哪些步驟可能造成性能瓶頸這個(gè)可以從多個(gè)層面回答DNS 解析慢DNS 服務(wù)器響應(yīng)慢、沒(méi)開(kāi) DNS 預(yù)解析TCP 連接慢網(wǎng)絡(luò)環(huán)境差、TCP 握手延遲HTTP/2 多路復(fù)用可以緩解服務(wù)器處理慢后端接口響應(yīng)慢、沒(méi)有做緩存資源下載慢資源體積大、沒(méi)有開(kāi)啟 CDN、沒(méi)有做壓縮渲染阻塞render-blocking的 CSS/JS 太多、腳本過(guò)大導(dǎo)致主線程長(zhǎng)時(shí)間占用這個(gè)問(wèn)題答得好不好其實(shí)能看出你平時(shí)是真的關(guān)心過(guò)頁(yè)面性能還是只在面試前背過(guò)一道題。3.3 跨域同源策略下的常見(jiàn)解決思路跨域是前端筆試?yán)锒悴婚_(kāi)的考點(diǎn)。因?yàn)榍昂蠖朔蛛x架構(gòu)下幾乎每個(gè)項(xiàng)目都會(huì)遇到。先理解為什么會(huì)有跨域?yàn)g覽器的同源策略協(xié)議、域名、端口三者一致才算同源限制了頁(yè)面腳本不能訪問(wèn)不同源的資源。這個(gè)限制是瀏覽器實(shí)現(xiàn)的不是服務(wù)器實(shí)現(xiàn)的。所以跨域這個(gè)問(wèn)題核心思路是“讓服務(wù)器配合瀏覽器放行”或者“繞過(guò)瀏覽器的限制”。常見(jiàn)的解決方式CORS跨域資源共享最正統(tǒng)的方案。服務(wù)器在響應(yīng)頭里加Access-Control-Allow-Origin來(lái)允許指定域名訪問(wèn)。如果要帶 cookie還得加Access-Control-Allow-Credentials: true并且不能把Allow-Origin設(shè)為*必須指定明確的域名。JSONP利用script標(biāo)簽不受同源策略限制這個(gè)特性動(dòng)態(tài)創(chuàng)建script標(biāo)簽加載一個(gè)帶回調(diào)參數(shù)的外部腳本。這是老方案只支持 GET 請(qǐng)求現(xiàn)在用得少了但筆試?yán)锝?jīng)?？荚怼ginx 反向代理把前端請(qǐng)求代理到后端瀏覽器只跟同源的 Nginx 通信由 Nginx 轉(zhuǎn)發(fā)請(qǐng)求。這是生產(chǎn)環(huán)境里最常用、最穩(wěn)定的方案。WebSocket不受同源策略限制。postMessage用于 iframe 頁(yè)面之間的跨域通信。筆試的經(jīng)典題目是寫(xiě)一個(gè) JSONP 的實(shí)現(xiàn)或者描述 JSONP 的執(zhí)行流程。function jsonp(url, params, callback) { return new Promise((resolve, reject) { const script document.createElement(script); const random callback_${Date.now()}_${Math.random().toString(16).slice(2)}; window[random] function (data) { resolve(data); delete window[random]; script.remove(); }; const queryString Object.keys(params) .map((key) ${encodeURIComponent(key)}${encodeURIComponent(params[key])}) .join(); const callbackKey callback || callback; script.src ${url}?${queryString}${callbackKey}${random}; script.onerror function () { reject(new Error(JSONP request failed)); delete window[random]; script.remove(); }; document.body.appendChild(script); }); }這里有個(gè)很重要的細(xì)節(jié)回調(diào)函數(shù)名不能寫(xiě)死要用動(dòng)態(tài)生成的隨機(jī)名。因?yàn)槿绻麅蓚€(gè) JSONP 請(qǐng)求同時(shí)進(jìn)行都用了同一個(gè)回調(diào)名后面注冊(cè)的會(huì)覆蓋前面的導(dǎo)致第一個(gè)請(qǐng)求永遠(yuǎn)等不到回調(diào)。這是一個(gè)很經(jīng)典的邊界問(wèn)題。4. 框架與組件設(shè)計(jì)從使用到原理的認(rèn)知升級(jí)前端校招筆試的另一個(gè)重頭戲是框架題。樂(lè)信2020年筆試的時(shí)候Vue 2.x 還是絕對(duì)的主流React 16.x 也有一批項(xiàng)目在用所以筆試題基本圍繞這兩個(gè)框架出。這部分題不像手寫(xiě)題那樣需要寫(xiě)大量代碼而是更側(cè)重考察“你用了這個(gè)框架這么久有沒(méi)有想過(guò)它底層是怎么工作的”。4.1 響應(yīng)式原理Object.defineProperty 與 Proxy 的對(duì)比Vue 2.x 的響應(yīng)式原理是 Object.definePropertyVue 3.x 換成了 Proxy。筆試題目通常會(huì)問(wèn)Vue 2 的響應(yīng)式原理是什么有哪些局限Vue 3 用 Proxy 解決了什么。Vue 2 的核心邏輯是在初始化時(shí)遍歷 data 對(duì)象的每個(gè)屬性用 Object.defineProperty 把它們?nèi)哭D(zhuǎn)換成 getter/setter。當(dāng)組件讀取某個(gè)屬性時(shí)觸發(fā) getter把當(dāng)前 watcher 收集進(jìn)依賴?yán)镆蕾囀占?dāng)屬性被修改時(shí)觸發(fā) setter通知之前收集的 watcher 去更新派發(fā)更新。這個(gè)機(jī)制的局限在于新增屬性不是響應(yīng)式的。因?yàn)?Object.defineProperty 是在屬性已經(jīng)存在的情況下做攔截的你后來(lái)給對(duì)象新增一個(gè)屬性它壓根沒(méi)有被 defineProperty 處理過(guò)所以修改它不會(huì)觸發(fā)更新。Vue 2 的解決辦法是Vue.set或this.$set來(lái)手動(dòng)把新屬性變成響應(yīng)式。數(shù)組的某些操作無(wú)法被攔截。直接通過(guò)索引修改數(shù)組元素比如this.list[0] xxx是觸發(fā)不了 setter 的。Vue 2 只好重寫(xiě)了數(shù)組的push、pop、shift、unshift、splice、sort、reverse這些方法讓它們操作完之后再手動(dòng)通知更新。需要遞歸遍歷所有屬性初始化性能有損耗。對(duì)象嵌套越深遞歸成本越高。Object.defineProperty 本身只能攔截屬性不能攔截整個(gè)對(duì)象所以刪除屬性的操作也無(wú)法被感知。Vue 3 用 Proxy 重寫(xiě)了整個(gè)響應(yīng)式系統(tǒng)。Proxy 可以代理整個(gè)對(duì)象不管是新增屬性、刪除屬性、讀取屬性還是修改屬性都能被攔截所以就不需要$set了。同時(shí)Vue 3 的響應(yīng)式還做了懶收集不像 Vue 2 初始化時(shí)就把所有屬性都遞歸遍歷一遍而是等真正用到了才去收集依賴性能上也有提升。筆試答這道題建議畫(huà)一個(gè)兩列對(duì)比表格把“數(shù)據(jù)初始化時(shí)發(fā)生了什么”“新增屬性時(shí)怎么處理”“數(shù)組變更時(shí)怎么處理”“性能表現(xiàn)”這幾個(gè)維度列出來(lái)。這能有效展示你理解得夠深。4.2 組件通信父子、兄弟、跨層級(jí)這題說(shuō)白了就是考察你實(shí)際寫(xiě)項(xiàng)目時(shí)有沒(méi)有遇到過(guò)組件間數(shù)據(jù)傳遞的場(chǎng)景。樂(lè)信筆試?yán)锍霈F(xiàn)過(guò)一道場(chǎng)景題有 A、B 兩個(gè)兄弟組件用戶點(diǎn)擊 B 組件里的按鈕需要讓 A 組件里的數(shù)據(jù)發(fā)生變化問(wèn)怎么實(shí)現(xiàn)。這道題沒(méi)有唯一標(biāo)準(zhǔn)答案它考察的是你對(duì)多種通信方案的理解以及方案選型能力。優(yōu)秀的回答應(yīng)該先列出所有方案再說(shuō)出你在什么場(chǎng)景下會(huì)用哪種方案。常見(jiàn)方案場(chǎng)景方案父?jìng)髯觩rops子傳父$emit觸發(fā)自定義事件兄弟組件通過(guò)共同的父組件中轉(zhuǎn)子B$emit父組件監(jiān)聽(tīng)父組件把數(shù)據(jù)通過(guò) props 傳給子A跨層級(jí) / 任意組件Vuex狀態(tài)管理庫(kù)、Provide/Inject、EventBusReact 場(chǎng)景Context、Redux/Zustand回答這題時(shí)可以順便講講 Vuex 的架構(gòu)和核心概念。state是全局狀態(tài)數(shù)據(jù)getters類似 Vue 實(shí)例里的 computed用于派生狀態(tài)mutations是唯一能修改 state 的地方而且是同步的actions里可以寫(xiě)異步邏輯可以提交 mutation。為什么 mutation 必須是同步的因?yàn)?Vuex 的 devtools 要記錄狀態(tài)變化的快照如果 mutation 里混了異步操作時(shí)間線就沒(méi)法追蹤了調(diào)試起來(lái)會(huì)很痛苦。4.3 生命周期從創(chuàng)建到銷毀的關(guān)鍵時(shí)刻生命周期是框架題的?？统鲱}方式通常是給一段代碼問(wèn)在哪個(gè)生命周期里發(fā)請(qǐng)求、在哪個(gè)生命周期里銷毀定時(shí)器、在哪個(gè)生命周期里訪問(wèn) DOM。Vue 2 的生命周期可以歸納為四個(gè)階段創(chuàng)建階段beforeCreate實(shí)例初始化之前此時(shí)拿不到 data 和 methods、created實(shí)例創(chuàng)建完成data 和 methods 可用但 DOM 還沒(méi)掛載掛載階段beforeMount模板編譯完成但還沒(méi)有插入真實(shí) DOM、mountedDOM 掛載完成可以訪問(wèn)this.$el更新階段beforeUpdate數(shù)據(jù)變化后DOM 更新前、updatedDOM 更新完成銷毀階段beforeDestroy實(shí)例銷毀前定時(shí)器、事件監(jiān)聽(tīng)還活著適合清理、destroyed實(shí)例銷毀后答生命周期題建議記住一個(gè)核心結(jié)論發(fā)起數(shù)據(jù)請(qǐng)求放在created或mounted都行但放在created更好因?yàn)閏reated階段在掛載之前數(shù)據(jù)如果提前拿到可以避免 DOM 渲染完再等數(shù)據(jù)造成的不必要閃爍。定時(shí)器和全局事件監(jiān)聽(tīng)一定在beforeDestroy里清理。樂(lè)信筆試這道題的陷阱是問(wèn)“在created里能不能訪問(wèn) DOM”。答案是不能。因?yàn)閏reated階段實(shí)例剛創(chuàng)建模板還沒(méi)編譯DOM 還沒(méi)存在訪問(wèn)this.$el是undefined。如果你需要在初始化階段操作 DOM比如讓某個(gè)元素獲得焦點(diǎn)那就得放在mounted或$nextTick回調(diào)里。5. 版本控制與工程化基礎(chǔ)考察你的職業(yè)素養(yǎng)前幾年校招筆試?yán)锇姹究刂艷it和工程化相關(guān)的題占比不高但偶爾會(huì)出現(xiàn)在附加題或簡(jiǎn)答題里。樂(lè)信2020年的筆試就有一道 Git 操作場(chǎng)景題。這類題你說(shuō)它難它真的不難但如果你是第一次見(jiàn)可能連命令都寫(xiě)不完整。5.1 Git 協(xié)作場(chǎng)景沖突解決與分支管理常見(jiàn)筆試題目是你正在一個(gè)分支上開(kāi)發(fā)功能另一個(gè)同事改了同一個(gè)文件的同一個(gè)地方你把他的分支合并到你的分支時(shí)發(fā)生了沖突怎么解決正確的操作路徑先提交你當(dāng)前分支的工作切換到目標(biāo)分支比如 main/master拉取最新代碼切回你的開(kāi)發(fā)分支執(zhí)行g(shù)it merge main或git rebase mainGit 提示沖突CONFLICT打開(kāi)沖突文件你會(huì)看到類似這樣內(nèi)容 HEAD 你的代碼 對(duì)方的代碼 feature/xxx手動(dòng)編輯文件刪掉、、這些標(biāo)記決定保留哪部分代碼或都保留保存后執(zhí)行g(shù)it add把文件加入暫存區(qū)執(zhí)行g(shù)it commit完成沖突解決。這里要補(bǔ)充一個(gè)概念對(duì)比merge和rebase的區(qū)別。merge會(huì)保留完整的合并歷史生成一個(gè)新的 merge commit分支圖會(huì)分叉rebase是把你的提交“變基”到目標(biāo)分支之后重新排列提交歷史是一條直線更干凈。筆試如果問(wèn)“你們團(tuán)隊(duì)用 merge 還是 rebase”比較好的回答是團(tuán)隊(duì)協(xié)作中尤其是公共分支盡量用 merge 來(lái)保留歷史個(gè)人開(kāi)發(fā)分支可以用 rebase 整理提交記錄讓歷史更線性。5.2 Webpack 核心概念loader、plugin、性能優(yōu)化樂(lè)信這類偏工程化的公司筆試?yán)锖芸赡軙?huì)考 Webpack 的基本概念。核心考點(diǎn)就三個(gè)loader 是什么、plugin 是什么、兩者區(qū)別在哪里。簡(jiǎn)單來(lái)說(shuō)loader 是“轉(zhuǎn)換器”它把 Webpack 不認(rèn)識(shí)的文件轉(zhuǎn)換成 JS 模塊。比如 babel-loader 把 ES6 語(yǔ)法編譯成 ES5css-loader 處理 CSS 文件里的import和url()style-loader 把 CSS 代碼注入到style標(biāo)簽里。plugin 是“擴(kuò)展器”它可以玩更高級(jí)的把控。從打包優(yōu)化到文件處理到環(huán)境變量注入都能通過(guò) plugin 實(shí)現(xiàn)。常見(jiàn)的有HtmlWebpackPlugin自動(dòng)生成 HTML 并注入打包后的腳本、MiniCssExtractPlugin把 CSS 提取成獨(dú)立文件、TerserPlugin壓縮 JS。loader 和 plugin 最常見(jiàn)的混淆點(diǎn)很多人分不清“轉(zhuǎn)換某個(gè)文件類型”到底應(yīng)該用 loader 還是 plugin。記住一句話loader 只做文件級(jí)轉(zhuǎn)換plugin 做構(gòu)建流程級(jí)別的控制。舉個(gè)直觀例子處理.vue文件用的是vue-loader它把單文件組件拆成模板、腳本、樣式三部分再分別處理而你想要在打包結(jié)束之后自動(dòng)上傳產(chǎn)物到 CDN那就是UploadPlugin自定義 plugin的事了。如果筆試再加問(wèn) Webpack 性能優(yōu)化可以從兩個(gè)維度答打包體積開(kāi)啟 tree-shaking去除沒(méi)用到的模塊代碼分割splitChunks把公共依賴抽出來(lái)按需加載路由懶加載。構(gòu)建速度用cache-loader或 Webpack 自帶的持久化緩存用thread-loader開(kāi)啟多進(jìn)程構(gòu)建減少 loader 的include范圍別讓node_modules里的文件也被 Babel 去處理。5.3 一個(gè)簡(jiǎn)單的筆試場(chǎng)景題如何設(shè)計(jì)一個(gè)可復(fù)用的彈窗組件這類題在筆試題里被歸為“設(shè)計(jì)題”不寫(xiě)完整代碼只考設(shè)計(jì)思路。出題意圖非常明確看你會(huì)不會(huì)抽象組件、會(huì)不會(huì)考慮公共邏輯、會(huì)不會(huì)預(yù)留擴(kuò)展點(diǎn)。一個(gè)合格的彈窗組件應(yīng)該至少包含以下設(shè)計(jì)點(diǎn)對(duì)外暴露的 API通過(guò) props 控制彈窗標(biāo)題、寬度、內(nèi)容、是否顯示底部按鈕通過(guò)事件如visible-change通知外部彈窗關(guān)閉?？刂骑@隱外部通過(guò)v-if或visible屬性控制組件內(nèi)部在點(diǎn)擊遮罩層、點(diǎn)擊關(guān)閉按鈕時(shí)觸發(fā)關(guān)閉事件。插槽slot設(shè)計(jì)支持默認(rèn)插槽自定義內(nèi)容區(qū)域支持具名插槽如 footer自定義按鈕區(qū)域。功能細(xì)節(jié)點(diǎn)擊遮罩層是否關(guān)閉需可配置close-on-click-overlay是否顯示右上角關(guān)閉按鈕需可配置是否可拖拽需可配置組件卸載時(shí)是否重置數(shù)據(jù)。層級(jí)管理彈窗的z-index應(yīng)該是動(dòng)態(tài)遞增的防止多個(gè)彈窗互相遮擋。一般會(huì)有一個(gè)全局變量記錄當(dāng)前最大z-index每次打開(kāi)彈窗時(shí)加1。定位與布局彈窗居中遮罩層覆蓋全屏滾動(dòng)鎖死打開(kāi)彈窗時(shí)禁止 body 滾動(dòng)。回答設(shè)計(jì)題時(shí)最好口述一個(gè)“從使用到實(shí)現(xiàn)”的完整鏈路最外層是一個(gè)遮罩層position: fixed覆蓋全屏半透明背景中間是彈窗主體position: fixedleft: 50%; top: 50%; transform: translate(-50%, -50%)實(shí)現(xiàn)居中通過(guò) TeleportVue 3或 Portal 把彈窗掛載到body下避免被父組件的overflow: hidden裁掉。能講到 Teleport/Portal 這層基本就比大多數(shù)候選人高出一個(gè)段位了。因?yàn)檫@證明你不僅知道怎么用組件還知道組件在 DOM 結(jié)構(gòu)中的位置會(huì)影響樣式表現(xiàn)。6. 從筆試到實(shí)戰(zhàn)那些刷題之外更重要的功夫講完這幾類典型題型我知道很多讀者更關(guān)心的是我到底該怎么準(zhǔn)備才能在有限時(shí)間里最高效地通過(guò)筆試我自己的經(jīng)驗(yàn)是筆試前一天不要把大量時(shí)間花在刷“新題”上而是做三件效率最高的事。第一把高頻手寫(xiě)題默寫(xiě)一遍。防抖、節(jié)流、深拷貝、Promise.all、數(shù)組去重、數(shù)組扁平化、call/apply/bind 的實(shí)現(xiàn)。這些題是有標(biāo)準(zhǔn)模板的你只要平時(shí)默寫(xiě)過(guò)三遍以上考場(chǎng)上基本是肌肉記憶幾分鐘就能寫(xiě)完還能騰出時(shí)間給后面的難題。第二把框架的核心原理用自己的話說(shuō)一遍。Vue 響應(yīng)式、生命周期、組件通信、虛擬 DOMReact 的函數(shù)組件渲染流程、hooks 的原理。能用自己的話說(shuō)清楚說(shuō)明你是真理解而不是背的八股文。筆試簡(jiǎn)答題最忌諱的就是把網(wǎng)上的原話抄上去閱卷人一眼就能看出你是背的還容易因?yàn)楸硎霾粐?yán)謹(jǐn)被扣分。第三看看你們學(xué)校或目標(biāo)公司往年的筆試真題搞清楚出題風(fēng)格。有些公司偏愛(ài)手寫(xiě)題有些公司偏愛(ài)基礎(chǔ)選擇題有些公司會(huì)加一道邏輯題或場(chǎng)景設(shè)計(jì)題。投了不同公司策略完全不同。這里還想多說(shuō)幾句關(guān)于“刷題心態(tài)”的問(wèn)題。我發(fā)現(xiàn)很多應(yīng)屆生準(zhǔn)備筆試時(shí)容易陷入一種焦慮覺(jué)得題量巨大、知識(shí)無(wú)邊似乎永遠(yuǎn)準(zhǔn)備不完。實(shí)際上校招筆試是個(gè)合格性考試不是選拔性考試它不是要你考滿分而是要看你在重點(diǎn)模塊上有沒(méi)有達(dá)到一個(gè)“能干活”的最低標(biāo)準(zhǔn)。所以與其在所有角落撒網(wǎng)不如把最高頻的模塊吃透。就拿樂(lè)信這套題來(lái)說(shuō)JavaScript 基礎(chǔ)、手寫(xiě)代碼、瀏覽器緩存、跨域、Vue 原理、Git 常規(guī)操作這幾塊占了 80% 的分?jǐn)?shù)。把這些搞定筆試過(guò)關(guān)基本沒(méi)有問(wèn)題。還有一點(diǎn)做題時(shí)一定要先易后難。開(kāi)考后先花 5 分鐘把整張卷子掃一遍標(biāo)記出哪些題是送分題哪些題是模棱兩可的哪些題是完全沒(méi)思路的。先把送分題寫(xiě)完再做中等難度的最后有時(shí)間再攻克難題。很多同學(xué)喜歡按順序做結(jié)果手寫(xiě)題卡了半小時(shí)后面的簡(jiǎn)答題沒(méi)時(shí)間寫(xiě)白白丟分。最后聊一個(gè)隱藏技能筆試?yán)锏拇a書(shū)寫(xiě)規(guī)范。手寫(xiě)題雖然不要求真的跑起來(lái)但閱卷人會(huì)看你的代碼習(xí)慣。變量命名是不是有語(yǔ)義有沒(méi)有處理邊界情況格式是不是整潔這些都會(huì)影響印象分。我見(jiàn)過(guò)有些同學(xué)手寫(xiě)代碼時(shí)連分號(hào)都不寫(xiě)函數(shù)名用a、b、fn代替雖然邏輯可能是對(duì)的但給閱卷人的感覺(jué)很不好。筆試不僅僅是考你會(huì)不會(huì)也是在模擬你未來(lái)在工作里寫(xiě)代碼的樣子。把一個(gè)數(shù)組去重寫(xiě)成兩行簡(jiǎn)潔、有注釋的代碼和寫(xiě)十行邏輯混亂的代碼最后得分差距會(huì)很大。我自己面過(guò)不少校招生刷掉的人不一定是技術(shù)最差的但大概率是代碼習(xí)慣最差的。所以從現(xiàn)在開(kāi)始每次在紙上或白板上寫(xiě)代碼都把它當(dāng)成一次正式的代碼審查注意格式、命名、邊界條件。這個(gè)習(xí)慣養(yǎng)成了不管什么筆試都會(huì)受益。準(zhǔn)備筆試的過(guò)程其實(shí)是很枯燥的但也是提升最快的階段。等你真正把原型鏈、事件循環(huán)、響應(yīng)式原理這些硬骨頭啃下來(lái)再回頭看之前覺(jué)得難的項(xiàng)目會(huì)發(fā)現(xiàn)腦海里的圖景完全不一樣。技術(shù)這條路有時(shí)候就是這樣你以為是應(yīng)付考試實(shí)際上是在給自己打更深的地基。