2019年那時候奇安信還沒有從360體系里完全獨立出來多久春招筆試的題目風格其實已經(jīng)很有辨識度了。我印象里那套前端開發(fā)試題整體難度中等偏上不算變態(tài)但覆蓋面很廣基礎不扎實的人很容易在及格線附近徘徊。今天把這套題掰開揉碎講一講不只是給答案更重要的是講清楚每一類題目背后的考察邏輯和備考思路。不管你是準備應屆生校招還是社招想跳槽去安全行業(yè)的技術團隊這套題里的知識點都值得過一遍。1. 試題整體印象怎么看懂一套前端筆試題的“出題人意圖”拿到任何一套筆試題先別急著埋頭做題。我習慣先花五分鐘把整張卷子掃一遍標出題目類型和分值分布這時候出題人的“口味”基本就暴露了。1.1 奇安信2019春招前端卷的題型構成從整體來看這套題大致分為四個板塊基礎理論題、代碼輸出題、手寫實現(xiàn)題和開放設計題?；A理論題覆蓋HTML、CSS、JavaScript、瀏覽器原理和網(wǎng)絡基礎代碼輸出題主要考察JavaScript的語言特性比如作用域、閉包、異步順序手寫實現(xiàn)題則集中在數(shù)組去重、深拷貝、防抖節(jié)流這類經(jīng)典場景開放設計題會給你一個業(yè)務場景讓你描述技術方案。這種結構說明什么說明奇安信的前端團隊在招人時非常看重候選人的語言基本功和工程思維而不是看你背了多少框架API。那一年Vue和React已經(jīng)非常流行了但這套題里框架相關的考點占比并不高反而基礎能力占了大頭。這和當時很多大廠的出題風格是反著來的——當時不少公司一上來就問Vue生命周期、React diff算法的細節(jié)。后來我復盤了一下這個思路其實和奇安信的業(yè)務屬性高度相關。安全公司做的前端產(chǎn)品比如管理后臺、態(tài)勢感知大屏、終端管控界面絕大多數(shù)時候不是面向海量C端用戶的而是面向企業(yè)客戶和安全運維人員的。這類產(chǎn)品對穩(wěn)定性、數(shù)據(jù)準確性、安全性要求極高花里胡哨的交互反而是次要的。所以面試官更在意你能不能寫出靠譜的代碼而不是能不能背出某個框架的源碼細節(jié)。1.2 這套題的備考價值在哪兒哪怕你不是去奇安信面試這套題的參考價值也很大。原因很簡單它考察的知識點全部是前端領域“保值率”最高的那部分。反而是那些當年很熱門的框架題放到今天可能早就過時了。ES6語法、事件循環(huán)、原型鏈、HTTP緩存、跨域方案這些內(nèi)容今天依然是前端面試的絕對主力。所以如果你現(xiàn)在正在準備前端面試與其漫無目的地刷題不如拿這套題當一次自測。能把這套題做到80分以上至少說明你的JS基礎是過關的面對大多數(shù)公司的筆試環(huán)節(jié)都不會太虛。2. HTML與CSS考點安全公司會在布局題里埋什么坑很多人對HTML和CSS題不以為然覺得就是背背標簽、記記屬性。但實際上奇安信這類公司的前端筆試里CSS題的陷阱往往藏得很深。2.1 盒模型與BFC不只是概念題盒模型是CSS的第一課但能把content-box和border-box的區(qū)別講透的人并不多。標準盒模型content-box的width只包含內(nèi)容區(qū)而IE盒模型border-box的width包含內(nèi)容、內(nèi)邊距和邊框。實際開發(fā)里我們普遍通過box-sizing: border-box來統(tǒng)一全局盒模型因為這樣更符合人腦直覺——你設置多大的寬度元素就占多大的寬度。BFC塊級格式化上下文同樣是高頻考點。BFC可以理解為一個獨立的渲染區(qū)域內(nèi)部元素的布局不會影響外部。觸發(fā)BFC的方式有float非none、position為absolute或fixed、overflow非visible、display為inline-block或flex等。常見的應用場景有兩個一是清除浮動當子元素全部浮動導致父容器高度塌陷時給父容器設置overflow: hidden觸發(fā)BFC父容器就會重新包裹子元素二是防止 margin 折疊兩個兄弟元素的上下margin在垂直方向會取較大值合并但把它們各自放進獨立的BFC里就可以避免折疊。這里有個實操經(jīng)驗真正做后臺管理系統(tǒng)的時候overflow: hidden觸發(fā)BFC來清除浮動這個方案在新老瀏覽器上表現(xiàn)都不錯但也有副作用——如果子元素需要溢出顯示下拉菜單會被父容器裁掉。所以現(xiàn)代項目里我一般優(yōu)先用display: flow-root或者直接改用flex布局這兩種方式干凈利落。2.2 經(jīng)典布局題圣杯布局與雙飛翼布局圣杯布局和雙飛翼布局是CSS筆試的常青樹它們要解決的核心問題是一樣的左右兩欄固定寬度中間主內(nèi)容欄自適應寬度且中間欄在DOM結構上優(yōu)先渲染這對首屏加載和SEO友好。圣杯布局的思路是三欄都用float: left中間欄寬度設為100%然后利用padding為左右欄騰出位置。左右兩欄通過負margin移動到對應位置——左欄margin-left: -100%讓它上移到中間欄的左側起點右欄margin-left: -自身寬度讓它上移到最右側。最后給三欄的父容器設置左右padding寬度等于左右欄的寬度。雙飛翼布局則換了個思路中間欄內(nèi)部再套一層div左右兩欄的定位方式和圣杯一樣但為中間欄內(nèi)容騰位置時不用父容器的padding而是給中間欄內(nèi)部那層div設置左右margin。這樣父容器寬度就是100%左右欄直接貼在兩側省去了相對定位的步驟。實際筆試里這種題不一定要求你手寫完整代碼更多是讓你說清楚實現(xiàn)思路和區(qū)別。但我的建議是哪怕不寫完整代碼也要把這個過程推導清楚同時提一句“現(xiàn)在都用flex或grid實現(xiàn)了”這樣面試官會覺得你既懂老方案也跟得上新趨勢。2.3 垂直水平居中的N種姿勢垂直水平居中幾乎每次筆試都會出現(xiàn)而且出題人常常會補一句“元素高度未知”。這個限制條件很關鍵它排除了line-height和絕對定位配合負margin的方案。我一般會給面試官按場景分類元素定寬高絕對定位 四角為0 margin: auto這個方案兼容性最好不定寬高絕對定位 transform: translate(-50%, -50%)用CSS3解決唯一注意父容器要相對定位flex方案父元素display: flex; align-items: center; justify-content: center;這是當前項目里的首選代碼量最少grid方案父元素display: grid; place-items: center;更簡潔。實話說現(xiàn)在項目里我從來不給彈窗用transform居中而是直接用flex。因為transform會創(chuàng)建新的層疊上下文有時候會連帶出z-index和定位問題。筆試寫方案的時候可以提一句“flex最穩(wěn)transform有層疊上下文副作用”這種細節(jié)會讓你跟其他候選人明顯拉開差距。3. JavaScript核心考點輸出題背后藏著多少語言特性JS部分永遠是前端筆試的主導奇安信也不例外。這套題里代碼輸出題占比不低而且專門挑那些“看似簡單一寫就錯”的語法糖來考。3.1 作用域、閉包和立即執(zhí)行函數(shù)經(jīng)典題目var在for循環(huán)中配合setTimeout打印的問題。連續(xù)輸出10個10原因在于var聲明是函數(shù)作用域循環(huán)體里的i是同一個變量等到定時器回調執(zhí)行時循環(huán)早已結束i已經(jīng)變成了10。解決辦法有兩個用let聲明讓每一次循環(huán)都綁定一個新的i或者用立即執(zhí)行函數(shù)IIFE傳遞當前值。閉包在奇安信這類基礎題里幾乎是必考的。比如問你以下代碼輸出什么function foo() { let count 0; return function () { count; console.log(count); }; } const f foo(); f(); f();答案是1, 2。核心考點是內(nèi)部函數(shù)引用了外部函數(shù)的變量外部函數(shù)執(zhí)行結束后變量沒有被垃圾回收而是被內(nèi)部函數(shù)繼續(xù)持有。這也解釋了為什么閉包可能造成內(nèi)存泄漏——如果你在DOM事件里用了閉包又忘了移除事件綁定整個作用域鏈都會殘留。3.2 this的指向問題別背口訣畫調用棧this指向是JS筆試的重災區(qū)也是很多工作兩三年的前端說不清的地方。出題人很愛把this和對象調用、普通函數(shù)調用、箭頭函數(shù)混在一起出題比如const obj { name: qihoo, getName: function () { return this.name; }, getNameArrow: () { return this.name; }, }; console.log(obj.getName()); console.log(obj.getNameArrow());第一行輸出qihoo沒問題this指向調用者obj。第二行就有意思了箭頭函數(shù)沒有自己的this它的this是在定義時從外部作用域捕獲的所以這里的this指向全局對象this.name是undefined。我不建議死記“誰調用指向誰”這種口訣因為遇到箭頭函數(shù)這口訣立刻就失效了。更好的分析方式是先把函數(shù)調用方式畫出來看它是普通調用、對象方法調用、call/apply調用還是new調用然后逐層確定this如果函數(shù)是箭頭函數(shù)直接往上找最近的外層普通函數(shù)的this。這套邏輯可以應對所有this考題。3.3 事件循環(huán)與異步順序輸出題里最能拉開差距的就是事件循環(huán)。比如考這樣的代碼console.log(a); setTimeout(() { console.log(b); }, 0); Promise.resolve().then(() { console.log(c); }); console.log(d);輸出順序是a d c b。這里考察的微任務和宏任務執(zhí)行順序同步代碼先執(zhí)行然后本輪事件循環(huán)中的微任務Promise的then回調優(yōu)先于宏任務setTimeout回調執(zhí)行。即使setTimeout的延遲是0它也會被放進宏任務隊列要等下一輪事件循環(huán)才輪到。2019年的考題還很少問到async/await和微任務嵌套的復雜情況但現(xiàn)在這里已經(jīng)成了必考深水區(qū)。我的建議是把事件循環(huán)的機制徹底搞清楚執(zhí)行棧清空后微任務隊列會一次性清空然后再取一個宏任務執(zhí)行宏任務執(zhí)行過程中又會產(chǎn)生新的微任務這些微任務會排在下一次宏任務之前執(zhí)行。把這條鏈路理解透不管題目怎么嵌套你都不會懵。3.4 對象與數(shù)組方法map、filter、reduce的熟用程度數(shù)組方法題在筆試題里也經(jīng)常出現(xiàn)。比如[1, 2, 3].map(parseInt)的輸出是什么答案是[1, NaN, NaN]。原因是parseInt接收兩個參數(shù)map回調會把當前值和索引傳進去所以第二次調用是parseInt(2, 1)第三次是parseInt(3, 2)都是無效進制返回NaN。這類題考察的不是你會不會用map而是你清不清楚map回調的完整參數(shù)列表當前值、索引、原數(shù)組以及parseInt的完整參數(shù)簽名字符串、進制基數(shù)。所以平時寫代碼多留意標準API的完整簽名少依賴記憶中的“常用方式”這種坑踩一次就能記住。4. 框架與工程化考點安全公司也躲不開的范疇雖然前面說這套題基礎占比大但框架和工程化的內(nèi)容也沒有缺席。尤其是在開放題和應用題里Vue/React的使用經(jīng)驗是加分項。4.1 Vue與React從“會寫頁面”到“說清原理”筆試中常見的框架問題有Vue的雙向綁定原理、虛擬DOM的作用、key的作用、組件通訊方式、生命周期鉤子對比。React的常見考點則是state與props的區(qū)別、setState的異步性、受控組件與非受控組件、 useState/useEffect的依賴數(shù)組、Fiber架構解決了什么問題。奇安信前臺產(chǎn)品偏管理類和展示類Vue的普及率在我印象里比React高一些所以Vue出題概率更大。重點準備這幾個問題computed和watch的區(qū)別computed是聲明式地根據(jù)依賴數(shù)據(jù)計算出新值有緩存watch是監(jiān)聽數(shù)據(jù)變化執(zhí)行副作用操作用于異步或開銷較大的操作。v-if和v-show的區(qū)別v-if是條件渲染不滿足條件直接不渲染DOM切換有渲染銷毀成本v-show是css的display切換只是視覺隱藏適合頻繁切換的場景。key的作用key幫助diff算法識別節(jié)點復用當列表順序變化時正確的key可以最小化DOM操作。不建議用數(shù)組索引當key因為增刪元素后索引會變可能導致狀態(tài)錯亂。4.2 前端性能優(yōu)化筆試愛問實際項目更要會安全產(chǎn)品的前端頁面往往數(shù)據(jù)量大、圖表多、刷新頻繁性能優(yōu)化是實際問題。筆試里的性能優(yōu)化題通常不要求你寫代碼但要求你按場景列出方案。我通常會按瀏覽器工作流程來組織答案網(wǎng)絡層面做資源壓縮合并、HTTP緩存、CDN分發(fā)渲染層面減少DOM操作次數(shù)避免強制同步回流用文檔碎片或虛擬列表處理長列表代碼層面做按需加載和懶加載拆分首屏代碼優(yōu)化圖片格式和尺寸。這里有一個很多人的誤區(qū)一說性能優(yōu)化就在扣JS執(zhí)行時間但實際上首屏性能的大頭通常在資源加載和網(wǎng)絡請求。2019年我優(yōu)化一個數(shù)據(jù)中心管理后臺時把十幾個第三方依賴全部改為按需引入首屏體積從2.4M降到800K加載時間從5秒變成2秒左右這個收益遠大于優(yōu)化幾個函數(shù)執(zhí)行耗時。所以面試時一定要先說網(wǎng)絡和加載層面的優(yōu)化再說渲染和運行時的優(yōu)化這更符合真實場景的優(yōu)先級。4.3 工程化工具鏈webpack問題怎么答不露怯工程化題偶爾會考webpack的構建流程、loader和plugin的區(qū)別、如何做代碼分割。這類題其實有個答題模板先說整個構建過程是入口解析、依賴收集、模塊編譯、代碼生成這幾個階段loader負責對模塊源代碼進行轉換是在編譯單個模塊時執(zhí)行plugin則在整個構建流程里都可以介入通過鉤子機制完成更廣泛的任務。只要把base流程說清楚然后舉一兩個常用的loader和plugin例子比如babel-loader處理ES6、eslint-loader做代碼檢查、HtmlWebpackPlugin生成HTML、TerserPlugin做代碼壓縮基本就能過關。5. 安全公司面試的隱藏彩蛋前端安全題才是重頭戲奇安信做的是安全業(yè)務前端筆試題里幾乎一定會出現(xiàn)安全相關的考點。這既是奇安信面試的特色也是非安全公司面試容易忽略的盲區(qū)。把這塊準備好你能給面試官留下極其深刻的印象。5.1 XSS攻擊與防御別只知道alert彈窗XSS跨站腳本攻擊是前端安全里最經(jīng)典的考點?；驹硎枪粽甙褠阂饽_本注入到頁面中當其他用戶訪問這個頁面時腳本在用戶瀏覽器中執(zhí)行從而盜取Cookie、篡改頁面內(nèi)容或者發(fā)起請求。防御手段有三個層次。第一層是輸入過濾用戶輸入的內(nèi)容一律當作數(shù)據(jù)而非代碼處理前端要對特殊字符做轉義比如替換為lt;替換為gt;第二層是輸出編碼在不同上下文HTML標簽內(nèi)、屬性內(nèi)、JavaScript內(nèi)要用不同的編碼方式第三層是設置安全響應頭比如Content-Security-PolicyCSP可以限制頁面能加載的資源和腳本來源就算腳本被注入也執(zhí)行不了。5.2 CSRF與CORS跨域問題的安全視角CSRF跨站請求偽造的經(jīng)典場景是用戶登錄了銀行網(wǎng)站又去訪問了惡意網(wǎng)站惡意網(wǎng)站利用瀏覽器自動攜帶Cookie的特性構造一個跨站請求讓用戶在不知情的情況下完成轉賬或修改操作。防御CSRF的思路主要有校驗請求頭中的Origin或Referer用token機制——后端生成一個隨機token存到表單或請求頭里服務器驗證token是否有效設置Cookie的SameSite屬性限制跨站請求是否攜帶Cookie用自定義請求頭因為跨站請求無法自動構造自定義頭。CORS跨域資源共享和CSRF容易混淆但考點完全不同。CORS是瀏覽器對外部請求的一種協(xié)議規(guī)范當頁面請求了其他域的接口瀏覽器會先發(fā)起預檢請求OPTIONS服務器通過響應頭里的Access-Control-Allow-Origin來聲明是否允許跨域。前端開發(fā)中常見的跨域方案除了CORS外還有JSONP、代理服務器等。有一道題讓我印象很深題目問的是“前端做了CORS配置能徹底解決跨域安全問題嗎”。正確答案當然是不能。CORS只是瀏覽器層面的訪問控制接口本身是否安全還需要后端做鑒權驗證。你能在理解CORS的同時指出這個邊界面試官會明顯高看你一眼。5.3 路徑遍歷與文件上傳場景熱詞里提到了“奇安信 輸入驗證路徑遍歷”這個知識點同樣會出現(xiàn)在筆試題甚至實際產(chǎn)品中。路徑遍歷是指攻擊者通過構造../這樣的特殊路徑訪問服務器上本不該被訪問的文件。前端在接收文件上傳、下載參數(shù)時一定要對路徑參數(shù)做白名單校驗不能直接拼接用戶輸入到文件路徑里。比如下載文件的接口如果后端拿到的文件名參數(shù)是../../etc/passwd拼接路徑后就可能讀取到系統(tǒng)敏感文件。前端的責任是上傳文件時校驗文件類型限制文件大小對文件名做合法性校驗下載文件時不要把用戶輸入直接作為路徑參數(shù)傳遞而是建議后端用映射ID來定位文件。6. 手寫實現(xiàn)題這些代碼現(xiàn)在就可以背下來手寫題是筆試里最能直接反映編碼能力的一環(huán)。說實話這部分題是有套路的核心題型不多練熟了就是送分題。但如果沒練過現(xiàn)場寫很容易翻車。6.1 數(shù)組去重至少給出三種思路數(shù)組去重是最經(jīng)典的手寫題也是我當年筆試的第一道手寫題?，F(xiàn)在回想起來這道題的關鍵不是寫出來而是寫得全面、有層次。最樸素的方案是雙重循環(huán)或使用indexOf做去重時間復雜度較高。用Set是最簡潔的方案一行代碼搞定[...new Set(arr)]。但面試官往往不希望你就此打住還會追問如果數(shù)組里有對象Set去重還靠譜嗎這時候要答到Array.from(new Set(arr.map(item JSON.stringify(item))))來對對象序列化后去重或者用reduce配合Map來做按屬性去重。我寫題時的習慣是先說清楚各種方案的優(yōu)缺點再選一種代碼量適中的方案寫上。除非題目明確要求性能最優(yōu)否則不要一上來就寫奇技淫巧。6.2 深拷貝考你會不會考慮邊界情況深拷貝題的高頻程度不用多說。手寫一個遞歸深拷貝看起來簡單但能拿滿分的人不多?；A版本是判斷值類型和引用類型值類型直接返回引用類型創(chuàng)建新對象后遞歸復制屬性。但要注意幾個邊界數(shù)組和對象要分別處理要防止循環(huán)引用否則會棧溢出函數(shù)的特殊處理不算重點但要說清楚。比較穩(wěn)妥的寫法是function deepClone(obj, map new WeakMap()) { if (obj null || typeof obj ! object) return obj; if (map.has(obj)) return map.get(obj); const result Array.isArray(obj) ? [] : {}; map.set(obj, result); for (const key in obj) { if (Object.prototype.hasOwnProperty.call(obj, key)) { result[key] deepClone(obj[key], map); } } return result; }這里用WeakMap來處理循環(huán)引用是關鍵點。很多人寫深拷貝不考慮循環(huán)引用一遇到a.self a這種結構就爆棧。能主動想到用WeakMap處理這個問題這道題基本穩(wěn)了。6.3 防抖和節(jié)流應用場景比代碼本身更重要防抖debounce和節(jié)流throttle也是手寫題里的?？?。防抖的核心是“延遲執(zhí)行”在事件觸發(fā)后的一段時間內(nèi)如果再次觸發(fā)就重新計時適用于輸入框搜索聯(lián)想、窗口resize后的計算節(jié)流的核心是“限制執(zhí)行頻率”一段時間內(nèi)只執(zhí)行一次適用于滾動加載、按鈕連點、拖拽等場景。一個比較完整的防抖實現(xiàn)是function debounce(fn, delay, immediate false) { let timer null; return function (...args) { if (immediate !timer) fn.apply(this, args); if (timer) clearTimeout(timer); timer setTimeout(() { fn.apply(this, args); timer null; }, delay); }; }注意這里用apply綁定this并且...args接收參數(shù)這兩個細節(jié)很多培訓班出來的候選人都會漏。如果面試官讓你說應用場景別只說搜索輸入可以補充一個“請求取消”的場景用戶快速點擊多個篩選條件時只保留最后一個請求結果既能防止重復請求也能避免舊請求覆蓋新請求。6.4 其他高頻手寫題清單除了上面幾道下面是2019年前后前端筆試中出現(xiàn)頻率很高的手寫題建議每道題都能做到10分鐘內(nèi)獨立寫出可運行版本實現(xiàn)一個new操作符實現(xiàn)Function.prototype.call/apply/bind實現(xiàn)一個Promise.all實現(xiàn)一個簡單的發(fā)布訂閱EventEmitter實現(xiàn)instanceof的底層邏輯實現(xiàn)一個簡單的Object.create洗牌算法Fisher-Yates手寫一個簡單的MVVM響應式系統(tǒng)這些題目雖然看著多但其實是相互關聯(lián)的。比如Promise.all的核心是理解Promise的執(zhí)行和狀態(tài)流轉EventEmitter的核心是維護一個事件回調數(shù)組。把底層邏輯想明白代碼寫出來就是水到渠成的事。7. 時間分配與答題策略筆試比的不只是會多少一套筆試題做下來很多人掛掉的原因不是不會而是來不及做。筆試的時間分配直接決定你的得分上限。7.1 拿到卷子先做這三件事第一快速瀏覽全卷把所有題目分成“秒殺題”“思考題”“硬骨頭”三類。第二先把秒殺題做完并檢查一遍保證拿滿基礎分。第三再去做思考題最后進攻硬骨頭。不要把時間耗在某一題上比如深拷貝寫了一半卡住就先跳到下一題最后再回來補。我見過不少人在一道手寫題上死磕了30分鐘結果后面10道基礎選擇題全沒做。這種策略性失誤完全可以通過考前模擬來避免。建議考前自己卡著時間做兩套完整的真題或高質量模擬題別只看題不解題。7.2 代碼題的“過程分”怎么拿手寫題即使寫不出來完整答案也要把自己的思路分步驟寫下來。比如深拷貝寫不出來你寫了“先判斷類型然后遞歸復制注意循環(huán)引用”三行字也能拿一部分過程分。更聰明的做法是在注釋里寫清楚思路然后寫出一個不完美但思路正確的版本——筆試批卷人更看重你解決問題的思維路徑而不是最后的代碼是否一字不差。另外手寫題的代碼格式一定要干凈。變量命名合理、縮進統(tǒng)一、函數(shù)抽取清晰這些細節(jié)都能加分。別小看這些印象分在水平接近的候選人里代碼風格好的往往優(yōu)先進面試。7.3 安全公司的筆試復習重點既然目標公司是安全行業(yè)除了常規(guī)前端知識一定要多花時間看安全和業(yè)務結合的部分。我的建議是準備一個“安全場景下的前端項目經(jīng)驗”故事比如你曾經(jīng)處理過登錄表單的輸入校驗、給文件上傳接口做過類型和尺寸校驗、用CSP增強過頁面的安全性或者改過接口的鑒權邏輯防止越權訪問。把這些真實經(jīng)歷整理成一小段有背景、有舉措、有結果的描述比背十個面試題模板都管用。8. 那些年我踩過的筆試坑和回頭看的心得現(xiàn)在回頭看看2019年的前端筆試再對照這些年帶團隊的面試經(jīng)歷有些心得值得和還在準備筆試的你說一說。8.1 筆試掛掉最常見的三個原因第一基礎題不仔細讀題。很多題目不是不會是題眼沒看到。比如題目要求用ES5實現(xiàn)防抖你上來就用let、箭頭函數(shù)直接扣分。第二手寫題只看邏輯不看邊界。代碼在正常輸入下沒問題但一遇到空數(shù)組、空對象、循環(huán)引用就崩了這種代碼在工程化標準里是過不了評審的。第三框架經(jīng)驗寫得太滿基礎一塌糊涂。筆試就是一面照妖鏡你平時靠框架和工具掩蓋的知識盲區(qū)在基礎題面前全都會現(xiàn)原形。8.2 從面試官視角看什么樣的候選人能過我后來也參與過校招筆試的出題和閱卷站在面試官的角度我會優(yōu)先看三樣東西一是代碼的完整性邊界條件和異常處理有沒有考慮二是思路的清晰度即使題目沒完全做出來注釋和流程描述也能看出思考過程三是對安全相關的意識哪怕筆試沒有專門的安全題候選人在回答性能優(yōu)化、跨域問題時能否主動提到安全風險這會讓我覺得這個候選人很契合公司業(yè)務。8.3 給正在準備前端筆試的你的實操建議如果你現(xiàn)在是準備階段我建議你做兩件事。第一件把本文提到的所有手寫題全部寫一遍寫到不需要思考就能默寫的程度。筆試現(xiàn)場是有時間壓力的如果這些基礎題你在腦子清醒時都不能秒寫現(xiàn)場環(huán)境會更糟。第二件找一個有經(jīng)驗的前端幫你做一次模擬面試讓他用這套題的類型抽考你重點看你能不能邊說思路邊寫代碼而不是默默寫完。很多筆試掛掉的人不是不會寫是不敢在時間壓力下寫這個問題只能靠模擬場景來克服。這組題放在今天依然不過時因為它考的從來不是某個特定版本的框架API而是你對前端底層的理解深度。這份理解力一旦建立不管面哪家公司筆試環(huán)節(jié)都不會對你構成真正的阻礙。