去年年初我動(dòng)了換工作的念頭前后斷斷續(xù)續(xù)面了十幾家公司從十幾人的小團(tuán)隊(duì)到一線大廠的業(yè)務(wù)線都聊過。一年經(jīng)驗(yàn)去面試處境其實(shí)挺微妙你說自己是新人吧已經(jīng)脫離了校招的池子你說自己有經(jīng)驗(yàn)吧又遠(yuǎn)夠不著高級(jí)前端的門檻。面試官自己可能都在糾結(jié)該拿什么標(biāo)準(zhǔn)來考你。這篇文章就把我這一年經(jīng)驗(yàn)求職過程中被問過的高頻問題、踩過的坑、以及事后復(fù)盤總結(jié)出來的準(zhǔn)備方法整理出來給同樣處在這個(gè)階段的朋友做個(gè)參考。我不想寫成那種 XX面試題大全 的收藏貼而是想聊聊更實(shí)際的東西一年經(jīng)驗(yàn)在面試中到底被怎么定位、八股文要背到什么程度、項(xiàng)目經(jīng)驗(yàn)怎么講才不像是流水賬、手寫題和場景題的思路怎么練。這些都直接關(guān)系到你能不能把這一年的積累在面試中充分展示出來。1. 一年經(jīng)驗(yàn)到底被面試官怎么定位——先搞清楚游戲規(guī)則一年經(jīng)驗(yàn)這個(gè)階段面試官對(duì)你的預(yù)期其實(shí)很明確能獨(dú)立承接需求有基本的工程素養(yǎng)遇到問題有自我驅(qū)動(dòng)力去解決并且有成長潛力。他們不指望你現(xiàn)在就能做架構(gòu)設(shè)計(jì)也不指望你能搞定疑難雜癥但前提是——基礎(chǔ)得扎實(shí)項(xiàng)目得是真的自己做的講得出細(xì)節(jié)。我一開始沒想明白這件事前期面試準(zhǔn)備完全是按資深前端的標(biāo)準(zhǔn)去啃源碼、啃算法結(jié)果基礎(chǔ)題反而翻車了幾次。后來才反應(yīng)過來一年經(jīng)驗(yàn)的面試更像是在驗(yàn)證下限你是不是真的寫過一年代碼還是在公司打了一年雜。面試官會(huì)通過基礎(chǔ)題確認(rèn)你的知識(shí)體系有沒有漏洞通過項(xiàng)目追問確認(rèn)你的產(chǎn)出真實(shí)性和思考深度通過手寫題確認(rèn)你的代碼功底。1.1 一年經(jīng)驗(yàn) vs 應(yīng)屆生 vs 三年經(jīng)驗(yàn)考察重心完全不同我把這幾個(gè)階段的考察差異整理成了一張表方便大家對(duì)號(hào)入座考察維度應(yīng)屆生一年經(jīng)驗(yàn)三年經(jīng)驗(yàn)基礎(chǔ)知識(shí)概念是否了解概念 場景應(yīng)用原理 邊界條件框架會(huì)調(diào)用API能講清原理大致流程能讀源碼、能封裝項(xiàng)目課程設(shè)計(jì) / 實(shí)習(xí)內(nèi)容真實(shí)業(yè)務(wù) 你的角色系統(tǒng)設(shè)計(jì) 技術(shù)決策代碼題LeetCode簡單/中等手寫常見JS方法 基礎(chǔ)算法復(fù)雜場景設(shè)計(jì) 性能優(yōu)化系統(tǒng)設(shè)計(jì)基本不考簡單場景設(shè)計(jì)完整方案 擴(kuò)展性考量從這張表能看出來一年經(jīng)驗(yàn)正好卡在一個(gè)中間態(tài)。面試官不會(huì)用校招標(biāo)準(zhǔn)只考你知道不知道也不會(huì)用社招高級(jí)標(biāo)準(zhǔn)考你架構(gòu)能力有多強(qiáng)。他們真正想知道的是你在真實(shí)業(yè)務(wù)里有沒有獨(dú)立解決問題的經(jīng)歷。所以準(zhǔn)備策略就清晰了八股文不能只背概念必須每個(gè)知識(shí)點(diǎn)都能接一句這個(gè)在我項(xiàng)目里是這樣的……項(xiàng)目經(jīng)驗(yàn)不能只列功能清單必須能講清楚為什么這么做手寫題不能只背答案必須能處理邊界情況和追問。1.2 簡歷關(guān)項(xiàng)目描述決定你有沒有面試機(jī)會(huì)一年經(jīng)驗(yàn)投簡歷最吃虧的就是項(xiàng)目看起來像打雜。負(fù)責(zé)XX模塊的開發(fā)、參與XX系統(tǒng)的迭代這種描述HR和面試官一天能看幾百份根本留不下印象。我改簡歷前后的面試邀約率差距非常大核心變化就是把做了什么改成解決了什么問題、用了什么方案、帶來了什么結(jié)果。舉個(gè)例子同樣是寫一個(gè)后臺(tái)管理系統(tǒng)改前負(fù)責(zé)后臺(tái)管理系統(tǒng)的用戶管理模塊開發(fā)和維護(hù)。改后針對(duì)后臺(tái)用戶管理模塊權(quán)限混亂的問題基于RBAC模型設(shè)計(jì)了動(dòng)態(tài)路由和按鈕級(jí)權(quán)限控制方案將越權(quán)操作工單量降低約40%。第二版明顯更能勾起面試官的興趣因?yàn)閷?duì)方可以從里面挖出一連串可追問的點(diǎn)RBAC模型你具體怎么設(shè)計(jì)的動(dòng)態(tài)路由怎么掛載的按鈕級(jí)權(quán)限是前端控制還是后端控制這些追問恰恰是你展示真實(shí)項(xiàng)目經(jīng)驗(yàn)的機(jī)會(huì)。簡歷上技術(shù)棧的寫法也注意一下。不要只寫熟練使用Vue/React盡量標(biāo)出你在這個(gè)技術(shù)棧下做過的具體事比如基于Vue3 TypeScript開發(fā)了可配置化表單引擎、基于React Hooks封裝了通用請(qǐng)求狀態(tài)管理工具。技術(shù)點(diǎn)要能經(jīng)得起追問簡歷上寫到的每一項(xiàng)都要準(zhǔn)備好被深挖。2. 基礎(chǔ)八股文的真實(shí)火力范圍——哪些必背、哪些可以放一年經(jīng)驗(yàn)被問到的八股文范圍其實(shí)比想象中要收斂。面試官不會(huì)拿冷門偏題難為你翻來覆去就是那些高頻考點(diǎn)。但難點(diǎn)在于——你不能只會(huì)背定義得能講出場景、講出原理、接得住追問。我根據(jù)自己的面試經(jīng)歷和身邊朋友的反饋整理了下面這個(gè)高頻考點(diǎn)表標(biāo)注了一年前端應(yīng)該掌握到的深度考點(diǎn)分類具體內(nèi)容一年經(jīng)驗(yàn)應(yīng)有的深度JS基礎(chǔ)閉包、作用域鏈、this、原型鏈能說出概念 至少一個(gè)實(shí)際應(yīng)用場景異步編程事件循環(huán)、宏任務(wù)/微任務(wù)、Promise、async/await能現(xiàn)場分析一段代碼的輸出順序?yàn)g覽器渲染流程、重排重繪、緩存機(jī)制能講出頁面性能優(yōu)化的具體手段網(wǎng)絡(luò)HTTP緩存、跨域、HTTPS握手、WebSocket能講清原理 知道業(yè)務(wù)中怎么排查問題CSS布局、BFC、選擇器優(yōu)先級(jí)、移動(dòng)端適配能解決實(shí)際問題 解釋原因工程化Webpack/Vite基礎(chǔ)、模塊化、代碼規(guī)范能配置、能說出構(gòu)建流程大致過程2.1 JS基礎(chǔ)八股閉包、事件循環(huán)、this 都要能接到業(yè)務(wù)上閉包幾乎是必問的。光是背出函數(shù)執(zhí)行完后作用域不被銷毀這層概念已經(jīng)不夠了面試官多半會(huì)追問一句你項(xiàng)目里哪里用到了閉包。我用的回答思路是這樣在組件庫開發(fā)中用閉包實(shí)現(xiàn)一個(gè)只有內(nèi)部才能訪問的私有狀態(tài)或者用閉包做函數(shù)防抖把定時(shí)器ID緩存起來。只要能證明你不是在背概念而是真的在代碼里用過這個(gè)特性這題就過關(guān)了。事件循環(huán)的建議準(zhǔn)備方式是找?guī)锥未a自己做輸出預(yù)測練習(xí)。比如console.log(script start); setTimeout(() { console.log(setTimeout); }, 0); Promise.resolve().then(() { console.log(promise1); }).then(() { console.log(promise2); }); console.log(script end);這種題能答對(duì)只是及格面試官還會(huì)繼續(xù)加問為什么Promise的回調(diào)會(huì)在setTimeout之前輸出宏任務(wù)和微任務(wù)在什么階段被消費(fèi)這時(shí)候需要把事件循環(huán)的完整流程講一遍執(zhí)行同步代碼 → 清空微任務(wù)隊(duì)列 → 取一個(gè)宏任務(wù)執(zhí)行 → 再清空微任務(wù)隊(duì)列。用這個(gè)模型去套上面這段代碼輸出順序就很清楚了。關(guān)于this與其背四條規(guī)定不如理解函數(shù)被調(diào)用時(shí)決定this指向這句話。箭頭函數(shù)本身沒有this所以它的this繼承自定義時(shí)的外層作用域普通函數(shù)的this看調(diào)用方式bind/apply/call可以顯式綁定。面試常考的連環(huán)題基本都是從這個(gè)原點(diǎn)推導(dǎo)出來的。2.2 CSS和瀏覽器渲染定位和性能問題最常被問到盒模型、BFC、flex布局這些屬于送分題但有兩塊內(nèi)容一年經(jīng)驗(yàn)反而容易翻車移動(dòng)端適配和渲染性能。移動(dòng)端適配被問到的概率很高面試官通常不會(huì)直接問rem和vw有什么區(qū)別而是給一個(gè)場景設(shè)計(jì)稿是750寬你要適配不同尺寸的手機(jī)方案怎么選這個(gè)問題的答法可以分三層先說viewport設(shè)置是基礎(chǔ)再說rem方案依賴根元素字號(hào)配合postcss-pxtorem做自動(dòng)轉(zhuǎn)換最后說vw/vh更直觀但要注意兼容性和最小字體限制。能把這些方案的優(yōu)缺點(diǎn)和取舍講清楚比單純背概念要加分得多。渲染性能這一塊核心是重排和重繪改樣式觸發(fā)重繪、改布局觸發(fā)重排、重排必然導(dǎo)致重繪。面試官如果追問頁面滾動(dòng)很卡怎么排查可以從三個(gè)方向答減少重排的樣式操作比如用transform替代top/left、用requestAnimationFrame做動(dòng)畫節(jié)流、對(duì)高頻事件scroll/resize做防抖節(jié)流。這些如果平時(shí)有過真實(shí)的性能排查經(jīng)驗(yàn)講出來會(huì)讓面試官覺得你不是只會(huì)背書的類型。2.3 網(wǎng)絡(luò)題緩存是重點(diǎn)跨域和鑒權(quán)跟著項(xiàng)目走HTTP緩存在我面過的公司里被問到概率接近100%而且經(jīng)常配一道場景題你的頁面接口返回?cái)?shù)據(jù)偶爾是舊的怎么排查這類問題的分析思路是固定的先看響應(yīng)頭里有沒有Cache-Control有沒有ETag/Last-Modified強(qiáng)緩存命中就不會(huì)發(fā)請(qǐng)求如果發(fā)了請(qǐng)求但用舊數(shù)據(jù)說明協(xié)商緩存邏輯有問題可能是后端返回的資源沒帶正確的ETag前端能做的是在靜態(tài)資源URL上加hash參數(shù)或者在接口請(qǐng)求里加隨機(jī)參數(shù)繞過緩存。這個(gè)排查鏈路能講完整基本就是面試官想要的答案?？缬騿柕靡捕?。JSONP、CORS預(yù)檢、反向代理devServer proxy / nginx這三個(gè)方案一定要能各講出一段適用場景。比如為什么開發(fā)環(huán)境用proxy就行生產(chǎn)環(huán)境反而得后端配CORS或網(wǎng)關(guān)處理——因?yàn)闉g覽器攔截的是請(qǐng)求響應(yīng)不是請(qǐng)求發(fā)出代理服務(wù)器轉(zhuǎn)發(fā)就沒有跨域限制。鑒權(quán)這一塊一年經(jīng)驗(yàn)通常不會(huì)被問得太深但token存在哪里這種經(jīng)典問題要準(zhǔn)備好。localStorage和cookie的取舍、為什么推薦httpOnly的cookie方案可以防XSS竊取、token過期后怎么用refreshToken續(xù)期——這些如果能結(jié)合自己項(xiàng)目的登錄流程講出來屬于明顯的加分項(xiàng)。3. 框架題不再是背API——React和Vue問到哪一層一年經(jīng)驗(yàn)去面試框架這塊的問題明顯和校招不一樣了。校招問Vue的生命周期有哪些一年經(jīng)驗(yàn)會(huì)問你和后端聯(lián)調(diào)時(shí)接口請(qǐng)求放在哪個(gè)生命周期/鉤子里為什么、組件更新時(shí)如何避免多余的渲染。這說明面試官默認(rèn)你會(huì)用框架現(xiàn)在考察的是你理解不理解框架運(yùn)作的背后邏輯。3.1 ReactHooks原理和渲染優(yōu)化是兩大核心React崗位一面基本不離Hooks。useState、useEffect、useMemo、useCallback這幾個(gè)要能講出源碼層面的原理和實(shí)際場景。useEffect最常見的追問是為什么不能在里面直接寫async函數(shù)這個(gè)問題的本質(zhì)是React要求在effect回調(diào)里返回一個(gè)清理函數(shù)或undefined而async函數(shù)返回的永遠(yuǎn)是一個(gè)Promise。面試官真正想通過這個(gè)問題考察你有沒有仔細(xì)讀過報(bào)錯(cuò)信息、理解React對(duì)effect執(zhí)行時(shí)機(jī)的約束。渲染優(yōu)化是另一個(gè)重點(diǎn)。面試官會(huì)問一個(gè)很實(shí)際的問題父組件重新渲染時(shí)子組件也跟著渲染了但子組件的數(shù)據(jù)沒有變化怎么優(yōu)化答案核心是React.memo和useMemo/useCallback。但比答案更重要的是你是否理解memo只做淺比較這件事——如果props里傳的是對(duì)象字面量或箭頭函數(shù)memo就失效了所以必須配合useMemo和useCallback來保證引用不變。這一條鏈路能講清楚說明你是真的在用React而不是只會(huì)搭頁面。虛擬DOM和diff算法被問到的頻率也很高。一年經(jīng)驗(yàn)不需要把源碼里每個(gè)函數(shù)都背出來但至少要能講清楚為什么需要虛擬DOM跨平臺(tái) 批量更新、diff算法的大致流程同層比較、key的作用、為什么key不要用index列表增刪時(shí)可能導(dǎo)致節(jié)點(diǎn)復(fù)用錯(cuò)亂。3.2 Vue響應(yīng)式原理和編譯優(yōu)化是加分項(xiàng)Vue崗位會(huì)被問到Vue2和Vue3響應(yīng)式原理的區(qū)別。Object.defineProperty 監(jiān)聽的是對(duì)象屬性所以Vue2里新增屬性不會(huì)觸發(fā)更新需要Vue.set而Proxy代理的是整個(gè)對(duì)象可以攔截屬性增刪和in操作符。能把這個(gè)區(qū)別講清楚再引申到Vue3為什么性能更好的問題上就很有說服力了。computed和watch的區(qū)別也是高頻題。核心區(qū)別在于computed有緩存、支持依賴追蹤、適合做派生狀態(tài)watch更偏向命令式地監(jiān)聽變化后執(zhí)行副作用。我一般用一個(gè)例子說明購物車?yán)锷唐房們r(jià)用computed因?yàn)橹灰唐妨斜砘騿蝺r(jià)不變總價(jià)就不需要重新計(jì)算而監(jiān)聽路由參數(shù)變化去做數(shù)據(jù)請(qǐng)求用watch更合適。nextTick的實(shí)現(xiàn)原理、keep-alive的作用、slot的作用域問題這些如果簡歷里寫了會(huì)用到相關(guān)項(xiàng)目都值得準(zhǔn)備。整體思路就是不要只背nextTick是異步更新DOM后執(zhí)行回調(diào)要能說出Vue的DOM更新是異步批量的所以修改數(shù)據(jù)后不能立刻拿到最新DOM需要nextTick。3.3 微前端和組件庫一年經(jīng)驗(yàn)也被問的工程化話題我在面試中被問到過微前端當(dāng)時(shí)很意外因?yàn)楦杏X微前端適合中大團(tuán)隊(duì)玩我們小團(tuán)隊(duì)怎么會(huì)用到。后來越來越多公司問這個(gè)問題其實(shí)是想考察你對(duì)團(tuán)隊(duì)協(xié)作、多應(yīng)用管理的理解。微前端核心要能講清楚三件事為什么需要不同團(tuán)隊(duì)維護(hù)不同技術(shù)棧的應(yīng)用、獨(dú)立部署、增量遷移、常見方案是什么qiankun基于single-spa的JS沙箱和樣式隔離、module federation的運(yùn)行時(shí)共享依賴、拆分的粒度怎么控制主應(yīng)用只做導(dǎo)航和注冊(cè)子應(yīng)用獨(dú)立開發(fā)部署。如果實(shí)際沒做過可以說技術(shù)選型調(diào)研階段我了解過xxx方案但千萬別編。組件庫相關(guān)的問題問得也很多尤其是簡歷里寫了封裝過通用組件的話。面試官大概率會(huì)追著問你封裝的組件怎么設(shè)計(jì)API、怎么處理受控和非受控、樣式方案是怎么做的。這些沒有標(biāo)準(zhǔn)答案但要有自己的設(shè)計(jì)思路。我通常按這個(gè)框架答先分析業(yè)務(wù)里高頻出現(xiàn)的UI模式抽象出基礎(chǔ)組件API設(shè)計(jì)上支持默認(rèn)值、暴露事件回調(diào)、支持自定義插槽/children樣式用CSS變量做主題定制而非每個(gè)組件寫死顏色。4. 項(xiàng)目經(jīng)驗(yàn)怎么講才不會(huì)變成流水賬——STAR法則和亮點(diǎn)提煉項(xiàng)目經(jīng)驗(yàn)是面試的重頭戲也是最容易講砸的部分。我早期面試犯的典型錯(cuò)誤是把項(xiàng)目從頭到尾按功能模塊講一遍我做了用戶管理、我做了訂單列表、我做了報(bào)表導(dǎo)出面試官聽完面無表情完全沒有追問的欲望。后來我才意識(shí)到項(xiàng)目經(jīng)驗(yàn)的目標(biāo)不是讓面試官知道你做了什么功能而是讓他通過你的講述評(píng)價(jià)你解決問題的能力和技術(shù)判斷力。正確的方法是用STAR法則組織背景Situation、任務(wù)Task、行動(dòng)Action、結(jié)果Result。更重要的是講的過程中要有意識(shí)地埋技術(shù)亮點(diǎn)引導(dǎo)面試官往你準(zhǔn)備好的方向上追問。4.1 項(xiàng)目案例大文件上傳用Web Worker每一步都要能講出為什么如果簡歷里寫過基于Web Worker實(shí)現(xiàn)大文件上傳面試官大概率會(huì)抓住不放。這個(gè)案例我完整講一遍我的準(zhǔn)備模板背景業(yè)務(wù)里用戶需要上傳幾百M(fèi)B的視頻文件原來直接上傳會(huì)導(dǎo)致頁面卡死、失敗率很高。任務(wù)設(shè)計(jì)一個(gè)不阻塞UI的大文件上傳方案。行動(dòng)上分四步第一步文件分片。用file.slice按固定大小比如5MB切分文件分片列表管理上傳進(jìn)度。為什么分片一是大文件整體上傳一旦失敗就要重傳分片后可以單獨(dú)重試失敗的分片二是瀏覽器對(duì)單個(gè)請(qǐng)求體大小有限制分片能規(guī)避。第二步計(jì)算文件哈希。為了支持?jǐn)帱c(diǎn)續(xù)傳和秒傳需要給文件算一個(gè)唯一標(biāo)識(shí)。哈希計(jì)算是CPU密集型的幾GB的文件在主線程算會(huì)把頁面卡死。所以這里放到Web Worker里做。Worker里用SparkMD5庫計(jì)算主線程只接收進(jìn)度更新并渲染進(jìn)度條。第三步并發(fā)控制。如果幾百個(gè)分片同時(shí)上傳瀏覽器會(huì)建立大量TCP連接反而拖慢速度甚至報(bào)錯(cuò)。實(shí)現(xiàn)上用一個(gè)簡單的并發(fā)池控制同時(shí)上傳的分片數(shù)量比如限制同時(shí)5個(gè)。這里可以提一下怎么處理上傳失敗的分片失敗隊(duì)列 自動(dòng)重試重試次數(shù)超過3次就標(biāo)記失敗允許用戶手動(dòng)點(diǎn)擊重試。第四步斷點(diǎn)續(xù)傳。把已經(jīng)上傳成功的分片索引存到localStorage或IndexedDB里。用戶中斷后再次選擇同一個(gè)文件通過哈希比對(duì)只上傳未完成的分片。結(jié)果上傳失敗率從原來的15%降到2%左右大文件上傳時(shí)頁面操作依然流暢。結(jié)果要有數(shù)字最好沒有數(shù)字就講頁面在計(jì)算哈希的過程中不再卡死這種對(duì)比感受。這套方案講完面試官通常會(huì)追問Web Worker和主線程怎么通信、postMessage傳遞的是什么類型的數(shù)據(jù)、為什么不用Service Worker做、并發(fā)控制具體怎么實(shí)現(xiàn)。都需要提前準(zhǔn)備一輪。4.2 基礎(chǔ)功能也能講出深度以字典管理為例有一次面試官問系統(tǒng)管理下的字典管理一般有啥用我一開始覺得很基礎(chǔ)差點(diǎn)回答得很敷衍。后來整理答案的時(shí)候才發(fā)現(xiàn)這個(gè)題其實(shí)可以答出很多層次。第一層講清字典是什么把性別、狀態(tài)、類型這類業(yè)務(wù)枚舉值從代碼中抽離出來統(tǒng)一維護(hù)在數(shù)據(jù)庫或配置文件中前端根據(jù)字典類型拉取選項(xiàng)列表。第二層講清它解決的問題產(chǎn)品改文案不用發(fā)版、不同端共用一套枚舉、權(quán)限和翻譯統(tǒng)一處理。第三層講代碼層面會(huì)做哪些事封裝字典Hooks或組件把字典加載、緩存、翻譯邏輯收斂在同一個(gè)模塊里提升加載速度用緩存或預(yù)取考慮字典變更時(shí)的刷新策略?；A(chǔ)功能講出業(yè)務(wù)理解和工程化思考比講一堆花哨技術(shù)更能反映真實(shí)水平。面試官真正想知道的是你做了這個(gè)功能有沒有想過為什么這么做、還能怎么做得更好。4.3 追問怎么扛技術(shù)選型的理由和取舍項(xiàng)目經(jīng)驗(yàn)里最怕的就是被問到你為什么用這個(gè)方案。比如用Web Worker做哈希面試官可能追問用requestIdleCallback在主線程分片計(jì)算行不行、直接用文件內(nèi)容做hash的一部分但只讀取首尾幾MB做抽樣hash行不行。這種問題沒有絕對(duì)的對(duì)錯(cuò)考察的是你有沒有想過方案的邊界。我的經(jīng)驗(yàn)是任何一個(gè)技術(shù)選型都要準(zhǔn)備至少兩個(gè)備選方案和它們各自的優(yōu)缺點(diǎn)。用技術(shù)選型對(duì)比的思路去講比單點(diǎn)講我用了什么要穩(wěn)得多。比如上傳并發(fā)控制手寫并發(fā)池 vs 使用p-limit庫。手寫能更靈活控制失敗重試邏輯但需要自己測試各種邊界p-limit經(jīng)過了大量生產(chǎn)環(huán)境驗(yàn)證但想定制特定行為時(shí)不一定滿足。斷點(diǎn)續(xù)傳的存儲(chǔ)localStorage vs IndexedDB。localStorage簡單但容量只有5MB存幾百個(gè)分片索引可能不夠IndexedDB容量大、支持異步讀寫但API更復(fù)雜。哈希計(jì)算SparkMD5全量計(jì)算 vs 抽樣計(jì)算。全量計(jì)算準(zhǔn)確率高但耗時(shí)抽樣計(jì)算快但存在不同文件算出相同哈希的風(fēng)險(xiǎn)。每一條都能展開講上兩三分鐘而且會(huì)讓面試官覺得你有技術(shù)判斷力。5. 手寫題與場景設(shè)計(jì)題——面試官真正想看的思維過程手寫題是面試中翻車率最高的環(huán)節(jié)。倒不是因?yàn)轭}有多難而是很多候選人背答案背得太機(jī)械一被追問邊界條件就露餡。面試官要考察的從來不是你背過這道題而是你在現(xiàn)場能不能像寫業(yè)務(wù)代碼一樣結(jié)構(gòu)清晰、考慮周全地把一個(gè)函數(shù)實(shí)現(xiàn)出來。5.1 高頻手寫題的正確練習(xí)姿勢我把一年經(jīng)驗(yàn)遇到的高頻手寫題分成三類每一類說下準(zhǔn)備建議第一類是工具函數(shù)防抖節(jié)流、深拷貝、數(shù)組去重、數(shù)組拍平、函數(shù)柯里化。這類題的核心是邊界條件。拿深拷貝舉例很多人能寫遞歸版本但面試官追問循環(huán)引用怎么辦就卡住。正確做法是引入WeakMap作為緩存已經(jīng)拷貝過的對(duì)象直接返回緩存中的引用還要考慮Date、RegExp這類非普通對(duì)象以及Symbol屬性是否需要拷貝。答案要求不是能跑而是生產(chǎn)環(huán)境可用的代碼。第二類是Promise相關(guān)手寫Promise.all、Promise.race、Promise.allSettled。這類題核心是理解Promise的狀態(tài)機(jī)pending → fulfilled / rejected狀態(tài)一旦改變就不可逆。寫Promise.all時(shí)要注意傳入的參數(shù)可能不是Promise數(shù)組需要先用Promise.resolve統(tǒng)一包裝任何一個(gè)reject都要讓整個(gè)all走reject分支結(jié)果數(shù)組要保持和輸入相同的順序。第三類是設(shè)計(jì)模式或原理模擬發(fā)布訂閱EventEmitter、實(shí)現(xiàn)一個(gè)簡單的響應(yīng)式系統(tǒng)。這類題考察的是對(duì)框架底層原理的理解。比如實(shí)現(xiàn)響應(yīng)式系統(tǒng)思路是defineProperty/Proxy攔截get和setget時(shí)收集依賴set時(shí)觸發(fā)更新。能把這個(gè)流程寫出來配合Vue3響應(yīng)式原理一起講效果會(huì)很好。5.2 場景設(shè)計(jì)題的基本框架從權(quán)限系統(tǒng)說起場景設(shè)計(jì)題不是系統(tǒng)設(shè)計(jì)那種大而全的架構(gòu)設(shè)計(jì)而是給你一個(gè)小而具體的業(yè)務(wù)需求看你能不能給出一個(gè)完整的前端落地方案。一年經(jīng)驗(yàn)最常見的是設(shè)計(jì)一個(gè)按鈕級(jí)權(quán)限控制方案。我的回答框架分四步第一步定義權(quán)限模型。常見的是RBAC基于角色的訪問控制用戶 → 角色 → 權(quán)限。前端拿到的是當(dāng)前用戶的權(quán)限碼列表比如 [user:add, user:delete]。第二步權(quán)限碼的生成和后端接口對(duì)接。后端登錄接口返回權(quán)限碼或角色前端存到狀態(tài)管理里。需要考慮權(quán)限變化了怎么刷新token過期重新登錄后權(quán)限怎么重新拉取第三步前端如何控制。按鈕級(jí)權(quán)限一般用自定義指令Vue的v-permission或HOCReact的withPermission包裹內(nèi)部判斷權(quán)限碼列表里是否有目標(biāo)權(quán)限。動(dòng)態(tài)路由則是根據(jù)權(quán)限過濾路由表后addRoute掛載。第四步安全邊界。要明確指出前端控制按鈕只是用戶體驗(yàn)層面的手段真正的安全校驗(yàn)必須后端再做一道。如果面試官追問用戶通過瀏覽器控制臺(tái)直接調(diào)接口怎么辦要能接住接口層面必須做鑒權(quán)前端只是不可依賴的展示層優(yōu)化。5.3 一道完整的設(shè)計(jì)題走一遍前端告警通知中心有一次面試官讓我現(xiàn)場設(shè)計(jì)一個(gè)前端告警通知中心從需求梳理到落地方案。這類題沒有標(biāo)準(zhǔn)答案但考察的是你拆解問題的能力。我當(dāng)時(shí)的回答結(jié)構(gòu)通知類型全局頂部提示、站內(nèi)信列表、郵件/短信等外部通知。每一類的展示形式和對(duì)用戶的打擾程度不同。實(shí)時(shí)性站內(nèi)信和頂部提示需要實(shí)時(shí)性。實(shí)現(xiàn)方案有WebSocket長連接、SSEServer-Sent Events、輪詢?nèi)N。我重點(diǎn)對(duì)比了WebSocket和SSEWebSocket全雙工、適合雙向通信比如聊天SSE是單向服務(wù)端推送、基于HTTP、自動(dòng)重連、斷線續(xù)傳更簡單。通知中心只需要服務(wù)端推送給前端用SSE更輕量。但如果業(yè)務(wù)里已經(jīng)有WebSocket基礎(chǔ)設(shè)施也可以復(fù)用。未讀已讀前端維護(hù)消息狀態(tài)調(diào)用接口標(biāo)記已讀。未讀數(shù)字可以放在全局狀態(tài)管理里接收新消息時(shí)自增點(diǎn)擊查看后調(diào)接口并減對(duì)應(yīng)數(shù)量。這里要處理多標(biāo)簽頁同步如果用戶開了兩個(gè)標(biāo)簽頁一個(gè)已讀了另一個(gè)未讀數(shù)怎么同步可以用BroadcastChannel或storage事件跨標(biāo)簽頁通信。消息列表的分頁和滾動(dòng)加載一般是分頁加載下拉加載更多要求高的場景用虛擬列表。一年經(jīng)驗(yàn)?zāi)苤v到分頁就夠虛擬列表可以提一句了解原理。高頻消息的節(jié)流如果服務(wù)端一次性推過來幾十條告警不能全部彈頂部提示否則用戶會(huì)被打擾。需要節(jié)流策略比如2秒內(nèi)最多彈出1條其余消息只進(jìn)列表和未讀計(jì)數(shù)。這個(gè)題被認(rèn)可不是因?yàn)槲业姆桨赣卸喔呒?jí)而是我把問題拆成了幾個(gè)明確的小模塊每一塊都有實(shí)現(xiàn)思路和取舍理由。場景設(shè)計(jì)題考察的正是這種結(jié)構(gòu)化思考能力。6. 綜合面與HR面——能力之外的決定性因素技術(shù)面過了之后綜合面和HR面往往被很多人忽視但實(shí)際上這一關(guān)也會(huì)刷人而且刷得莫名其妙。一年經(jīng)驗(yàn)的候選人最常見的失敗原因集中在離職原因給面試官留下負(fù)面印象、職業(yè)規(guī)劃說得太空、期望薪資完全沒依據(jù)。6.1 離職原因和職業(yè)規(guī)劃怎么回答不踩雷離職原因的核心原則只有一條不要在面試中表達(dá)對(duì)前公司的負(fù)面情緒。加班太多、領(lǐng)導(dǎo)不行、技術(shù)太舊這類說法哪怕說的是事實(shí)在面試官聽來也會(huì)變成這個(gè)人來了之后也可能這樣說我。更安全的說法是圍繞個(gè)人成長和技術(shù)方向來展開比如我希望接觸更大規(guī)模的前端工程化實(shí)踐現(xiàn)在的項(xiàng)目體量已經(jīng)到瓶頸了。職業(yè)規(guī)劃這個(gè)問題一年經(jīng)驗(yàn)的回答重點(diǎn)要落在未來1-2年能在這個(gè)崗位做些什么。不要說我打算三年內(nèi)做架構(gòu)師這種空話。更務(wù)實(shí)的說法是短期先把當(dāng)前技術(shù)棧做深希望能參與團(tuán)隊(duì)的基礎(chǔ)設(shè)施建設(shè)比如組件庫、工程化工具鏈中期希望能獨(dú)立負(fù)責(zé)一條業(yè)務(wù)線的前端技術(shù)方案。聽起來有目標(biāo)但又不顯得浮躁。6.2 期望薪資一年經(jīng)驗(yàn)的合理報(bào)價(jià)邏輯期望薪資沒有固定數(shù)字要結(jié)合你當(dāng)前的薪資基數(shù)、跳槽的漲幅空間、所在城市的行情來報(bào)。一年經(jīng)驗(yàn)跳槽合理的漲幅區(qū)間通常在15%-30%之間除非你面試表現(xiàn)特別突出或者同時(shí)手握多個(gè)offer可以競價(jià)。報(bào)價(jià)的策略是先給區(qū)間再解釋區(qū)間背后的理由。比如我目前是月薪12k一年下來大約14薪?；诋?dāng)前市場和我面試的崗位復(fù)雜度我期望在15k以上。這樣既給了空間又說明了數(shù)字不是亂報(bào)的。如果HR壓價(jià)可以問清楚薪資結(jié)構(gòu)——固定薪資、績效占比、年終獎(jiǎng)規(guī)則這些因素都要考慮進(jìn)去。6.3 反問環(huán)節(jié)問什么能讓面試官覺得你靠譜反問環(huán)節(jié)最怕冷場和問出敏感話題。加班多不多這種問題不是不能問但最好不要在第一輪就問容易讓面試官覺得你優(yōu)先考慮的是摸魚而不是做事。更推薦問的是這個(gè)崗位進(jìn)來后前三個(gè)月最需要解決的問題是什么——展示你的目標(biāo)感。團(tuán)隊(duì)目前前端最大的技術(shù)挑戰(zhàn)是什么——展示你對(duì)技術(shù)方向的關(guān)注。這個(gè)崗位之前的人是什么原因離開的——這個(gè)要謹(jǐn)慎看面試官狀態(tài)問得好能了解很多信息。反問環(huán)節(jié)的核心是讓面試官覺得你在認(rèn)真評(píng)估這個(gè)機(jī)會(huì)是否合適而不是單純?cè)谡夜ぷ?。工作一年多去面試我自己的體會(huì)是這一年積累的技術(shù)深度和項(xiàng)目經(jīng)驗(yàn)在面試中能不能被看見取決于你怎么組織、怎么表達(dá)。面試本質(zhì)上是一場“展示思維過程”的游戲——八股文背后是知識(shí)的扎實(shí)程度項(xiàng)目經(jīng)驗(yàn)背后是解決問題的真實(shí)經(jīng)歷手寫題背后是代碼的工程素養(yǎng)。與其焦慮“我經(jīng)驗(yàn)不夠”不如先把自己的項(xiàng)目好好梳理一遍把每一個(gè)技術(shù)選型的理由都想清楚。最后分享一個(gè)小技巧每次面試結(jié)束趁記憶還熱乎把被問到的問題記錄下來標(biāo)出哪些答得好、哪些卡殼了。卡殼的地方就是下一次需要補(bǔ)的方向。面了五六家之后你會(huì)發(fā)現(xiàn)自己對(duì)高頻問題的回答越來越順因?yàn)槟切﹩栴}翻來覆去就那么多。面試不僅是找一個(gè)新工作也是逼自己把過去一年的積累重新整理一遍的過程——不管結(jié)果如何這個(gè)整理本身就很值。