筆試拿到手里那一刻屏幕上全是密密麻麻的選擇題和兩道算法題時(shí)間兩小時(shí)旁邊的同學(xué)已經(jīng)開(kāi)始噼里啪啦敲鍵盤(pán)了。說(shuō)實(shí)話第四范式那年前端筆試的難度放在今天看依然不算低——不是因?yàn)轭}目偏、怪而是它特別擅長(zhǎng)把“你覺(jué)得自己會(huì)”的知識(shí)點(diǎn)換一個(gè)角度問(wèn)到你說(shuō)不出話。這篇文章不打算復(fù)刻當(dāng)年的原卷題目因?yàn)檫@類(lèi)內(nèi)容涉及保密協(xié)議網(wǎng)上流傳的版本也殘缺不全。我想做的是把那年校招前端筆試真正的考點(diǎn)脈絡(luò)拆解出來(lái)——它考了什么、為什么考、底層在考察什么能力以及如果你要備戰(zhàn)類(lèi)似的人工智能公司前端崗應(yīng)該如何體系化準(zhǔn)備。第四范式是做機(jī)器學(xué)習(xí)和人工智能平臺(tái)的公司這類(lèi)公司的前端崗位有一個(gè)明顯特征不追求花哨的頁(yè)面表現(xiàn)而是極度看重你對(duì)計(jì)算機(jī)基礎(chǔ)、JavaScript語(yǔ)言本質(zhì)、瀏覽器原理的掌握程度。換句話說(shuō)它認(rèn)認(rèn)真真地把前端當(dāng)軟件工程在考而不是當(dāng)“切圖仔”在考。這也是為什么那套題里純CSS布局題少得可憐反而有大量你在日常業(yè)務(wù)開(kāi)發(fā)中可能從未深究過(guò)的“底層題”。下面我會(huì)按照當(dāng)年筆試的真實(shí)模塊劃分把每個(gè)模塊的核心考點(diǎn)、出題意圖和準(zhǔn)備思路完整拆開(kāi)講。這篇文章里的題目均為基于公開(kāi)考點(diǎn)和歷年考生回憶的“同源變體”目的不是讓你背題而是讓你知道這類(lèi)題應(yīng)該怎么思考。1. 選擇題里的“陷阱藝術(shù)”你以為會(huì)其實(shí)一直在踩坑第四范式筆試的選擇題部分是整套題里最陰險(xiǎn)的。它不考什么偏門(mén)API所有考點(diǎn)都在你日常開(kāi)發(fā)中反復(fù)遇到但換個(gè)問(wèn)法之后錯(cuò)誤率能到七成以上。我一位當(dāng)年參加筆試的朋友出了考場(chǎng)跟我復(fù)盤(pán)最后一句是“這些題我全見(jiàn)過(guò)但全選錯(cuò)了”——這就是它的出題邏輯用最熟悉的知識(shí)點(diǎn)制造最隱蔽的思維盲區(qū)。1.1 JavaScript變量提升與閉包看似送分實(shí)際全是坑先看這一類(lèi)題目的經(jīng)典變體幾乎每一份前端筆試題里都會(huì)出現(xiàn)但第四范式的考法更細(xì)致。比如var a []; for (var i 0; i 10; i) { a[i] function () { console.log(i); }; } a[6]();如果你脫口而出“6”那這道題的分?jǐn)?shù)就沒(méi)了。正確答案是10因?yàn)関ar聲明的i屬于函數(shù)作用域循環(huán)結(jié)束后i已經(jīng)是10所有閉包捕獲的都是同一個(gè)變量。這類(lèi)題的進(jìn)階版會(huì)繼續(xù)延伸把var換成let、把函數(shù)換成箭頭函數(shù)、把console.log換成setTimeout每一種變化背后考察的都是對(duì)作用域和執(zhí)行上下文的真正理解。還有一類(lèi)高頻變形題是這樣——它們不再直接問(wèn)你輸出什么而是要求你判斷某個(gè)函數(shù)調(diào)用后外部變量是否被修改。比如function change(obj) { obj.name paradox; obj { name: new }; } let person { name: origin }; change(person); console.log(person.name);這道題考的是引用傳遞的邊界問(wèn)題。很多人知道對(duì)象是按引用傳遞的就誤以為obj { name: new }也會(huì)影響外部變量。但實(shí)際上面試官想考的是你修改的是“對(duì)象的內(nèi)容”還是“引用的指向”。obj.name paradox改的是堆內(nèi)存里那個(gè)對(duì)象本身外部person自然跟著變obj { name: new }只是讓obj這個(gè)參數(shù)變量重新指向了一塊新內(nèi)存原來(lái)的對(duì)象毫發(fā)無(wú)損。所以結(jié)果是paradox。這種題說(shuō)穿了其實(shí)是在考“值傳遞和引用傳遞的本質(zhì)區(qū)別”而很多教材對(duì)這一塊的表述是含糊的——嚴(yán)格來(lái)說(shuō)JavaScript里一切參數(shù)傳遞都是值傳遞只不過(guò)當(dāng)值是對(duì)象時(shí)傳遞的是“指向該對(duì)象的引用”的副本。我當(dāng)時(shí)給的準(zhǔn)備建議是不要靠背誦理解這類(lèi)題一定要在瀏覽器控制臺(tái)里親手改代碼、跑結(jié)果、再改回來(lái)反復(fù)幾次你才會(huì)對(duì)“引用副本”和“對(duì)象本身”產(chǎn)生肌肉記憶。面試筆試時(shí)時(shí)間是有限的如果你連這類(lèi)基礎(chǔ)題都要靠推理而非直覺(jué)后面的大題基本寫(xiě)不完。1.2 作用域鏈、this指向與箭頭函數(shù)高頻但不是送分題筆試選擇題里this指向的題目出現(xiàn)頻率極高。套路無(wú)非三種普通函數(shù)調(diào)用、對(duì)象方法調(diào)用、構(gòu)造函數(shù)調(diào)用——分別對(duì)應(yīng)this指向全局、指向?qū)ο?、指向新?chuàng)建的對(duì)象。但第四范式這類(lèi)公司通常會(huì)把this和箭頭函數(shù)混在一起考讓你對(duì)比兩段幾乎一樣的代碼輸出結(jié)果卻完全不同。var obj { name: paradox, getName: function () { return this.name; }, getNameArrow: () { return this.name; } }; console.log(obj.getName()); console.log(obj.getNameArrow());obj.getName()輸出paradox這沒(méi)問(wèn)題。但obj.getNameArrow()輸出的是undefined——箭頭函數(shù)本身沒(méi)有自己的this它捕獲的是定義時(shí)所在作用域的this也就是全局對(duì)象。如果全局對(duì)象里沒(méi)有name屬性結(jié)果就是undefined。這里幾乎所有人都知道箭頭函數(shù)的this是詞法作用域但真放到對(duì)象方法里對(duì)比時(shí)依然有一大半人會(huì)答錯(cuò)。更進(jìn)階的變體還會(huì)把this和原型鏈結(jié)合function Person(name) { this.name name; } Person.prototype.getName function () { return this.name; }; const p new Person(paradox); const fn p.getName; console.log(fn());這道題當(dāng)年答錯(cuò)的人非常多。fn只是對(duì)方法的引用調(diào)用時(shí)this已經(jīng)不再是p了而是全局對(duì)象所以結(jié)果是undefined。它考的是this綁定里最容易忽略的一條鐵律函數(shù)被調(diào)用時(shí)this的指向取決于調(diào)用方式而不是定義位置。一旦函數(shù)被解引用、賦值、當(dāng)作回調(diào)傳入this基本就丟了。針對(duì)這類(lèi)考點(diǎn)我建議你別只刷題。把JS的call、apply、bind三個(gè)方法的區(qū)別寫(xiě)在筆記本上然后手寫(xiě)一遍模擬bind的實(shí)現(xiàn)。這個(gè)過(guò)程會(huì)逼你認(rèn)真理解函數(shù)調(diào)用時(shí)的this綁定過(guò)程。當(dāng)年我就是這么練的后來(lái)遇到所有this指向的題目基本不用過(guò)腦子直接套“調(diào)用時(shí)綁定”和“箭頭函數(shù)詞法綁定”兩條規(guī)則就能鎖定答案。1.3 事件循環(huán)與異步AI公司的必考項(xiàng)目人工智能公司的前端筆試幾乎必考事件循環(huán)。原因很簡(jiǎn)單機(jī)器學(xué)習(xí)平臺(tái)的很多場(chǎng)景是實(shí)時(shí)展示訓(xùn)練進(jìn)度、流式請(qǐng)求長(zhǎng)連接、大規(guī)模數(shù)據(jù)可視化的動(dòng)態(tài)刷新這些全都依賴(lài)對(duì)異步機(jī)制的正確理解。筆試?yán)镒畛Ｒ?jiàn)的考法并不是讓你背宏任務(wù)微任務(wù)列表而是給出幾段相互嵌套的setTimeout和Promise執(zhí)行順序讓你排序。setTimeout(() { console.log(timeout1); Promise.resolve().then(() { console.log(promise1); }); }, 0); Promise.resolve().then(() { console.log(promise2); setTimeout(() { console.log(timeout2); }, 0); });輸出順序是promise2 → timeout1 → promise1 → timeout2。核心邏輯是同步代碼先執(zhí)行完畢接著清空當(dāng)前微任務(wù)隊(duì)列promise2然后取一個(gè)宏任務(wù)執(zhí)行timeout1timeout1執(zhí)行過(guò)程中產(chǎn)生的微任務(wù)promise1會(huì)在下一個(gè)宏任務(wù)timeout2之前被清空。這里有一個(gè)極其容易踩的坑有人會(huì)把“微任務(wù)優(yōu)先于宏任務(wù)”錯(cuò)誤理解為“所有微任務(wù)永遠(yuǎn)在所有宏任務(wù)之前”。實(shí)際上每執(zhí)行完一個(gè)宏任務(wù)都會(huì)重新檢查微任務(wù)隊(duì)列并全部清空然后再取下一個(gè)宏任務(wù)。也就是說(shuō)宏任務(wù)和微任務(wù)的交替是嵌套進(jìn)行的而不是分成兩個(gè)獨(dú)立的階段。筆試?yán)镏灰霈F(xiàn)Promise里面再包setTimeout或者setTimeout里再包Promise考的就是這個(gè)交替機(jī)制。準(zhǔn)備這類(lèi)題目不要靠背“幾個(gè)宏任務(wù)幾個(gè)微任務(wù)”的結(jié)論建議自己畫(huà)一張“事件循環(huán)時(shí)間線圖”把代碼執(zhí)行過(guò)程拆成同步段、微任務(wù)段、宏任務(wù)段每處理一個(gè)任務(wù)就重新檢查微任務(wù)隊(duì)列反復(fù)畫(huà)三五張你就能建立一套自己的分析流程。當(dāng)年筆試前我專(zhuān)門(mén)練過(guò)幾十道這類(lèi)題后來(lái)面對(duì)更復(fù)雜的組合題也能快速拆解。2. 手寫(xiě)代碼題看著簡(jiǎn)單但你要寫(xiě)出“有工程素養(yǎng)”的代碼第四范式筆試題的手寫(xiě)代碼部分和普通小公司的“手寫(xiě)一個(gè)防抖節(jié)流”完全不是一個(gè)層次。它要求的是在有限時(shí)間內(nèi)寫(xiě)出健壯、可擴(kuò)展、有邊界處理的完整函數(shù)而不是只寫(xiě)出核心邏輯。閱卷人一眼就能看出你是背過(guò)代碼還是真正理解。2.1 手寫(xiě)實(shí)現(xiàn)防抖與節(jié)流不是背代碼而是理解場(chǎng)景防抖和節(jié)流是前端筆試的常青樹(shù)第四范式幾乎每年都有。先說(shuō)防抖的核心定義在事件被連續(xù)觸發(fā)時(shí)只有在最后一次觸發(fā)后的等待時(shí)間內(nèi)沒(méi)有再次觸發(fā)才執(zhí)行函數(shù)。典型場(chǎng)景是搜索框輸入聯(lián)想用戶停止輸入500毫秒后才發(fā)送請(qǐng)求。一個(gè)合格的防抖實(shí)現(xiàn)至少要考慮三件事this指針的正確保留、事件參數(shù)的傳遞、以及取消能力。如果面試官在里面加一個(gè)“立即執(zhí)行”選項(xiàng)——第一次觸發(fā)時(shí)立即執(zhí)行之后連續(xù)觸發(fā)都重置計(jì)時(shí)器那多數(shù)人當(dāng)場(chǎng)露餡。我當(dāng)時(shí)總結(jié)的寫(xiě)法function debounce(func, wait, immediate) { let timer null; return function (...args) { const context this; const callNow immediate !timer; if (timer) clearTimeout(timer); timer setTimeout(() { timer null; if (!immediate) func.apply(context, args); }, wait); if (callNow) func.apply(context, args); }; }節(jié)流則不同它的核心是限制函數(shù)的執(zhí)行頻率保證在指定時(shí)間間隔內(nèi)最多執(zhí)行一次。經(jīng)典場(chǎng)景是滾動(dòng)事件里判斷是否加載更多。實(shí)現(xiàn)方式有“時(shí)間戳版”和“定時(shí)器版”兩種時(shí)間戳版的優(yōu)點(diǎn)是第一次會(huì)立即執(zhí)行缺點(diǎn)是停止觸發(fā)后最后一次調(diào)用會(huì)被丟棄定時(shí)器版恰恰相反最后一次會(huì)被執(zhí)行但第一次會(huì)有延遲。筆試題目如果只要求“手寫(xiě)節(jié)流”寫(xiě)出其中一種并講清楚缺陷基本就能拿滿分。但如果你能主動(dòng)說(shuō)“時(shí)間戳版適合拖拽場(chǎng)景定時(shí)器版適合動(dòng)畫(huà)場(chǎng)景兩者可以結(jié)合成有頭有尾的加強(qiáng)版”這就能拉開(kāi)和普通考生的差距。我當(dāng)時(shí)還專(zhuān)門(mén)寫(xiě)了一個(gè)帶leading和trailing配置項(xiàng)的版本function throttle(func, wait, options {}) { let timer null; let previous 0; return function (...args) { const context this; const now Date.now(); if (!previous options.leading false) previous now; const remaining wait - (now - previous); if (remaining 0) { if (timer) { clearTimeout(timer); timer null; } previous now; func.apply(context, args); } else if (!timer options.trailing ! false) { timer setTimeout(() { previous options.leading false ? 0 : Date.now(); timer null; func.apply(context, args); }, remaining); } }; }這一版不僅處理了首次和末次觸發(fā)的邊界情況代碼的可讀性也更好。寫(xiě)這類(lèi)代碼時(shí)哪怕筆試環(huán)境不要求你運(yùn)行也建議在注釋里簡(jiǎn)單標(biāo)注每一塊的意圖。閱卷人看得出來(lái)你是“背的”還是“懂的”。2.2 手寫(xiě)深拷貝從“能用”到“穩(wěn)”的進(jìn)階之路深拷貝在前端筆試?yán)锍霈F(xiàn)的概率極高但大多數(shù)人第一反應(yīng)是JSON.parse(JSON.stringify(obj))。這條捷徑能應(yīng)付純JSON數(shù)據(jù)但一旦遇到undefined、function、Symbol、Date、RegExp、循環(huán)引用它就會(huì)暴露出嚴(yán)重問(wèn)題。第四范式這類(lèi)公司的筆試題不會(huì)直接問(wèn)你“寫(xiě)一個(gè)深拷貝”而是給你一個(gè)包含上述特殊類(lèi)型的對(duì)象讓你寫(xiě)一個(gè)函數(shù)能完整拷貝——這就是在逼你考慮所有邊界情況。一個(gè)比較完整的深拷貝實(shí)現(xiàn)核心思路是用WeakMap記錄已經(jīng)拷貝過(guò)的對(duì)象解決循環(huán)引用問(wèn)題對(duì)基本類(lèi)型直接返回用Object.prototype.toString判斷類(lèi)型分別處理Date、RegExp、Map、Set、Array和普通對(duì)象。function deepClone(target, map new WeakMap()) { if (target null || typeof target ! object) return target; if (map.has(target)) return map.get(target); const type Object.prototype.toString.call(target); const basicTypes [[object Date], [object RegExp]]; if (basicTypes.includes(type)) { return new target.constructor(target); } if (type [object Map]) { const mapClone new Map(); map.set(target, mapClone); target.forEach((value, key) { mapClone.set(key, deepClone(value, map)); }); return mapClone; } if (type [object Set]) { const setClone new Set(); map.set(target, setClone); target.forEach(value { setClone.add(deepClone(value, map)); }); return setClone; } const clone Array.isArray(target) ? [] : {}; map.set(target, clone); Reflect.ownKeys(target).forEach(key { clone[key] deepClone(target[key], map); }); return clone; }這里Reflect.ownKeys會(huì)把Symbol類(lèi)型的鍵也拿進(jìn)來(lái)這是一個(gè)非常討巧的細(xì)節(jié)。很多人寫(xiě)深拷貝時(shí)會(huì)忽略Symbol鍵如果筆試題目里故意加一個(gè)Symbol屬性能想到用Reflect.ownKeys的考生就寥寥無(wú)幾了。另外一個(gè)筆試殺手锏是循環(huán)引用。如果不處理調(diào)用棧直接爆掉。用WeakMap而不是Map的原因也很簡(jiǎn)單WeakMap的鍵是弱引用不會(huì)阻止垃圾回收能避免深拷貝完之后的額外內(nèi)存滯留。我建議你寫(xiě)這道題時(shí)先在注釋里列出“需要處理的類(lèi)型清單”再逐個(gè)分支實(shí)現(xiàn)。這樣整體結(jié)構(gòu)清晰閱卷人給你的印象分也會(huì)高很多。2.3 手寫(xiě)事件總線或觀察者模式前端架構(gòu)的縮影觀察者模式和發(fā)布訂閱模式是前端面試?yán)锢@不開(kāi)的設(shè)計(jì)模式考點(diǎn)。第四范式這類(lèi)做平臺(tái)型產(chǎn)品的公司尤其重視這種抽象能力。筆試?yán)锿ǔ?huì)出一道偏中等的題手寫(xiě)一個(gè)EventEmitter需要支持on、off、once和emit。這題表面上考的是API設(shè)計(jì)其實(shí)考的是三件事事件映射表的數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)、once監(jiān)聽(tīng)的自動(dòng)移除、off時(shí)的安全性。很多人的實(shí)現(xiàn)能跑通基礎(chǔ)場(chǎng)景但一遇到監(jiān)聽(tīng)函數(shù)在觸發(fā)過(guò)程中又被移除的邊界情況就出問(wèn)題了。我的參考實(shí)現(xiàn)class EventEmitter { constructor() { this.events Object.create(null); } on(type, handler) { if (!this.events[type]) this.events[type] []; this.events[type].push(handler); } off(type, handler) { if (!this.events[type]) return; const index this.events[type].indexOf(handler); if (index -1) { this.events[type].splice(index, 1); } } once(type, handler) { const wrapper (...args) { handler.apply(this, args); this.off(type, wrapper); }; this.on(type, wrapper); } emit(type, ...args) { if (!this.events[type] || this.events[type].length 0) return; this.events[type].slice().forEach(handler { handler.apply(this, args); }); } }這里有一個(gè)非常重要的細(xì)節(jié)emit里用了slice()復(fù)制了一份監(jiān)聽(tīng)器數(shù)組。為什么要復(fù)制因?yàn)槿绻硞€(gè)監(jiān)聽(tīng)器內(nèi)部調(diào)用了off把后續(xù)的監(jiān)聽(tīng)器移除正在遍歷的原數(shù)組長(zhǎng)度會(huì)發(fā)生變化導(dǎo)致跳過(guò)某些監(jiān)聽(tīng)器。用復(fù)制數(shù)組遍歷可以避免這種“遍歷時(shí)增刪元素導(dǎo)致行為異?！钡膯?wèn)題。這個(gè)細(xì)節(jié)筆試?yán)锊灰欢〞?huì)考到但如果你在注釋里寫(xiě)明原因閱卷人立刻知道你是真寫(xiě)過(guò)、踩過(guò)坑的人。3. 網(wǎng)絡(luò)與瀏覽器原理從“會(huì)用”到“懂得為什么”前端工程師的日常工作離不開(kāi)HTTP、瀏覽器緩存、渲染原理但這些知識(shí)在業(yè)務(wù)開(kāi)發(fā)中往往被框架和工具鏈掩蓋住了。第四范式的筆試?yán)锞W(wǎng)絡(luò)和瀏覽器相關(guān)的題目分量很重因?yàn)槿斯ぶ悄芷脚_(tái)的Web端有大量數(shù)據(jù)和模型文件需要加載性能優(yōu)化是剛需。3.1 HTTP緩存機(jī)制強(qiáng)緩存與協(xié)商緩存的完整鏈路關(guān)于HTTP緩存的選擇題第四范式考過(guò)的角度特別刁鉆。它不直接問(wèn)“強(qiáng)緩存和協(xié)商緩存的區(qū)別”而是給出幾種響應(yīng)頭配置讓你判斷瀏覽器是直接使用本地緩存還是發(fā)請(qǐng)求去服務(wù)器驗(yàn)證。如果發(fā)請(qǐng)求服務(wù)器返回304后瀏覽器接下來(lái)怎么做。核心鏈路是這樣的瀏覽器請(qǐng)求資源時(shí)先看強(qiáng)緩存Cache-Control是max-age3600還在有效期內(nèi)就完全不會(huì)發(fā)請(qǐng)求直接用本地緩存。如果強(qiáng)緩存失效瀏覽器會(huì)帶上If-None-Match對(duì)應(yīng)ETag或If-Modified-Since對(duì)應(yīng)Last-Modified發(fā)請(qǐng)求服務(wù)器返回304時(shí)瀏覽器繼續(xù)使用本地緩存但會(huì)更新緩存有效期服務(wù)器返回200時(shí)內(nèi)容和緩存一并更新。筆試?yán)镒钊菀鬃鲥e(cuò)的點(diǎn)有三個(gè)Cache-Control的優(yōu)先級(jí)高于Expires。兩者同時(shí)存在時(shí)以Cache-Control為準(zhǔn)但很多人只會(huì)背“高優(yōu)先級(jí)”這個(gè)結(jié)論不理解是因?yàn)镃ache-Control是HTTP/1.1規(guī)范而Expires是HTTP/1.0規(guī)范瀏覽器為了兼容會(huì)優(yōu)先采用更現(xiàn)代的字段。no-cache的意思不是“不緩存”而是“每次使用前必須去服務(wù)端驗(yàn)證”no-store才是真正的不緩存。如果響應(yīng)頭里沒(méi)有Cache-Control但設(shè)置了Last-Modified瀏覽器通常會(huì)采用啟發(fā)式緩存部分瀏覽器會(huì)按(當(dāng)前時(shí)間 - Last-Modified時(shí)間) * 10%來(lái)設(shè)置一個(gè)緩存時(shí)間。這最后一點(diǎn)是我在真實(shí)環(huán)境里抓包驗(yàn)證過(guò)的。比如一張圖片的Last-Modified是一個(gè)月前瀏覽器可能在沒(méi)有任何顯式緩存頭的情況下自動(dòng)把這張圖片緩存三天。如果你在筆試題里遇到“沒(méi)有緩存相關(guān)響應(yīng)頭但瀏覽器卻用了緩存”的案例考的就是這個(gè)啟發(fā)式規(guī)則。3.2 從輸入U(xiǎn)RL到頁(yè)面展示瀏覽器渲染鏈路中的重繪與重排這類(lèi)題幾乎是國(guó)內(nèi)前端筆試的保留項(xiàng)目但第四范式的考法更傾向于“性能優(yōu)化驅(qū)動(dòng)”它會(huì)給出一段CSS或JS操作代碼要求分析這期間觸發(fā)了哪些重排、哪些重繪以及哪些操作可以合并。關(guān)于重排和重繪我建議你理解到一個(gè)程度就夠了——重排一定會(huì)引起重繪但重繪不一定會(huì)引起重排。改變color、background、box-shadow這些只涉及視覺(jué)表現(xiàn)但不影響布局的屬性只會(huì)觸發(fā)重繪改變width、height、top、left、font-size這些影響元素幾何信息的屬性一定會(huì)觸發(fā)重排reflow然后附帶觸發(fā)重繪repaint。筆試中的經(jīng)典考法是這樣一段代碼const el document.getElementById(box); el.style.width 200px; el.style.height 200px; el.style.margin 10px;如果只寫(xiě)這三行瀏覽器通常會(huì)合并成一次重排。但如果中間穿插了讀取布局屬性的操作比如const el document.getElementById(box); el.style.width 200px; const height el.clientHeight; el.style.height 200px;那么el.clientHeight的讀取會(huì)強(qiáng)制瀏覽器立即執(zhí)行一次布局來(lái)計(jì)算準(zhǔn)確值這就會(huì)導(dǎo)致第一次重排發(fā)生在讀取時(shí)然后修改height又觸發(fā)第二次重排——原本可以被合并的操作被拆成了兩次。這個(gè)知識(shí)點(diǎn)在筆試題里經(jīng)常以“以下哪段代碼的性能更差”的形式出現(xiàn)。答案永遠(yuǎn)是在一次修改和讀取的循環(huán)里“讀取”破壞了瀏覽器的批量渲染優(yōu)化。我當(dāng)年在準(zhǔn)備這類(lèi)知識(shí)點(diǎn)時(shí)在本地用Chrome DevTools的Performance面板跑過(guò)對(duì)比一次批量的屬性修改渲染耗時(shí)可能在幾毫秒但如果循環(huán)里交替進(jìn)行style修改和offsetHeight讀取會(huì)有明顯的Layout次數(shù)飆升。自己動(dòng)手驗(yàn)證過(guò)一次你會(huì)對(duì)“強(qiáng)制同步布局”這個(gè)概念有非常深的記憶遠(yuǎn)比背十遍筆記有效。3.3 Cookie、localStorage與sessionStorage不再只是“都會(huì)用”提到Web存儲(chǔ)大多數(shù)人都知道“l(fā)ocalStorage不會(huì)過(guò)期、sessionStorage關(guān)標(biāo)簽頁(yè)就沒(méi)了、Cookie會(huì)隨請(qǐng)求發(fā)送”。但筆試?yán)锶绻嫉竭@些往往不會(huì)只停留在這一層。關(guān)于Cookie第四范式?？嫉狞c(diǎn)是HttpOnly和Secure標(biāo)志。HttpOnly是為了防止XSS腳本通過(guò)document.cookie讀取敏感會(huì)話信息一旦設(shè)置前端JavaScript就完全無(wú)法訪問(wèn)這個(gè)Cookie。Secure標(biāo)志則要求Cookie只能在HTTPS連接中傳輸如果網(wǎng)站從HTTP跳轉(zhuǎn)到HTTPS這個(gè)Cookie也不會(huì)在第一次HTTP請(qǐng)求中帶上需要在HTTPS連接建立后才能設(shè)置。關(guān)于localStorage筆試題最喜歡考的是它的同步阻塞特性和存儲(chǔ)容量限制。**localStorage的讀寫(xiě)操作是同步的而且發(fā)生在主線程上。**如果你存了一個(gè)很大的JSON字符串頁(yè)面解析時(shí)就會(huì)出現(xiàn)明顯的卡頓。這個(gè)是很多面試官列出“l(fā)ocalStorage缺點(diǎn)”時(shí)最希望聽(tīng)到的點(diǎn)之一——它不僅是容量5MB的問(wèn)題更是同步I/O阻塞渲染的問(wèn)題。sessionStorage和localStorage還有一個(gè)極易被忽略的區(qū)別——它們的隔離粒度不一樣。localStorage在所有同源標(biāo)簽頁(yè)之間共享sessionStorage只存在于單個(gè)標(biāo)簽頁(yè)的會(huì)話中即使在同一個(gè)頁(yè)面里通過(guò)window.open打開(kāi)新標(biāo)簽新標(biāo)簽頁(yè)的sessionStorage也和原來(lái)的不共享。但有一種例外如果新標(biāo)簽頁(yè)是通過(guò)window.open從原頁(yè)面打開(kāi)的并且新頁(yè)面將opener設(shè)為null依然無(wú)法繼承sessionStorage。筆試?yán)锶绻霈F(xiàn)“在新標(biāo)簽頁(yè)中能否訪問(wèn)原頁(yè)面sessionStorage”這類(lèi)判斷題答案取決于打開(kāi)方式。4. Vue框架與前端工程化實(shí)戰(zhàn)能力的分水嶺第四范式2019年前后端筆試題里框架部分以Vue為主——這跟當(dāng)年Vue在國(guó)內(nèi)的普及度以及公司技術(shù)棧的選擇都有關(guān)系。但框架題并不好答因?yàn)樗幌裾Z(yǔ)言基礎(chǔ)題有標(biāo)準(zhǔn)答案閱卷人會(huì)從你的答案里判斷你是“用過(guò)Vue”還是“理解Vue”。4.1 Vue的響應(yīng)式原理從Object.defineProperty到ProxyVue 2的響應(yīng)式原理是筆試題的絕對(duì)高頻考點(diǎn)。核心脈絡(luò)是這樣的Vue在初始化時(shí)會(huì)遞歸遍歷data對(duì)象的所有屬性用Object.defineProperty把它們?nèi)哭D(zhuǎn)成getter和setter。每個(gè)組件實(shí)例對(duì)應(yīng)一個(gè)Watcher當(dāng)組件渲染函數(shù)執(zhí)行時(shí)會(huì)訪問(wèn)模板里用到的數(shù)據(jù)屬性觸發(fā)getter把這個(gè)Watcher收集進(jìn)該屬性的依賴(lài)列表。當(dāng)數(shù)據(jù)發(fā)生變化時(shí)setter會(huì)觸發(fā)依賴(lài)列表里所有Watcher的更新。筆試常見(jiàn)的問(wèn)法是“用Object.defineProperty實(shí)現(xiàn)響應(yīng)式有什么缺陷”答案有兩點(diǎn)。第一它無(wú)法監(jiān)聽(tīng)屬性的新增和刪除所以Vue 2才提供了Vue.set和Vue.delete來(lái)彌補(bǔ)第二它需要遞歸遍歷對(duì)象對(duì)象級(jí)別很深時(shí)初始化性能會(huì)有損耗第三對(duì)于數(shù)組Vue 2只能通過(guò)重寫(xiě)數(shù)組的7個(gè)變更方法來(lái)實(shí)現(xiàn)監(jiān)聽(tīng)直接通過(guò)下標(biāo)修改數(shù)組元素是無(wú)法觸發(fā)響應(yīng)的。到了Vue 3響應(yīng)式底層換成了Proxy。Proxy可以直接代理整個(gè)對(duì)象攔截set、deleteProperty、has、ownKeys等多種操作所以新增、刪除屬性都能被感知也不需要重寫(xiě)數(shù)組方法。但Proxy也并非無(wú)敵它的兼容性不如Object.defineProperty不支持IE11并且如果用Proxy去代理一個(gè)非常大的對(duì)象代理對(duì)象的創(chuàng)建過(guò)程會(huì)比Object.defineProperty更耗時(shí)。Vue 3源碼里為了規(guī)避這一點(diǎn)用了reactive和ref這樣的兩級(jí)響應(yīng)式設(shè)計(jì)深層對(duì)象用了懶代理策略——訪問(wèn)到哪一層才代理哪一層。在筆試?yán)锶绻隳馨堰@些差異點(diǎn)完整寫(xiě)出來(lái)再補(bǔ)一句“Vue 3的懶代理能在初始化時(shí)避免深層對(duì)象全部遞歸”這就能體現(xiàn)你對(duì)源碼實(shí)現(xiàn)層面的理解。4.2 虛擬DOM與diff算法別停留在“快”的層面關(guān)于虛擬DOM筆試?？嫉狞c(diǎn)是“為什么要用虛擬DOM”。最標(biāo)準(zhǔn)的答案是“減少直接操作真實(shí)DOM帶來(lái)的性能消耗”。但如果你能補(bǔ)充“虛擬DOM的真正價(jià)值在于把DOM操作抽象成數(shù)據(jù)層面的變化從而能夠跨平臺(tái)渲染比如服務(wù)端渲染、小程序渲染、原生應(yīng)用渲染都用到了類(lèi)似機(jī)制”會(huì)讓閱卷人覺(jué)得你不是在背面試題。diff算法的核心流程也需要掌握同層比較、深度優(yōu)先。Vue 2的diff過(guò)程是先判斷新舊節(jié)點(diǎn)是否為sameVnode通過(guò)key和tag判斷不是則直接替換是則進(jìn)行patchVnode對(duì)比屬性、更新子節(jié)點(diǎn)。子節(jié)點(diǎn)的更新用的是雙端比較策略頭頭對(duì)比、尾尾對(duì)比、頭尾對(duì)比、尾頭對(duì)比最后再用key做查找復(fù)用。Vue 3的diff算法在此基礎(chǔ)上做了優(yōu)化利用編譯時(shí)的patchFlag標(biāo)記動(dòng)態(tài)節(jié)點(diǎn)跳過(guò)靜態(tài)節(jié)點(diǎn)的比對(duì)大幅減少diff范圍。這個(gè)點(diǎn)如果放在筆試?yán)飼?huì)以“Vue 3為什么比Vue 2快”的形式出現(xiàn)。僅僅說(shuō)“Proxy代替了Object.defineProperty”是不夠的因?yàn)轫憫?yīng)式只是數(shù)據(jù)更新的一部分真正大幅提升更新性能的是編譯階段生成的塊樹(shù)Block Tree和動(dòng)態(tài)節(jié)點(diǎn)標(biāo)記讓diff過(guò)程不必再遍歷整個(gè)模板。我記得有一次和朋友模擬面試問(wèn)“虛擬DOM一定比真實(shí)DOM操作快嗎”他愣了一下。實(shí)際上并不是——在非常小的頁(yè)面里手動(dòng)優(yōu)化過(guò)的DOM操作可能比虛擬DOM更快虛擬DOM的優(yōu)勢(shì)在于將頻繁的DOM操作收斂為內(nèi)存中的計(jì)算再通過(guò)批量patch一次性更新真實(shí)DOM。這種“不穩(wěn)定答案”的題恰恰是這類(lèi)公司最?lèi)?ài)用來(lái)判斷候選人是否有獨(dú)立技術(shù)判斷力的方式。4.3 Webpack構(gòu)建性能與前端工程化AI公司的平臺(tái)需求第四范式這類(lèi)平臺(tái)型公司前端工程化的核心痛點(diǎn)往往在于“大型項(xiàng)目構(gòu)建慢”“多項(xiàng)目復(fù)用難”“私有化部署要求高”。所以筆試?yán)锍霈F(xiàn)Webpack相關(guān)題目一點(diǎn)都不意外。當(dāng)年最常見(jiàn)的問(wèn)法是“打包時(shí)如何減小打包體積” 答案可以從幾個(gè)層面展開(kāi)代碼分割用SplitChunksPlugin把公共依賴(lài)提取成單獨(dú)chunk避免多入口重復(fù)打包。動(dòng)態(tài)導(dǎo)入路由懶加載按需加載頁(yè)面級(jí)代碼塊。壓縮TerserPlugin壓縮JS、MiniCssExtractPlugin提取CSS并壓縮。Tree Shaking依賴(lài)ES Module的靜態(tài)分析能力移除未被使用的導(dǎo)出代碼。externals配置把React、Vue這類(lèi)基礎(chǔ)庫(kù)標(biāo)記為外部依賴(lài)改用CDN加載減少包體體積。而在構(gòu)建性能方面核心技巧包括用cache-loader或Webpack 5的持久化緩存來(lái)緩存模塊編譯結(jié)果用thread-loader或HappyPack老項(xiàng)目做多進(jìn)程構(gòu)建用DllPlugin預(yù)編譯不常變化的第三方庫(kù)。這些方案其實(shí)都是“拿空間換時(shí)間拿緩存換時(shí)間”的思路。筆試?yán)锶绻霈F(xiàn)“如何優(yōu)化開(kāi)發(fā)環(huán)境的構(gòu)建速度”最常見(jiàn)的回答是開(kāi)啟HotModuleReplacement。但如果你能補(bǔ)充一條“開(kāi)發(fā)環(huán)境不會(huì)打包mock數(shù)據(jù)的那部分路由代碼減少模塊解析范圍然后在生產(chǎn)環(huán)境單獨(dú)引入”會(huì)顯得你有實(shí)際調(diào)優(yōu)經(jīng)驗(yàn)而不只是在背文檔。5. 算法與編程題兩大題的思路完全暴露編程功底第四范式畢競(jìng)是一家人工智能公司算法題的地位非同小可。雖然前端崗不會(huì)考動(dòng)態(tài)規(guī)劃、圖論那種地獄難度但基礎(chǔ)的數(shù)據(jù)結(jié)構(gòu)與算法能力是必須展示出來(lái)的。當(dāng)年的算法題大概覆蓋了字符串處理、數(shù)組操作、樹(shù)遍歷和排序搜索這幾類(lèi)。5.1 “手寫(xiě)一個(gè)字符串去重并統(tǒng)計(jì)字符出現(xiàn)次數(shù)”這題可以簡(jiǎn)單到令人懷疑也可以復(fù)雜到寫(xiě)出生產(chǎn)級(jí)代碼。核心考點(diǎn)其實(shí)不是去重而是你是否能寫(xiě)出O(n)時(shí)間、可讀性好、易于擴(kuò)展的解法。比如function countCharacters(str) { const result {}; for (const char of str) { result[char] (result[char] || 0) 1; } return result; }大部分人能走到這一步。但要拿滿分還需要討論幾個(gè)細(xì)節(jié)是否要區(qū)分大小寫(xiě)是否要包含空格如果統(tǒng)計(jì)對(duì)象里的key需要按字母序排列怎么處理這些邊界情況并不是故意刁難而是真實(shí)業(yè)務(wù)中必然要考慮的問(wèn)題。如果你在代碼里主動(dòng)處理了這些情況并在注釋里寫(xiě)清楚假設(shè)條件閱卷人會(huì)認(rèn)為你有工程意識(shí)。5.2 “手寫(xiě)一個(gè)數(shù)組扁平化”數(shù)組扁平化也是一個(gè)經(jīng)典題。最簡(jiǎn)單的方法是遞歸進(jìn)階一點(diǎn)可以用reduce再進(jìn)階一些可以用while配合somefunction flat(arr, depth Infinity) { return arr.reduce((acc, cur) { if (Array.isArray(cur) depth 0) { return acc.concat(flat(cur, depth - 1)); } return acc.concat(cur); }, []); }如果題目允許使用Array.flat當(dāng)然可以直接調(diào)但要寫(xiě)清楚你選擇它的原因。筆試?yán)锔粗氐氖悄隳芊裨诓挥脙?nèi)建方法的情況下實(shí)現(xiàn)并且考慮到“指定扁平化深度”而不是無(wú)腦全部拉平。把這個(gè)深度參數(shù)加進(jìn)來(lái)代碼的魯棒性就上了一個(gè)臺(tái)階。5.3 “手寫(xiě)一個(gè)輕量級(jí)的事件分發(fā)器”這一題我在前文已經(jīng)給過(guò)參考實(shí)現(xiàn)。它在算法題里的變形通常是被包裝成“模擬實(shí)現(xiàn)一個(gè)簡(jiǎn)單的redux中間件機(jī)制”或者“實(shí)現(xiàn)一個(gè)支持異步的觀察者”?？嫉氖悄銓?duì)“發(fā)布訂閱模式核心是解耦”的理解。如果能畫(huà)出一張“事件的發(fā)布、訂閱、取消訂閱”的流程說(shuō)明圖再把once和off的邊界問(wèn)題答清楚算法設(shè)計(jì)模式這一關(guān)基本就能穩(wěn)過(guò)。6. 開(kāi)放設(shè)計(jì)題拉開(kāi)分?jǐn)?shù)差距的“廬山真面目”第四范式筆試題最后往往有一道開(kāi)放設(shè)計(jì)題這道題沒(méi)有標(biāo)準(zhǔn)答案卻能直接看出你的架構(gòu)思維和業(yè)務(wù)理解能力。有一年的大意是請(qǐng)?jiān)O(shè)計(jì)一個(gè)機(jī)器學(xué)習(xí)平臺(tái)的“模型訓(xùn)練任務(wù)詳情頁(yè)”包含訓(xùn)練日志實(shí)時(shí)展示、模型指標(biāo)曲線繪制、任務(wù)狀態(tài)輪詢。你會(huì)怎么設(shè)計(jì)前端的數(shù)據(jù)流、組件結(jié)構(gòu)和性能優(yōu)化策略。這道題里藏了多個(gè)考點(diǎn)。第一個(gè)是任務(wù)狀態(tài)輪詢——不能用setInterval粗暴解決因?yàn)轫?yè)面不可見(jiàn)時(shí)依然會(huì)發(fā)請(qǐng)求浪費(fèi)資源。更合理的方案是使用requestIdleCallback或者結(jié)合visibilitychange事件在頁(yè)面不可見(jiàn)時(shí)暫停輪詢回到頁(yè)面時(shí)立即拉取一次最新數(shù)據(jù)。第二個(gè)是訓(xùn)練日志的實(shí)時(shí)展示——如果直接用v-html渲染日志文本會(huì)有XSS風(fēng)險(xiǎn)正確做法是純文本解析加web worker分詞處理。第三個(gè)是大規(guī)模指標(biāo)曲線的渲染——直接操作SVG或Canvas還是用ECharts這類(lèi)庫(kù)要解釋清楚你的選擇理由并且考慮“數(shù)據(jù)量達(dá)到幾萬(wàn)點(diǎn)時(shí)如何聚合降采樣”。這種情況下比較能拿高分的回答邏輯是這樣的先把狀態(tài)管理方案說(shuō)清楚——任務(wù)詳情頁(yè)用獨(dú)立store包含任務(wù)狀態(tài)機(jī)排隊(duì)中、運(yùn)行中、成功、失敗、終止。再講數(shù)據(jù)更新策略——訓(xùn)練日志用WebSocket或者定時(shí)輪詢并結(jié)合虛擬滾動(dòng)渲染長(zhǎng)日志。接著說(shuō)性能優(yōu)化——曲線圖用Canvas渲染離線聚合數(shù)據(jù)后再按需加載。最后補(bǔ)充異常處理——網(wǎng)絡(luò)斷開(kāi)時(shí)如何重連、失敗狀態(tài)如何讓用戶重試、日志文件過(guò)大時(shí)如何服務(wù)端分片。如果只是把組件結(jié)構(gòu)劃分出來(lái)比如“頭部信息區(qū)、日志區(qū)、指標(biāo)區(qū)、操作按鈕”這是基礎(chǔ)分真正拉開(kāi)差距的地方在于你對(duì)數(shù)據(jù)流、性能邊界、異常恢復(fù)的思考。我當(dāng)時(shí)給朋友的建議是遇到這類(lèi)題不要一上來(lái)就寫(xiě)組件樹(shù)先用幾句話定義“核心狀態(tài)有哪些”再定義“每個(gè)狀態(tài)如何更新”最后才考慮“組件如何展示”。這套思考方式能讓你在有限時(shí)間內(nèi)向閱卷人展示出“系統(tǒng)設(shè)計(jì)”能力而不是“畫(huà)原型圖”能力。7. 當(dāng)年答完這套題后我做了什么復(fù)盤(pán)我雖然沒(méi)參加那一年第四范式的筆試但一直有把各家題沉淀成知識(shí)圖譜的習(xí)慣。筆試結(jié)束后我會(huì)把自己踩過(guò)的坑和從別人那里收集到的共性問(wèn)題整理成一張自檢清單方便后續(xù)查漏補(bǔ)缺。這里分享一份針對(duì)AI公司前端筆試的通用復(fù)習(xí)體系語(yǔ)言基礎(chǔ)閉包、作用域、this指向、原型鏈、事件循環(huán)、ES6新特性必須做到能用自己的話講清楚每一條底層規(guī)則。瀏覽器與網(wǎng)絡(luò)緩存策略、渲染鏈路、重排重繪、Web安全XSS、CSRF、跨域方案每塊都要有對(duì)應(yīng)的實(shí)驗(yàn)驗(yàn)證。框架原理選一個(gè)你使用最深的框架把它的響應(yīng)式、diff、生命周期、組件通信全部讀到源碼注釋級(jí)別。工程化Webpack核心配置、構(gòu)建優(yōu)化、前端性能監(jiān)控、代碼規(guī)范與自動(dòng)化測(cè)試這些都是平臺(tái)型公司的日常。數(shù)據(jù)結(jié)構(gòu)與算法數(shù)組、字符串、鏈表、棧、隊(duì)列、二叉樹(shù)的基本操作加上常用排序和搜索能達(dá)到國(guó)內(nèi)大廠筆試入門(mén)線即可。開(kāi)放題找到自己熟悉的業(yè)務(wù)場(chǎng)景提前準(zhǔn)備一到兩個(gè)“從設(shè)計(jì)到落地的完整方案”并練習(xí)在十分鐘內(nèi)講清楚。這套體系不必一次性全部塞進(jìn)腦子里但筆試前至少要把前四項(xiàng)過(guò)一遍后兩項(xiàng)根據(jù)自己的情況取舍。如果你正在準(zhǔn)備這類(lèi)公司的前端筆試我想說(shuō)一句如果你在考場(chǎng)上遇到一兩道完全沒(méi)見(jiàn)過(guò)的題先不要慌。這類(lèi)公司考的不是你的題庫(kù)覆蓋率而是你在有限時(shí)間內(nèi)拿到一個(gè)陌生問(wèn)題后如何拆解、如何分析、如何把“不會(huì)”轉(zhuǎn)化為“可以從哪些角度去推”。把一道開(kāi)放題答出邏輯推進(jìn)感比把五道背誦題寫(xiě)滿更能讓閱卷人記住你。