愛奇藝2019秋招前端方向筆試題A在網(wǎng)上已經(jīng)傳了好幾年但每次拿出來看都不過時。原因很簡單這份卷子考的不是“背答案”而是前端基礎(chǔ)功底的扎實程度以及遇到陌生問題時怎么拆解、怎么推導(dǎo)。我自己在做這份題的過程中最大的感受就是——它把JS的語言特性、瀏覽器運行機(jī)制、CSS布局原理、網(wǎng)絡(luò)協(xié)議常識、代碼手寫能力這幾個維度全部串在了一起。如果你正在準(zhǔn)備大廠前端崗的筆試或者已經(jīng)工作但想系統(tǒng)復(fù)盤一下基礎(chǔ)這份題都是一個很好的試金石。這篇內(nèi)容我會按照筆試題的高頻模塊來拆解把每類題目背后的考點、原理、踩坑點都展開講最后附上一些實戰(zhàn)經(jīng)驗。1. 內(nèi)容整體設(shè)計與思路拆解1.1 核心考點拆解愛奇藝這套前端筆試題A的考察范圍基本可以映射到大多數(shù)中大型互聯(lián)網(wǎng)公司前端筆試的經(jīng)典結(jié)構(gòu)JavaScript語言特性、CSS布局與渲染、瀏覽器與網(wǎng)絡(luò)、手寫代碼與邏輯題。它不會直接問“閉包是什么”這種八股而是通過讀代碼寫輸出、補(bǔ)全代碼、判斷執(zhí)行順序等方式考察你是否真正理解這些特性。這套卷子里最值得注意的是把“輸出順序題”和“原型/繼承題”作為重點。這類題在?？途W(wǎng)上特別常見但很多人刷題只是記答案不去追“為什么”。比如一道經(jīng)典的setTimeout與Promise輸出順序題如果你不理解微任務(wù)和宏任務(wù)的執(zhí)行時機(jī)、不理解事件循環(huán)的每一輪都會“先清空微任務(wù)隊列”那換一個變體就必錯。愛奇藝的題也有這個風(fēng)格喜歡在細(xì)節(jié)上做文章一個選項里的小括號位置都會影響整個邏輯。另外CSS部分不會直接考“flex怎么用”而是給一個布局需求讓你寫屬性或者給你一段代碼問最終渲染居中還是歪了。這說明考點是“實際場景下能不能正確地使用屬性”不是背單詞。而 HTML 語義化、BFC、層疊上下文這些雖然老但依然會反復(fù)出現(xiàn)——因為這些直接決定了頁面的可維護(hù)性和渲染表現(xiàn)。1.2 為什么大廠筆試偏愛這類題型很多人疑惑前端平時寫業(yè)務(wù)都是 Vue/React為什么筆試不考框架核心原因是框架迭代太快語言和瀏覽器才是恒定的底層。Vue 3 的源碼、React 的調(diào)度機(jī)制本質(zhì)上都是基于 JS 語言特性和瀏覽器 API 來實現(xiàn)的。如果一個候選人連var和let的區(qū)別、和的轉(zhuǎn)換規(guī)則都說清楚那讓他上手框架也得靠猜。愛奇藝作為視頻巨頭前端團(tuán)隊要面對播放器、首屏渲染、流量控制、廣告投放、頁面性能優(yōu)化等高復(fù)雜度場景。這些場景非常依賴對事件循環(huán)、DOM 操作代價、緩存策略、網(wǎng)絡(luò)請求調(diào)度的深入理解。所以筆試出題方向天然偏向這些基礎(chǔ)能力。同時筆試題也篩掉“只會調(diào)接口寫頁面”的候選人。前端崗位的競爭早就白熱化了單純會“調(diào)庫”“會用組件”已經(jīng)不夠。企業(yè)需要一個候選人能解釋“為什么頁面卡”、能定位“為什么這個按鈕點擊后延遲反饋”、能設(shè)計“如何減少不必要的渲染”。這些全得靠基礎(chǔ)功底。所以做這份題與其說是應(yīng)付面試不如說是一次自我體檢。2. 核心細(xì)節(jié)解析與實操要點2.1 JavaScript 基礎(chǔ)考點從執(zhí)行上下文到閉包JS 部分最核心的幾塊執(zhí)行上下文與作用域鏈、閉包、this 指向、原型鏈、Event Loop、ES6 新特性。愛奇藝這類大廠筆試很少直接考概念更多是給代碼問輸出所以關(guān)鍵是要學(xué)會“模擬執(zhí)行過程”。一個常見題型是var a 1; function foo() { console.log(a); var a 2; } foo();輸出是什么答案是undefined。原因是var聲明會提升到函數(shù)作用域頂部所以函數(shù)內(nèi)的a在打印時已經(jīng)被定義但還沒有賦值。這就叫變量提升。很多人只看答案覺得簡單但換成let就會變成ReferenceError因為let存在暫時性死區(qū)TDZ。閉包題往往結(jié)合循環(huán)for (var i 0; i 3; i) { setTimeout(function() { console.log(i); }, 100); }輸出是3 3 3。原因是var沒有塊級作用域setTimeout回調(diào)里訪問的是同一個i而循環(huán)結(jié)束時i已經(jīng)是 3。把var改成let或者用 IIFE、bind、閉包包一層才能輸出0 1 2。這背后實際上就是作用域捕獲的時機(jī)問題也是筆試?yán)镒畛ＴO(shè)的坑。關(guān)于 this 指向我給大家一個最實用的判斷口訣“函數(shù)被誰調(diào)用this 就指向誰”。但還要記住例外箭頭函數(shù)沒有自己的 this它繼承外層詞法作用域的 thisnew調(diào)用的時候 this 指向新對象call/apply/bind可以顯式指定 this。筆試題里最常見的套路是var obj { name: a, fn: function() { console.log(this.name); } }; var f obj.fn; f();這段輸出undefined嚴(yán)格模式下或全局對象屬性而不是a。因為f()調(diào)用時調(diào)用者是全局對象不是obj。這類題考察的是“引用丟失”問題在 React 類組件時代經(jīng)常出現(xiàn)現(xiàn)在寫函數(shù)組件也偶爾會遇到類似場景。2.2 CSS 與瀏覽器渲染盒模型、BFC、層疊上下文CSS 部分不能只靠“用過 flex”。筆試題會重點考察標(biāo)準(zhǔn)盒模型和 IE 盒模型的區(qū)別、外邊距折疊、BFC 的形成條件與作用、層疊上下文、水平垂直居中方案、flex 的 flex-grow/shrink 計算。盒模型這道基礎(chǔ)題每次筆試出現(xiàn)率都極高。box-sizing: content-box時width只算內(nèi)容寬度border-box時width包含內(nèi)容、內(nèi)邊距和邊框。實際開發(fā)時設(shè)置全局* { box-sizing: border-box; }可以減少大量寬高計算麻煩。這一點在筆試題里往往通過“問某個元素的實際占位寬度”來考。BFC 是一塊硬骨頭但記住“BFC 是一個獨立的渲染區(qū)域內(nèi)外互相不影響”就抓住了本質(zhì)。觸發(fā) BFC 的條件很多float不為none、overflow不為visible、display: inline-block、position: absolute/fixed、display: flex等。用途主要是清除浮動、防止外邊距折疊、阻止元素被浮動元素覆蓋。比如經(jīng)典的“父元素高度塌陷”問題給父元素設(shè)置overflow: hidden觸發(fā) BFC就能把浮動子元素的高度算進(jìn)去。層疊上下文則容易和z-index混淆。實際上z-index只在相同層疊上下文中比較。transform、opacity、filter、position加z-index都會創(chuàng)建層疊上下文。筆試題常給一個多層嵌套的定位元素問你哪個在最上面這時候就要按“父級上下文先比再比同級的 z-index”來推。我見過不少人死記z-index: 9999碰到嵌套場景還是出錯關(guān)鍵是理解規(guī)則。2.3 瀏覽器與網(wǎng)絡(luò)HTTP 緩存機(jī)制前端筆試?yán)锞W(wǎng)絡(luò)部分的常客是TCP 握手、HTTP 狀態(tài)碼、GET/POST 區(qū)別、HTTP 緩存、跨域。愛奇藝這套題里同樣有涉及尤其是緩存。HTTP 緩存可以簡單理解為“服務(wù)器給資源打標(biāo)簽瀏覽器下次按標(biāo)簽決定是否復(fù)用”。強(qiáng)緩存階段瀏覽器直接用本地副本不請求服務(wù)器協(xié)商緩存階段瀏覽器帶著標(biāo)簽去問服務(wù)器“這個資源還能用嗎”服務(wù)器決定返回304還是新資源。相關(guān)字段有Cache-Control: max-age、Expires強(qiáng)緩存Last-Modified/If-Modified-Since、ETag/If-None-Match協(xié)商緩存。前端筆試特別愛問“輸入 URL 到頁面展示的全過程”。這不是背流程就行而是要說明每一步的關(guān)鍵機(jī)制DNS 解析可能會查緩存、TCP 連接三次握手、發(fā)送 HTTP 請求攜帶緩存校驗信息、服務(wù)器返回響應(yīng)、瀏覽器解析 HTML 構(gòu)建 DOM 樹、解析 CSS 構(gòu)建樣式規(guī)則、JS 阻塞解析、布局與繪制。能流暢說出這個過程說明你對瀏覽器運行機(jī)制有整體概念這也是性能優(yōu)化思路的起點。2.4 手寫代碼與算法從數(shù)組去重到防抖節(jié)流手寫題是筆試中的重頭戲。最常出現(xiàn)的幾類數(shù)組去重、數(shù)組扁平化、深拷貝、防抖節(jié)流、Promise 實現(xiàn)、函數(shù)柯里化、Pub/Sub 事件總線。愛奇藝這類題的特點是要求不一定用 ES6 一行流而是看你能不能寫出健壯且可讀的實現(xiàn)。數(shù)組去重看起來簡單但考察的點是你知不知道多種方式Set一行解決filter indexOf解決但只能處理原始類型Map或?qū)ο箧I值處理引用類型。如果面試官追問“[1, 1]去重后有幾個”你就會發(fā)現(xiàn)Set用的是SameValueZero比較不會把1和1混掉。防抖和節(jié)流是面試必考題也是筆試手寫題?？?。防抖debounce的核心是“只認(rèn)最后一次”短時間內(nèi)連續(xù)觸發(fā)只有最后一次等待期結(jié)束后才執(zhí)行。典型場景是搜索框輸入聯(lián)想。節(jié)流throttle的核心是“限制頻率”不管觸發(fā)多少次每段時間最多執(zhí)行一次。典型場景是滾動事件、resize。實現(xiàn)都不難但要注意this綁定和參數(shù)透傳否則改 bug 改到懷疑人生。下面是一個帶this和參數(shù)處理的防抖實現(xiàn)function debounce(fn, wait) { let timer null; return function(...args) { const context this; if (timer) clearTimeout(timer); timer setTimeout(() { fn.apply(context, args); }, wait); }; }3. 實操過程與核心環(huán)節(jié)實現(xiàn)3.1 數(shù)組與對象操作常用方法背后的原理筆試題里經(jīng)?？肌跋铝心膫€方法會改變原數(shù)組”。很多人用的時候不關(guān)心這個但筆試偏偏要考。像push、pop、shift、unshift、splice、sort、reverse會改變原數(shù)組而map、filter、reduce、slice、concat不會。如果記不清可以直接用一個技巧方法名暗示是“原地操作”的一般會改。Array.prototype.reduce是高頻考點因為它是“萬能函數(shù)式工具”。筆試有時候會讓你用reduce實現(xiàn)map、filter、groupBy或者compose。比如用reduce實現(xiàn)數(shù)組扁平化function flatten(arr) { return arr.reduce((acc, cur) { return acc.concat(Array.isArray(cur) ? flatten(cur) : cur); }, []); }對象相關(guān)考點則集中在屬性遍歷for...in 與 Object.keys 的區(qū)別、對象深比較、可選鏈、解構(gòu)賦值、展開運算符。有一道經(jīng)典題是const obj { a: 1 }; const obj2 { ...obj }; obj2.a 2; console.log(obj.a); // 1因為第一層是淺拷貝但如果對象里嵌套了對象展開運算符只能拷貝第一層引用修改嵌套對象會連坐。所以深拷貝必須自己寫遞歸或借助structuredClone或lodash.cloneDeep。筆試寫深拷貝時還要考慮循環(huán)引用、日期、RegExp、Map、Set 等情況能寫出一個面試官會點頭的版本能加分不少。3.2 異步流程控制從回調(diào)地獄到 Promise異步是前端筆試的“分水嶺”。一部分人看到 Promise 就頭暈但真正理解事件循環(huán)后會發(fā)現(xiàn)所有異步題都是一個套路同步代碼先執(zhí)行然后按微任務(wù)和宏任務(wù)的優(yōu)先級輪詢執(zhí)行。你只要記住 Node.js 和瀏覽器的核心差異不是太大最重要的是“每執(zhí)行完一個宏任務(wù)都會清空整個微任務(wù)隊列”。下面這個順序題幾乎成為大廠必考console.log(script start); setTimeout(function () { console.log(setTimeout); }, 0); Promise.resolve() .then(function () { console.log(promise1); }) .then(function () { console.log(promise2); }); console.log(script end);輸出依次為script start、script end、promise1、promise2、setTimeout。原因是Promise.then屬于微任務(wù)setTimeout屬于宏任務(wù)同步代碼結(jié)束后會先清空微任務(wù)隊列再去取宏任務(wù)。如果題目里再加async/await其實也簡單await右邊的表達(dá)式會立即執(zhí)行await之后的代碼相當(dāng)于.then里的回調(diào)會放入微任務(wù)隊列。所以看到async題先把同步部分推完再把a(bǔ)wait后面的內(nèi)容當(dāng)作微任務(wù)按順序排好即可。3.3 網(wǎng)絡(luò)請求與 API 設(shè)計前端如何和服務(wù)器協(xié)作前端筆試還會通過代碼題考察你對HTTP 狀態(tài)碼和請求方法語義的理解。比如“創(chuàng)建一個資源用什么方法更新整個資源用什么方法刪除用什么方法”——這就是 RESTful 風(fēng)格。POST用于創(chuàng)建PUT用于整體更新PATCH用于部分更新DELETE用于刪除。如果對語義不熟接口設(shè)計時容易和別人撞車。另外一個高頻點是GET 與 POST 的區(qū)別。很多人背“GET 有長度限制、POST 安全”其實不嚴(yán)謹(jǐn)。本質(zhì)區(qū)別更多體現(xiàn)在GET 請求通常用于“查詢”參數(shù)放到 URL 上會被瀏覽器緩存、會留在歷史記錄里POST 通常用于“提交”參數(shù)放 body不會被緩存。至于長度限制其實是服務(wù)器或瀏覽器實現(xiàn)的限制不是 HTTP 協(xié)議硬性規(guī)定。這道題考的是你能不能區(qū)分“協(xié)議語義”和“實現(xiàn)限制”。還有一類代碼補(bǔ)全題要求你封裝一個request函數(shù)處理超時、重試、錯誤碼。實現(xiàn)上核心是“用Promise.race做超時控制”或者“用遞歸/循環(huán)做重試”。下面是一個簡化版的超時請求封裝function requestWithTimeout(url, options {}, timeout 5000) { return Promise.race([ fetch(url, options), new Promise((_, reject) { setTimeout(() reject(new Error(timeout)), timeout); }) ]); }這種題看著不難但能把邊界條件想清楚超時后要中斷請求、重試要避免重復(fù)提交、loading 狀態(tài)如何處理就能體現(xiàn)你寫業(yè)務(wù)代碼時是否嚴(yán)謹(jǐn)。3.4 前端工程化模塊化、構(gòu)建工具和組件化愛奇藝這套題既然叫前端開發(fā)筆試工程化相關(guān)的內(nèi)容也免不了。常見方向有CommonJS 與 ES Module 的區(qū)別、Tree Shaking 的原理、webpack 的構(gòu)建流程、Vue/React 組件通信。CommonJS 和 ES Module 的區(qū)別是基礎(chǔ)題但很多人的理解只停留在“一個是require一個是import”。深入一點CommonJS 是同步加載、動態(tài)加載、輸出的是值的拷貝ES Module 是靜態(tài)分析、異步加載、輸出的是值的引用。這些差異直接決定了瀏覽器和 Node.js 對模塊的處理方式不同?，F(xiàn)在 Node.js 同時支持兩種但.mjs與.cjs后綴不同行為也不同筆試有時候會出這個坑。關(guān)于組件化前端筆試可能給一段 Vue 或 React 代碼問你父子組件如何通信、跨級組件如何通信、狀態(tài)提升是什么。這類題目的核心是“單向數(shù)據(jù)流”父組件通過 props 向子組件傳數(shù)據(jù)子組件通過事件回調(diào)通知父組件更新。如果項目里狀態(tài)復(fù)雜再用全局狀態(tài)管理Vuex/Redux/Zustand或者 Context/Provide-inject。能把這個邏輯講清楚說明你在團(tuán)隊協(xié)作中不會亂寫全局變量。4. 常見問題與排查技巧實錄4.1 讀代碼題總“想當(dāng)然”怎么辦讀代碼題是踩坑重災(zāi)區(qū)。最常見的問題就是“還沒理清變量提升就直接按從上到下的順序讀”。比如這段經(jīng)典代碼var name global; function printName() { console.log(name); var name local; } printName();如果你按順序讀會以為先打印global實際輸出undefined。原因前面說過了函數(shù)內(nèi)var name提升到頂部但賦值不提升。遇到這種“怎么和我想的不一樣”的題先停下來把代碼重寫一遍把所有var聲明提到作用域頂部再模擬執(zhí)行。還有一個常見問題是忽略嚴(yán)格模式。如果代碼開頭有use strict那么this在獨立函數(shù)調(diào)用中是undefined而不是全局對象。變量賦值時不聲明會直接報錯。很多人在普通模式下測沒問題一旦環(huán)境切換就懵。所以做題時先看文件開頭有沒有嚴(yán)格模式標(biāo)記這會改變整個執(zhí)行結(jié)果。4.2 Promise 題老是排錯順序異步順序題出錯通常不是不知道“微任務(wù)先執(zhí)行”而是沒有區(qū)分 Promise 構(gòu)造器中的代碼和.then中的代碼。新手的誤區(qū)是以為new Promise里的代碼也是異步的。實際上Promise構(gòu)造器里的函數(shù)是同步執(zhí)行的只有resolve或reject之后的.then回調(diào)才是微任務(wù)。舉個例子new Promise((resolve) { console.log(inside); resolve(); console.log(after resolve); }).then(() { console.log(then); });輸出順序是inside、after resolve、then。resolve()只是把狀態(tài)改為 fulfilled并不會立即執(zhí)行.then函數(shù)體剩余代碼仍然同步執(zhí)行完。這個細(xì)節(jié)在筆試題里經(jīng)常設(shè)陷阱回答的時候不要一看Promise就以為是異步。4.3 布局題老忘記“父容器尺寸不定”的情況CSS 筆試題的另一個高頻失分點是忽略父容器沒有固定高度/寬度時的表現(xiàn)。比如經(jīng)典的“讓子元素垂直居中”問題很多人直接寫margin: auto但margin: auto只能在水平方向自動居中垂直方向需要display: flex或position transform配合。如果父容器沒有設(shè)置高度垂直居中其實沒有意義因為父容器高度由內(nèi)容撐開。再比如flex: 1的含意很多人只知道“填滿剩余空間”但不清楚它其實是flex-grow: 1; flex-shrink: 1; flex-basis: 0%的簡寫。筆試如果給你一個flex: 1和flex: auto的對比你要能解釋區(qū)別flex: 1的 basis 是 0所以不會受內(nèi)容固有尺寸影響flex: auto的 basis 是auto所以會優(yōu)先基于內(nèi)容尺寸分配空間。這一類細(xì)節(jié)平時寫樣式不注意做題必丟分。4.4 手寫題“會寫但沒考慮邊界”導(dǎo)致扣分手寫代碼題最容易出現(xiàn)“主流程對邊界漏”的情況。比如寫深拷貝只處理了普通對象和數(shù)組沒處理null、Date、RegExp、循環(huán)引用就會被扣分。實際上面試官看手寫題看的不是你“能不能寫出來”而是你“能不能考慮全面”。我建議你面試前準(zhǔn)備一個“模板庫”把高頻手寫題都寫成“帶邊界檢查”的版本而不是網(wǎng)上抄個一行版就背。比如數(shù)組去重可以按“原始類型 引用類型 NaN”這三個維度來寫Promise.all要確?！坝幸粋€ reject 就整體 reject”還要保證“傳入空數(shù)組時返回一個已解決的空數(shù)組”。這些邊界條件恰恰是日常寫代碼中最容易忽略的也是區(qū)分資深者和初學(xué)者的關(guān)鍵。5. 深度擴(kuò)展這份筆試題的深層價值5.1 從筆試看大廠前端的能力模型把愛奇藝筆試題放到更大的視角下看它其實描繪了“大廠前端的能力模型”語言基礎(chǔ)扎實、運行機(jī)制清楚、工程化意識強(qiáng)、邊界意識好。這不是愛奇藝一家的要求而是整個行業(yè)對成熟前端工程師的通用預(yù)期。很多從業(yè)三年左右的前端工作里一直在寫業(yè)務(wù)組件遇到問題就百度、CtrlC/V看起來什么都會但筆試一考就露餡。原因不是不聰明而是沒有建立“原理到實踐”的映射關(guān)系。比如用了無數(shù)次Array.prototype.map卻答不出它和forEach的本質(zhì)區(qū)別用了無數(shù)次display: flex卻不清楚 Flex 容器的三條主軸交叉軸規(guī)則。這份筆試題就像一面鏡子能照出你基礎(chǔ)功底的薄弱環(huán)節(jié)。另外這套題對“學(xué)習(xí)路徑”也有指導(dǎo)意義。如果你現(xiàn)在還是學(xué)生或者剛?cè)胄信c其追熱點學(xué)新框架不如先把 JS 高程、CSS 權(quán)威指南、HTTP 權(quán)威指南這些“老書”啃透?？蚣芨?lián)Q代是常態(tài)而語言特性和瀏覽器機(jī)制是十年內(nèi)都不會大變的地基。地基穩(wěn)了學(xué)框架只是換個語法而已。5.2 針對不同階段的備考策略對于在校生和應(yīng)屆生筆試準(zhǔn)備的核心是“刷題 建錯題本”。不要只悶頭在牛客上刷題每次做錯的題都要把“錯誤原因、正確推導(dǎo)、涉及知識點”記下來。過了兩周再拿出來做一遍直到能獨立推導(dǎo)出正確答案為止。針對愛奇藝這套題你可以關(guān)注高頻考點但不要跳過你認(rèn)為“簡單”的部分因為筆試的坑往往就埋在簡單題里。對于已經(jīng)工作的前端備考重點應(yīng)該放在“從原理角度重新組織答案”上。比如問你“什么是閉包”不要只回答“函數(shù)內(nèi)部訪問外部變量”而要能畫出作用域鏈、說出內(nèi)存回收的影響、舉一個實際業(yè)務(wù)場景比如防抖、柯里化、組件內(nèi)部函數(shù)。這樣你在面試官追問時才能接得住。筆試是筆試面試是面試但能力模型是通的能把面試中講清楚的東西寫到紙面上才說明真的掌握了。5.3 我發(fā)現(xiàn)的高頻規(guī)律與出題趨勢如果把近年的大廠前端筆試題放在一起看會發(fā)現(xiàn)出題趨勢非常明顯越來越重視“真正的場景題”而不再滿足于八股概念。所謂場景題就是“給一個具體業(yè)務(wù)問題讓你設(shè)計實現(xiàn)方案”。比如“有一個搜索框用戶輸入后需要防抖搜索同時要處理競態(tài)條件快速輸入時只取最后一次結(jié)果你會怎么做”這類題考察的點已經(jīng)超越了語言語法進(jìn)入架構(gòu)設(shè)計和邊界思考層面。愛奇藝這套2019年筆試題雖然整體偏基礎(chǔ)但已經(jīng)能看到這種趨勢的苗頭。比如它會在代碼題里設(shè)置“如果某個請求失敗了怎么辦”“如果這里傳的參數(shù)是不確定的怎么辦”等鋪陳其實就是在考察邊界處理?，F(xiàn)在的筆試題更是直接甩場景實現(xiàn)一個帶并發(fā)限制的異步調(diào)度器、實現(xiàn)一個 LazyMan、實現(xiàn)一個帶超時的 fetch、實現(xiàn)一個可取消的 Promise。這些題目背后考察的都是抽象能力和工程思維。我個人判斷未來前端筆試的難度還會繼續(xù)上探但考點永遠(yuǎn)圍繞“語言機(jī)制 異步控制 工程化 性能優(yōu)化”這幾條主線數(shù)據(jù)結(jié)構(gòu)與算法也在逐漸加重。所以趁早補(bǔ)齊基礎(chǔ)比臨時抱佛腳刷題靠譜太多。5.4 心態(tài)調(diào)整筆試不是終點而是起點我見過不少候選人因為一套筆試題做崩了就直接放棄這其實挺可惜的。筆試做不好往往不是能力不行而是練習(xí)方式不對或者準(zhǔn)備周期不夠。你只要把筆試當(dāng)作一次學(xué)習(xí)診斷把自己不會的題整理成專題一個個攻破效果遠(yuǎn)好于焦慮“我怎么這么菜”。另外提醒一句不要迷信“原題”。網(wǎng)上流傳的題庫再多也不可能押中所有面試題。真正穩(wěn)妥的做法是把每道題背后的知識點當(dāng)成一個“知識錨點”從這個錨點延伸出去把相關(guān)的概念、原理、應(yīng)用場景全部復(fù)習(xí)一遍。比如遇到一道“改變函數(shù) this 指向”的題你可以復(fù)習(xí)call/apply/bind的區(qū)別、手寫bind、箭頭函數(shù)、構(gòu)造函數(shù)new的過程、React 類組件中 this 綁定的常見錯誤。這樣一來一道題就變成了一套知識網(wǎng)絡(luò)不管怎么變著問你都能應(yīng)對。