2024年8月的一天下午我拿著手機盯著郵箱里貝殼找房2025屆秋季校園招聘前端崗位第一批筆試通知那行字心跳快了半拍。秋招做過的筆試不少大部分公司都是在?？突蛘哔惔a上扔一套卷子題目從題庫里隨機抽既看不出誠意也測不出水平。貝殼這套題卻不太一樣有基礎的八股選擇題有需要動手寫的編程題還有一道開放設計題。整體難度不算變態(tài)但它非常典型典型到可以說就是一線互聯(lián)網公司對前端應屆生的標準能力畫像?？纪曛笪覐捅P了整整兩天把每道題背后的知識點、當時的錯誤判斷、以及這道題到底想篩選什么樣的人都重新過了一遍收獲比刷十套LeetCode都大。這篇文章不只是把題目和答案復述一遍我會把選擇的邏輯、踩坑的過程、以及怎么在時間不夠的情況下拿到該拿的分盡量完整地還原出來。無論你是2025屆、2026屆正在備戰(zhàn)的在校生還是已經工作一陣子想跳槽的工程師應該都能從這里讀出一些通用的東西。1. 筆試摸底這套題考什么、該怎么分配時間1.1 三個模塊選擇、編程、開放貝殼第一批前端筆試整體分為三個模塊。第一個模塊是選擇題單多選混合覆蓋JavaScript基礎、CSS、瀏覽器與網絡、Vue/React框架原理。這部分大概占了40%的分數(shù)看起來簡單但多選題特別容易翻車因為很多選項是在一個細微的地方做改動少選、錯選都不得分。第二個模塊是編程題一般是2到4道考察數(shù)據(jù)結構和算法。整體難度在LeetCode中等題偏下的水平但有一道題會稍微復雜一點。值得注意的是貝殼的編程題里經常有一道前端場景題不直接考算法而是讓你手寫某個工具函數(shù)、組件邏輯或者業(yè)務場景中常見的函數(shù)這類題目的核心是考工程思維而不是純算法。第三個模塊是開放設計題給你一個前端工程問題讓你論述設計方案。我遇到的是錯誤監(jiān)控相關這個我后面專門展開講。1.2 開考前我做的三件事收到筆試通知到正式開考大概有三天時間。我沒有盲目刷題而是做了三件比較有效的事情。第一件去?？秃蜕鐓^(qū)翻以往的面經、筆經。雖然每個批次的題不完全一樣但出題風格和側重點是有延續(xù)性的比如往年就有人提到貝殼喜歡考事件循環(huán)、緩存和動態(tài)規(guī)劃這讓我在復習時有了明確方向。第二件把JavaScript中事件循環(huán)、Promise、閉包、原型鏈這四塊重新精讀了一遍。不是背概念而是要求自己能在紙上畫出代碼執(zhí)行過程中調用棧、宏任務隊列、微任務隊列的變化過程。這一步在后面選擇題上直接幫我省出了至少5分鐘。第三件重新練了一遍?？?賽碼平臺的輸入輸出環(huán)境。這里提醒大家筆試前一定要花時間熟悉你即將使用的在線平臺。比如賽碼的Node.js環(huán)境下輸入輸出是用readline模塊自己處理的和本地瀏覽器里寫的腳本完全是兩套玩法。我有同學因為不熟悉光是在輸入輸出上就卡了十分鐘直接把心態(tài)打崩。1.3 時間分配策略先拿穩(wěn)的再啃難的貝殼這批筆試總時長是90分鐘。我的時間分配是選擇題20到25分鐘編程題和場景題55到60分鐘開放題10到15分鐘。這個順序不是隨便定的背后的邏輯是先把確定性能拿到的分數(shù)全部拿到再去挑戰(zhàn)不確定的部分。選擇題雖然分值不算高但做起來快而且很多是記憶型題目趁頭腦清醒的時候回答正確率最高。編程題一定要先花一兩分鐘把所有題目都掃一遍評估每一道題的難度和熟悉度然后嚴格按照從易到難的順序來寫不要一上來就死磕最難的DP題。開放設計題放在最后因為它的主觀性比較大即使只剩10分鐘寫一個清晰的框架也能拿到部分分完全空著就徹底沒戲了。提示筆試系統(tǒng)普遍有切屏檢測千萬不要想著開另一個標簽頁查資料。貝殼這批是雙機位監(jiān)控切屏一次會記錄切屏多次可能直接判作弊代價太大不值得。2. 選擇與填空題事件循環(huán)、閉包和瀏覽器緩存的那些經典陷阱2.1 事件循環(huán)輸出題await不是簡單等一等選擇題第一類高頻考點是輸出題就是給你一段代碼讓你判斷輸出順序。前端人應該都懂這種題考的就是事件循環(huán)、宏任務與微任務以及Promise的執(zhí)行時機。貝殼的題里自然也少不了。舉個例子給你這樣一段代碼讓你寫出輸出順序async function async1() { console.log(async1 start); await async2(); console.log(async1 end); } async function async2() { console.log(async2); } console.log(script start); setTimeout(() { console.log(setTimeout); }, 0); async1(); new Promise((resolve) { console.log(promise1); resolve(); }).then(() { console.log(promise2); }); console.log(script end);正確答案是script start - async1 start - async2 - promise1 - script end - async1 end - promise2 - setTimeout。這個輸出題幾乎每年每個公司都會考但每次正確率都不高原因在于很多人對await的理解停留在等一等再執(zhí)行后面代碼這種模糊層面。實際執(zhí)行時async1函數(shù)體里的await async2()這一行會先同步執(zhí)行 async2()所以在控制臺能立刻看到 async2 輸出。然后遇到awaitasync1讓出控制權把后續(xù)的console.log(async1 end)注冊為微任務。緊接著繼續(xù)執(zhí)行同步代碼也就是輸出 promise1并把 promise2 注冊為另一個微任務。同步代碼全部執(zhí)行完后輸出 script end然后進入微任務隊列按注冊順序執(zhí)行先 async1 end再 promise2。最后執(zhí)行宏任務隊列里的 setTimeout。這里最容易錯的兩個點一是誤以為await async2()整句都是異步的把 async2 的輸出順序排到后面二是沒有意識到async1 end和promise2在同一個微任務隊列里的先后順序取決于注冊順序。如果只背微任務比宏任務先執(zhí)行遇到多個微任務混雜的情況就會算錯。2.2 閉包與變量提升一個隱藏的let另一道非常經典的輸出題是循環(huán)閉包。面試官把這段代碼放在選擇題里var a []; for (var i 0; i 3; i) { a[i] function () { console.log(i); }; } a[0](); a[1](); a[2]();輸出是 3 3 3因為var聲明的i沒有塊級作用域循環(huán)結束后i變成了3所有閉包捕獲的是同一個變量i。要想輸出0、1、2要么把var改成let要么用立即執(zhí)行函數(shù)包一層for (var i 0; i 3; i) { a[i] (function (num) { return function () { console.log(num); }; })(i); }這類題本身不難但它后面的引申很關鍵。比如考你如果循環(huán)體內部有異步操作比如setTimeout那輸出順序會怎樣變化或者考你let聲明的變量在塊級作用域里到底創(chuàng)建了幾個獨立綁定。在JavaScript中l(wèi)et的塊級作用域會讓每一次循環(huán)都創(chuàng)建一個新的詞法環(huán)境所以閉包捕獲到的i是每一輪自己的值。理解這個比背答案有用得多。2.3 緩存與跨域從場景判斷而不是背概念瀏覽器緩存也是貝殼選擇題的常客。但貝殼很少讓你直接默寫什么是強緩存、什么是協(xié)商緩存而是給你一個實際場景讓你判斷。比如某網站靜態(tài)資源在文件名上帶上了內容hash如app.8f3a9b.js那么部署時最適合使用什么緩存策略正確答案是對這類帶hash的靜態(tài)資源應該使用強緩存設置較長的Cache-Control: max-age例如一年。因為內容變了文件名就會變?yōu)g覽器不會拿到舊的文件名不變就說明內容沒變可以直接用瀏覽器本地緩存省去HTTP請求。反過來如果資源文件名不帶hash就不能設置過長的強緩存否則更新了代碼用戶還是老頁面這時候更適合用協(xié)商緩存通過ETag或Last-Modified在每次請求時向后端校驗資源沒變化時返回304瀏覽器復用本地緩存。我把這兩種策略對比一下資源類型推薦緩存策略原因帶hash的靜態(tài)資源強緩存Cache-Control: max-age31536000內容變了文件名變不存在舊文件命中問題不帶hash的資源協(xié)商緩存ETag / Last-Modified需要每次校驗資源是否更新避免拿到舊內容入口HTML文檔不緩存或協(xié)商緩存保證用戶能盡快拿到最新的頁面引用另外Shell也比較喜歡考跨域。不能只背JSONP、CORS、代理這幾個詞要能說清JSONP原理是動態(tài)插入script標簽、只能支持GET請求CORS需要服務端返回Access-Control-Allow-Origin等響應頭瀏覽器才會放行開發(fā)環(huán)境常用的webpack devServer代理則是通過服務端轉發(fā)來規(guī)避瀏覽器的同源限制。2.4 框架原理Vue3的Proxy和React的key框架相關的題目占比不小。貝殼會考Vue3的響應式是基于什么實現(xiàn)的答案是Proxy而不是Vue2的Object.defineProperty。更進一步它可能會問Proxy相比Object.defineProperty的優(yōu)勢在哪里。這個問題不能只答性能更好要說清楚三點第一Proxy可以直接監(jiān)聽對象新增屬性和刪除屬性第二Proxy可以監(jiān)聽數(shù)組索引和length的變化不需要像Vue2那樣重寫數(shù)組方法第三Vue2初始化時需要對data做深度遞歸遍歷用Object.defineProperty逐個劫持而Proxy是代理整個對象訪問到某個屬性時才惰性遞歸初始化性能更好。React相關的題關鍵是key。在列表渲染時給每個元素設置一個穩(wěn)定且唯一的key本質是幫助diff算法識別節(jié)點是否被復用。很多人覺得用index做key也沒問題反正能跑但在列表項有順序變化、插入刪除時用index會導致節(jié)點的狀態(tài)錯亂比如輸入框內容串行、圖片加載出bug。筆試里它會給你一段代碼讓你判斷為什么在某些場景下使用index作為key會出現(xiàn)問題這種題就是要考察你是否有真實項目的渲染優(yōu)化經驗而不是只在文檔里讀過。選擇部分整體感受是考得廣但不偏每個題都是前端日常工作中實際關心的點。只要基礎扎實拿高分并不難。3. 編程題第一關字符串統(tǒng)計與數(shù)組扁平化的邊界教訓3.1 字符串頻次排序sort的比較函數(shù)不是可選項編程題里有一道非常典型的題目大意是給定一個字符串統(tǒng)計每個字符出現(xiàn)的次數(shù)并按出現(xiàn)次數(shù)從高到低排序輸出如果次數(shù)相同按字符的ASCII碼升序。這道題看起來很簡單很多人的第一版代碼長這樣function frequencySort(s) { const map new Map(); for (const ch of s) { map.set(ch, (map.get(ch) || 0) 1); } const arr [...map.entries()]; arr.sort((a, b) b[1] - a[1]); return arr.map(([ch, count]) ch.repeat(count)).join(); }如果把提交后再自測幾個用例就會發(fā)現(xiàn)當兩個字符出現(xiàn)次數(shù)相同時輸出順序不符合ASCII升序要求。原因是上面的sort((a,b) b[1] - a[1])只按次數(shù)排序次數(shù)相同的情況下sort的穩(wěn)定排序會讓它們保持原本在Map中的插入順序而這個插入順序是字符串中第一次出現(xiàn)字符的順序不是ASCII碼順序。題目明確要求ASCII升序所以要再加一個比較條件arr.sort((a, b) { if (a[1] ! b[1]) { return b[1] - a[1]; // 次數(shù)降序 } return a[0].charCodeAt(0) - b[0].charCodeAt(0); // ASCII升序 });另一個容易踩的坑是Array.prototype.sort默認比較方式是把元素轉為字符串后按字典序排列不是按數(shù)值升序。如果不傳比較函數(shù)直接用sort對數(shù)字數(shù)組排序結果會完全不符合直覺。這個知識點很多人平時沒注意但筆試時一緊張很容易犯。3.2 數(shù)組扁平化去重遞歸寫法與Set的局限還有一道數(shù)組相關題目大意是多維數(shù)組展開成一維數(shù)組再去重。要求不能用Array.prototype.flat甚至可能要求不能用Set。如果允許用Set遞歸寫法非常清晰function flattenAndUnique(arr) { const result []; const seen new Set(); const dfs (val) { if (Array.isArray(val)) { val.forEach(dfs); } else if (!seen.has(val)) { seen.add(val); result.push(val); } }; arr.forEach(dfs); return result; }這里有一個非常隱蔽的問題Set判斷引用類型時是按引用地址去重不是按值去重。如果數(shù)組里有對象比如[{ a: 1 }, { a: 1 }]用Set去重后兩個對象都會被保留因為它們的內存引用不同。如果題目要求對象按內容去重就必須做深比較比如用JSON.stringify序列化后作為Set的key但這樣又會有key順序或函數(shù)丟失的問題。筆試中如果遇到帶對象的去重需要多想一層這也是這類題真正拉開差距的地方。3.3 為什么簡單題通過率反而不高從周圍的反饋看第一道編程題的通過率并不高。原因不是解法難而是環(huán)境、時間、邊界三座大山壓在一起。在線筆試平臺的JavaScript環(huán)境有兩個特點第一輸入輸出要走標準輸入輸出不是瀏覽器里的alert和console第二Node.js環(huán)境下輸入被分成一行一行讀取需要自己用readline或者process.stdin處理。很多人在本地IDE里寫得很溜一旦切到平臺的代碼編輯器光標一閃爍思路就亂了。應對辦法是在筆試開始前把輸入輸出模板先寫好。比如賽碼平臺常用的Node.js模板const readline require(readline); const rl readline.createInterface({ input: process.stdin, output: process.stdout, }); const lines []; rl.on(line, (line) { lines.push(line.trim()); }); rl.on(close, () { // 在這里編寫業(yè)務邏輯lines就是所有輸入行 const s lines[0]; console.log(frequencySort(s)); });邊界條件也不能忽視。字符串為空、全是同一個字符、字符是空格、包含數(shù)字和大小寫字母這些用例都要自己先跑一遍。一個常見低級錯誤是字符串里有空格而輸入讀取時用了.trim()把整行空格去掉了導致空格的統(tǒng)計結果不對。如果題目明確說字符包括空格就應該用line.split()這樣的方式保留原始內容而不是統(tǒng)一trim掉。4. 編程題第二關帶約束的DP和手寫防抖背后的競態(tài)處理4.1 從跳臺階到狀態(tài)機不能連續(xù)跳兩格的DP編程題里出現(xiàn)了一道讓我卡了挺久的動態(tài)規(guī)劃題。題目大意我盡量復述給定一個長度為n的臺階每次可以跳1格或2格但有一個額外約束——不能連續(xù)兩次都跳2格問到達第n級臺階有多少種不同的跳法。第一眼看上去大家都覺得是斐波那契數(shù)列的變形但不能連續(xù)兩次跳2格這個約束讓單一狀態(tài)數(shù)組沒辦法處理。因為當我們站在第i級臺階時能不能選擇跳2格這一步取決于上一次是不是通過跳2格上來的。也就是說上一步的信息會影響當前的選擇這是一個典型的狀態(tài)機問題。正確的解法是用二維DP把到達第i級且最后一步是跳幾格分開記錄。定義dp[i][0]到達第i級臺階最后一步是跳1格這樣的方案數(shù)。dp[i][1]到達第i級臺階最后一步是跳2格這樣的方案數(shù)。轉移也很直觀如果最后一步是跳1格那么到達它的前一個狀態(tài)可以是跳1格也可以是跳2格所以dp[i][0] dp[i-1][0] dp[i-1][1]。如果最后一步是跳2格那么前一步絕對不能是跳2格所以只能從i-2且最后一步是跳1格的狀態(tài)過來即dp[i][1] dp[i-2][0]。初始條件dp[0][0] 1表示在起點有一種什么都沒做的方案dp[1][0] 1表示從第0級跳1格到第1級dp[1][1] 0顯然跳到第1級不可能最后一步跳2格。然后從2開始迭代即可。這里想多說一句這個DP模型放到前端開發(fā)里并不是學了也沒用。想想一個交互組件的狀態(tài)遷移比如未開始/加載中/成功/失敗/空數(shù)據(jù)這幾個狀態(tài)之間有些遷移是允許的有些是不允許的寫代碼時如果不把這種約束顯式建模就會出現(xiàn)狀態(tài)錯亂。算法題訓練的其實就是這種把業(yè)務約束轉成狀態(tài)轉移的能力而不是純粹為了考試。4.2 業(yè)務場景題防抖加競態(tài)序號還有一道業(yè)務場景編程題我印象很深。題目大意是搜索框輸入時需要每300ms防抖發(fā)送一次請求同時要保證請求返回后不會把舊請求的結果渲染到界面上。要求手寫實現(xiàn)。大部分人的第一反應是寫一個防抖函數(shù)function debounce(fn, delay) { let timer null; return function (...args) { if (timer) { clearTimeout(timer); } timer setTimeout(() { fn.apply(this, args); }, delay); }; }寫到這里這道題只能算完成了一半。防抖可以保證請求不會頻繁發(fā)出但它不能保證響應順序不變動。用戶輸入貝殼先發(fā)了?keyword貝的請求再發(fā)?keyword貝殼的請求但網絡環(huán)境復雜先發(fā)的那個請求可能后返回如果后返回的舊響應直接渲染到界面上就會出現(xiàn)搜索貝殼卻顯示了貝的結果的經典競態(tài)問題。解決方案是給每次請求加一個序號只有當前序號等于最新序號時才渲染數(shù)據(jù)let seq 0; async function search(keyword) { const current seq; const data await fetchData(keyword); if (current seq) { render(data); } }這段代碼里的current seq是核心。它的意思就是只有當我這次請求仍然是最新的一次請求時結果才允許登場。競態(tài)問題在實際項目中非常常見不只是搜索引擎還包括列表分頁、下拉刷新、編輯保存等場景。這道題之所以值得寫是因為它考的不僅是防抖更是工程中一個真實的痛難點。4.3 筆試編程題的取舍先AC哪些編程題部分如果總共有4道理想的策略是用最短時間找出你最有把握的兩道先把它們AC然后回頭啃剩下的。時間分配上每道題給自己設定一個上限我在實戰(zhàn)中用的是10分鐘超過10分鐘還沒有明確思路就跳到下一道。不要覺得可惜你能拿到的分數(shù)才是真的分數(shù)卡在難題上反而會導致后面的開放題空著那才是更大的損失。另外寫代碼時如果一道題實在寫不出來也要把核心思路以注釋的形式寫在答題區(qū)。在很多公司的筆試評分體系中通過部分用例也有分思路備注能幫助面試官在簡歷篩選階段對你建立一個更好的印象。5. 開放設計題如何從做題家切換成工程師5.1 一個典型的開放題錯誤監(jiān)控SDK設計貝殼的開放設計題是這樣的風格給你一個實際的前端工程問題不要求寫完整代碼而是請你給出設計方案。我遇到的是請設計一個前端錯誤監(jiān)控SDK說明你會采集哪些信息、如何上報、如何減少對業(yè)務性能的影響。這類題對于只刷算法題的人來說會有點懵因為八股文里沒有現(xiàn)成答案。但對真正做過線上項目、用過Sentry、聽過前端監(jiān)控方案的候選人來說是很有話說的。所以它考察的本質是你有沒有真正思考過線上質量保障。我的作答思路分四個層面第一采集什么信息。JS運行時錯誤用window.onerror監(jiān)聽未捕獲的Promise異常用unhandledrejection監(jiān)聽。資源加載錯誤需要在window.addEventListener(error, fn, true)的捕獲階段處理因為資源加載錯誤不會冒泡。接口請求異常則可以在axios攔截器或fetch封裝層統(tǒng)一捕獲記錄狀態(tài)碼、請求耗時、請求參數(shù)。除了錯誤本身還要采集發(fā)生錯誤的頁面URL、用戶操作路徑、瀏覽器和系統(tǒng)信息、以及上下文的關鍵數(shù)據(jù)方便開發(fā)者復現(xiàn)問題。第二用什么方式上報。優(yōu)先推薦navigator.sendBeacon它的特點是即使頁面正在關閉瀏覽器也會盡力把數(shù)據(jù)發(fā)送出去非常適合統(tǒng)計日志和監(jiān)控數(shù)據(jù)。也可以用new Image().src url的方式做圖片打點但注意URL長度有限制日志內容多時會被截斷。普通情況下的日志上報循環(huán)發(fā)送太多請求還會擠壓正常業(yè)務請求所以往往需要一個批量上報隊列把一段時間內的多條錯誤合并成一次上報。第三如何減少性能影響。監(jiān)控SDK不能成為業(yè)務卡頓的源頭做業(yè)務的人最反感這一點。一般的要求是SDK異步加載不阻塞首屏渲染上報數(shù)據(jù)時對錯誤堆棧做截斷控制單條日志大小錯誤記錄先經過一個緩存隊列批量發(fā)送避免大量并發(fā)請求還可以通過采樣率控制上報量比如線上只采樣10%的用戶保證在不影響性能的前提下獲得足夠的錯誤樣本。第四如何保證監(jiān)控自身不出問題。SDK本身要容錯比如捕獲邏輯被業(yè)務代碼覆蓋了、某些跨域腳本拿不到詳細堆棧、舊瀏覽器不支持sendBeacon等都要有降級方案。這層思考往往是加分項能體現(xiàn)出工程經驗的深度。5.2 作答框架先定性再展開最后給驗證方案開放設計題最怕把答案寫成一句話。比如給window加個error監(jiān)聽然后上報到服務器這種回答等于沒答因為它和工程師的思考方式完全不匹配。我的框架是先明確設計目標再列出關鍵模塊每個模塊展開講一到兩個實現(xiàn)細節(jié)最后補上驗證和監(jiān)控手段。比如錯誤監(jiān)控SDK的目標是快、全、穩(wěn)、瘦——快速采集、盡量全面、自身穩(wěn)定、對業(yè)務的影響小。在這個目標框架下展開邏輯就會非常清晰。在具體的答題過程中還可以補充一個驗證方案如何測試SDK是否真的生效。比如寫一個demo頁面手動觸發(fā)一個未捕獲異?？纯刂婆_的數(shù)據(jù)請求是否發(fā)出模擬低網速環(huán)境觀察SDK是否影響頁面交互使用Lighthouse跑一下性能分數(shù)對比接入前后有沒有明顯下降。這些內容不需要你真的做過但作為工程師的正常思考路徑寫出來是合理的。5.3 開放題拿部分分的三個原則第一絕不空題。哪怕是只有5分鐘把采集、上報、性能三個大字寫出來也能讓閱卷人知道你有基本概念。第二寫分點和分層用第一/第二/第三或者1/2/3組織內容不寫一坨沒有結構的段落。第三不要寫自己都不確定的技術細節(jié)答錯比不答扣分更多。比如你忘了sendBeacon的兼容性就別強行編可以說如果是老舊瀏覽器使用Image打點降級。這類題的評分方式不完全看結論更看思路是否完整、有沒有考慮到真實業(yè)務場景這是這道題能篩選出有過真實項目經驗的人的原因。6. 復盤與看見這套題背后藏著的前端能力預期6.1 我這次填錯的三個地方交卷后我第一時間在草稿紙上復盤了整場筆試記錄了自己幾個明確的失誤點。第一個失誤在第一道編程題上我把輸入行做了trim結果題目里要求統(tǒng)計的字符串包含了空格導致空格這個字符的頻次統(tǒng)計錯了。這類教訓其實很基礎筆試中任何對輸入的好心清洗都要先想清楚題目要求。第二個失誤出在事件循環(huán)的選擇題上我在多個微任務嵌套時猶豫了太久。當時那道題已經把Promise和async/await層層嵌套我雖然知道微任務先于宏任務但在微任務隊列內部的順序上花了幾分鐘才理清。如果平時訓練多一點就完全不會卡殼。第三個失誤是DP題的狀態(tài)定義花了我太多時間。我第一反應是直接用一維dp基于斐波那契的思路往下走走了三四分鐘才發(fā)現(xiàn)不能連續(xù)跳2格這個約束無法在一維狀態(tài)里表達。后來從最后一步是跳幾格這個角度去想才找到二維狀態(tài)的定義方式。平時寫動態(tài)規(guī)劃時養(yǎng)成先想清楚狀態(tài)維度再想轉移方程的習慣能省很多時間。6.2 從筆試信號看秋招前端考察趨勢回頭來看貝殼這套題其實透露出很多信息。第一個信號是前端筆試正在從純八股算法向八股算法工程場景轉變。防抖加競態(tài)、錯誤監(jiān)控SDK這類題目已經不是在考記憶而是在看候選人有沒有真正的項目管理思維和線上問題排查意識。第二個信號是動態(tài)規(guī)劃這類經典的算法題依然有重要位置但考點越來越偏向約束條件下的狀態(tài)設計比如不能連續(xù)跳兩格。這類題目考察的是抽象建模能力同類型的還有打家劫舍不能連續(xù)偷兩家買賣股票有冷凍期等刷題時應該重點掌握這種狀態(tài)機的建模方式。第三個信號是框架、原理、瀏覽器緩存不再以死板的背誦形式出現(xiàn)而是給了更多場景要求你基于實際條件做判斷。這意味著平時的學習不能只靠背面試題一定要動手寫代碼、做項目、調試線上問題積累真正的體感。6.3 給后續(xù)批次同學的備賽清單根據(jù)這次筆試的復盤我整理了一份可以作為參考的備賽清單事件循環(huán)輸出題。把宏任務、微任務、Promise、async/await的代碼執(zhí)行順序練到形成肌肉記憶特別是多層嵌套的微任務順序。閉包與作用域。循環(huán)閉包、變量提升、let/var的區(qū)別會寫會解釋。瀏覽器緩存。強緩存、協(xié)商緩存、啟發(fā)式緩存以及針對不同資源的實際策略選擇。Vue3與React。響應式原理、key的作用、diff算法、組件生命周期要能講出為什么。LeetCode hot100。中等難度的字符串、雙指針、棧、隊列、簡單DP優(yōu)先難題學會及時放棄。前端場景題。防抖節(jié)流、深拷貝、數(shù)組扁平化、事件總線、帶并發(fā)限制的請求隊列不僅要會寫還要能說出邊界問題和改進方案。這份清單并不僅針對貝殼對絕大部分互聯(lián)網公司前端崗位的秋招筆試都是適用的。筆試結束那一刻我心里其實挺沒底的覺得自己好幾處都犯了低級錯誤。但復盤完才發(fā)現(xiàn)一場筆試真正的價值不是那個分數(shù)而是它像一面鏡子把你在知識體系和工程思維上的薄弱點照得清清楚楚。我后來順利進入了面試環(huán)節(jié)回頭看仍然覺得這套筆試題出得很有水平——它沒有為難人也沒有放水而是老老實實考察了一個前端工程師日常學習中應該積累的東西。如果你也正在準備前端秋招希望這篇復盤能幫你少踩幾個坑在考場上把該拿的分數(shù)都穩(wěn)穩(wěn)拿下。