時間過得真快2023 屆秋招早就落下帷幕但后臺時不時還有學弟學妹問我小紅書前端筆試到底考什么。我翻了下當時記的筆記把小紅書-前端崗-第一批筆試的完整復盤整理了出來。這篇文章里沒有那些虛頭巴腦的面經(jīng)匯總?cè)俏易约鹤诳紙隼镎鎸嵱龅降脑}、當時卡殼的地方以及事后復盤才想明白的解法。先說結(jié)論小紅書的前端筆試在互聯(lián)網(wǎng)大廠梯隊里屬于中等偏上難度不會像硬核算法廠那樣直接上 Hard 壓軸但也絕對不像某些業(yè)務廠那樣走個過場。它考察的維度很清晰——前端基礎與 JS 功底選擇 中等偏上的算法題編程 場景題問答。只要你刷過 LeetCode 前 150 題里的 Hot 100再把 JS 事件循環(huán)、原型鏈、Promise 這幾個八股高頻點吃透過筆試線問題不大。但這篇文章的價值不在于告訴你考什么而在于帶你把每道題從讀題到 AC 的完整思路走一遍包括我踩進去的坑和后來才反應過來的最優(yōu)解。1. 筆試整體節(jié)奏與題型分布1.1 考試形式與時間分配2023 年秋招小紅書前端崗第一批筆試是在牛客網(wǎng)上進行的我記得時間大概在 9 月上旬。整體限時 90 分鐘題目結(jié)構(gòu)非常清晰題型題量分值占比我的實際用時不定項選擇20 題約 40%25 分鐘編程題3 題約 50%55 分鐘簡答/場景題1 題約 10%10 分鐘這里有個很關鍵的細節(jié)選擇題是不定項選擇不是單選多選、少選、錯選都不得分。這意味著你做選擇題時必須對每個選項有確切的判斷不能像單選那樣用排除法蒙一個就完事。我身邊就有同學在選擇題上吃了大虧覺得差不多選了就行結(jié)果出來一對答案發(fā)現(xiàn)錯了小一半。時間分配上我強烈建議你壓縮選擇題的時間。因為編程題才是拉開差距的地方20 道選擇題最多給 30 分鐘遇到拿不準的先標記跳過別死磕。我見過太多人選擇題磨了 50 分鐘最后編程題連題都沒讀完就到點交卷——這是新手最容易犯的錯誤。1.2 題型構(gòu)成與考點側(cè)重從題目內(nèi)容上看小紅書前端筆試更偏向**計算機基礎 JS 語言特性 前端工程化**的組合而不是堆砌各種冷門 API。選擇題的考點分布我記得大概是這樣的JavaScript 核心機制事件循環(huán)Event Loop、閉包與作用域、原型鏈與繼承、this 指向、Promise 與異步控制瀏覽器與網(wǎng)絡頁面渲染過程、HTTP 緩存、跨域方案、WebSocket 基礎CSS 與布局盒模型、BFC、Flex 布局、Grid 布局的適用場景框架Vue/React組件通信方式、生命周期、虛擬 DOM 與 diff 算法、響應式原理計算機基礎數(shù)據(jù)結(jié)構(gòu)棧/隊列/二叉樹、網(wǎng)絡分層、簡單的時間復雜度分析編程題三道的難度梯度做得很好第一題是能輕松 AC 的送分題第二題是稍加思考能用常見算法解決的中檔題第三題就需要你有一些技巧和扎實的代碼功底了。這三題選得很有水平基本能篩掉刷題背答案黨和真會寫代碼的人。2. 編程題逐題拆解從讀題到 AC 的完整思路2.1 第一題最長無重復字符子串滑動窗口這是整個筆試里最溫和的一道題也是 LeetCode 的第 3 題原題。題目描述大概是這樣給定一個字符串請你找出其中不含有重復字符的最長子串的長度。看到這道題我第一反應是滑動窗口。窗口里維護一個 Set或 Map記錄當前窗口內(nèi)出現(xiàn)過的字符。right 指針不斷向右擴展如果遇到重復字符就移動 left 指針直到窗口里沒有重復字符為止然后更新最大長度。/** * param {string} s * return {number} */ function lengthOfLongestSubstring(s) { const set new Set(); let left 0; let maxLen 0; for (let right 0; right s.length; right) { const ch s[right]; // 如果窗口內(nèi)已經(jīng)有這個字符就收縮左邊界 while (set.has(ch)) { set.delete(s[left]); left; } set.add(ch); maxLen Math.max(maxLen, right - left 1); } return maxLen; }這道題思路本身不復雜但有兩個細節(jié)值得注意。第一個細節(jié)是**while 還是 if**。如果窗口內(nèi)已經(jīng)存在重復字符必須用 while 循環(huán)不斷收縮左邊界直到徹底移除那個重復字符為止。有些同學寫成 if以為收縮一次就夠了但遇到 abca 這樣的情況就會出錯當 right 走到第二個 a 時left 指向 b收縮一次只能刪除 b窗口還是包含 a必須繼續(xù)收縮到 left 越過第一個 a 才行。第二個細節(jié)是 Set 和 Map 的選擇。雖然這道題用 Set 就能解決但如果題目改成最長不含重復字符的子串并要求你返回這個子串本身那你就需要 Map 來記錄每個字符最后出現(xiàn)的位置這樣可以做到 left 指針直接跳躍到重復字符的下一個位置而不需要一格一格地挪。我當時答題時留了個心眼用 Map 做了優(yōu)化版本雖然寫起來稍微多幾行但時間復雜度依然是 O(n)空間復雜度同樣是 O(字符集大小)。筆試環(huán)境里時間緊張用最穩(wěn)妥的 Set 版本也完全夠用沒必要過度優(yōu)化。2.2 第二題合并區(qū)間排序 貪心第二題是合并區(qū)間也是 LeetCode 第 56 題的原題變種。題目大概是以數(shù)組 intervals 表示若干個區(qū)間的集合其中單個區(qū)間為 intervals[i] [start, end]start end。請你合并所有重疊的區(qū)間并返回一個不重疊的區(qū)間數(shù)組該數(shù)組需恰好覆蓋輸入中的所有區(qū)間。這道題我愿稱之為大廠筆試最愛的區(qū)間類題目沒有之一。因為它考察的是一個很重要的算法思維——貪心 排序而且代碼量不多、邊界情況明確非常適合作為中檔題。解題套路非常固定首先把區(qū)間數(shù)組按照左端點從小到大排序遍歷所有區(qū)間如果當前區(qū)間的左端點大于結(jié)果數(shù)組中最后一個區(qū)間的右端點說明兩個區(qū)間不重疊直接把當前區(qū)間加入結(jié)果數(shù)組否則說明有重疊更新結(jié)果數(shù)組中最后一個區(qū)間的右端點為它自己原本的右端點和當前區(qū)間的右端點中的較大值/** * param {number[][]} intervals * return {number[][]} */ function merge(intervals) { if (intervals.length 1) return intervals; // 按照左端點升序排序 intervals.sort((a, b) a[0] - b[0]); const result [intervals[0]]; for (let i 1; i intervals.length; i) { const current intervals[i]; const last result[result.length - 1]; if (current[0] last[1]) { // 有重疊合并 last[1] Math.max(last[1], current[1]); } else { result.push(current); } } return result; }這里最關鍵的一步是排序。為什么必須按左端點排序因為只有左端點有序你才能保證每次處理新區(qū)間時它只可能和結(jié)果數(shù)組的最后一個區(qū)間重疊而不可能和更早的區(qū)間重疊。如果不排序兩個不相鄰的區(qū)間也可能存在重疊關系就得用更復雜的算法去處理。還有一個細節(jié)排序時一定要寫成(a, b) a[0] - b[0]不是a[0] b[0]。雖然 ES2019 之后規(guī)范要求 sort 是穩(wěn)定的但顯式返回差值是最穩(wěn)妥的寫法也避免了隱式類型轉(zhuǎn)換的坑。筆試時我在這個排序上猶豫過一下要不要對右端點做二次排序后來想明白了不需要。因為左端點排好序后右端點怎么排都不影響合并邏輯我們只需要在合并時取較大的右端點即可。把排序?qū)懙锰珡碗s只會浪費自己的時間。2.3 第三題帶權(quán)最短路徑變形BFS 或 Dijkstra這道題算是三題里最有區(qū)分度的一道。它沒有直接考最短路徑的裸題而是套了一層場景小紅書社區(qū)里有一個筆記瀏覽鏈路的概念現(xiàn)在給出一系列筆記 ID 與相關筆記 ID的映射關系連接兩篇筆記有一個親密度權(quán)重要求從起點筆記出發(fā)找到到達目標筆記的最小總代價路徑其中代價定義為路徑上所有權(quán)重的乘積。這個場景包裝其實沒有改變題目的本質(zhì)——它就是一個帶權(quán)無向圖的最短路問題。但由于權(quán)重是乘積形式你沒法直接套用 Dijkstra 的加法邏輯需要先轉(zhuǎn)換思路。我當時第一反應是乘積的最短路徑不能用加法最短路的思路直接做。但我很快意識到如果所有權(quán)重都是大于 1 的整數(shù)那么最短路徑的這個乘積最小問題等價于對每條邊取對數(shù)把乘積變成求和。不過在筆試環(huán)境下你不可能用一個受浮點誤差影響的技巧來冒險。實際上這道題更簡單的解法是BFS 優(yōu)先隊列Dijkstra 思想因為邊權(quán)是正數(shù)Dijkstra 是有效的。雖然 Dijkstra 一般是用加法但它的貪心邏輯同樣適用于乘積最小的代價函數(shù)——只要代價函數(shù)滿足單調(diào)不減的性質(zhì)。乘法的最短代價有另一個特性如果所有權(quán)重都是正數(shù)大于 1那路徑越長乘積越大所以我們依然可以用 Dijkstra 的貪心選擇當前最小代價策略。/** * 帶權(quán)圖最短乘積路徑用 Dijkstra 思想 * param {number} n 節(jié)點數(shù) * param {number[][]} edges [u, v, weight] 無向邊 * param {number} start 起點 * param {number} end 終點 * return {number} 最小乘積無法到達返回 -1 */ function minProductPath(n, edges, start, end) { // 鄰接表構(gòu)建 const graph Array.from({ length: n }, () []); for (const [u, v, w] of edges) { graph[u].push([v, w]); graph[v].push([u, w]); } // dist[i] 表示從 start 到 i 的當前最小代價 const dist new Array(n).fill(Infinity); dist[start] 1; // 起點代價為 1不經(jīng)過任何邊 // 小頂堆優(yōu)先隊列每次取出代價最小的節(jié)點 // 這里用數(shù)組模擬筆試時更推薦直接用數(shù)組 sort 或手寫簡單最小堆 const pq [[1, start]]; // [代價, 節(jié)點] while (pq.length 0) { pq.sort((a, b) a[0] - b[0]); // 每次取最小筆試夠用 const [cost, node] pq.shift(); if (node end) return cost; if (cost dist[node]) continue; for (const [neighbor, weight] of graph[node]) { const nextCost cost * weight; if (nextCost dist[neighbor]) { dist[neighbor] nextCost; pq.push([nextCost, neighbor]); } } } return -1; }重點說說我在這里踩的坑。我當時第一版代碼用的是純 BFS沒有優(yōu)先隊列結(jié)果在搜索時可能出現(xiàn)先訪問到代價較大路徑導致后面更優(yōu)路徑被跳過的問題。因為 BFS 天然是按跳數(shù)擴展的而不是按代價擴展的這在每步代價不同的帶權(quán)圖中必然出錯。我 debug 了大概 8 分鐘才反應過來帶權(quán)圖的最短路徑問題本質(zhì)上是 Dijkstra不是 BFS。如果你在筆試里遇到帶權(quán)圖最短路徑大腦里要立刻彈出 Dijkstra 而不是 BFS。另一個細節(jié)是數(shù)組模擬優(yōu)先隊列的效率問題。筆試的數(shù)據(jù)量一般控制在幾百個節(jié)點、幾千條邊以內(nèi)所以就算我用了每次 sort 取最小這種笨方法也完全能 AC。但如果你在本地跑大樣例發(fā)現(xiàn)超時就需要手寫一個二叉堆來優(yōu)化。我建議平時就練一練手寫最小堆筆試時直接默寫出來會穩(wěn)很多。第三題還有一個容易漏掉的條件路徑代價是乘積所以初始代價要從 1 開始而不是從 0 開始。很多同學習慣性地把起點 dist 設成 0這在小規(guī)模測試下可能沒錯但一旦遇到起點和終點是同一個節(jié)點或起點到終點只有一條邊的情況答案就會出錯。3. 選擇題里的前端攔路虎這些概念最容易丟分3.1 事件循環(huán)與 Promise 混著出選擇題里比較惡心的就是事件循環(huán)的變體題。它不會單純問你宏任務和微任務哪個先執(zhí)行而是給你一長串代碼里面有 setTimeout、Promise.resolve、async/await、requestAnimationFrame 混在一起讓你寫出輸出順序。我當時遇到的一道題大概是這樣的變體console.log(1); setTimeout(() console.log(2), 0); Promise.resolve().then(() { console.log(3); setTimeout(() console.log(4), 0); }); async function test() { console.log(5); await Promise.resolve(); console.log(6); } test(); console.log(7);這道題的輸出順序是什么呢當時我的判斷邏輯是同步代碼先執(zhí)行依次輸出 1、5然后遇到 awaitawait 讓出線程繼續(xù)執(zhí)行同步代碼輸出 7本輪同步代碼結(jié)束后執(zhí)行微任務隊列先輸出 3這是 Promise.resolve().then 注冊的回調(diào)然后在 3 的回調(diào)里注冊了一個 setTimeout(4)接著執(zhí)行 await 后面的 console.log(6)輸出 6微任務隊列清空后執(zhí)行宏任務隊列先輸出 setTimeout(2) 的 2再輸出 setTimeout(4) 的 4最終輸出順序是1、5、7、3、6、2、4。這個考點背后是一個很關鍵的原則每次執(zhí)行完一個宏任務后必須清空整個微任務隊列再取下一個宏任務。而await本質(zhì)上就是一個微任務不是直接在原地同步等待。很多同學會把 async/await 理解成同步等待其實它在同步代碼執(zhí)行到 await 時就會返回一個 Promise后續(xù)代碼被包裹成一個微任務放回隊列。這個理解不到位遇到稍微復雜點的混編題就會錯。我復習時有個習慣把事件循環(huán)題目歸類成純宏微任務、含 Promise 鏈、含 async/await、含 DOM 渲染四種每類找?guī)椎李}刷透。筆試實際碰到的題目基本都是這個套路換湯不換藥。3.2 閉包、原型鏈與 this 的三合一考法第二個容易丟分的方向是閉包 原型鏈 this 指向結(jié)合出題。它會給你一個構(gòu)造函數(shù)、一個實例方法、一個箭頭函數(shù)讓你分析某次調(diào)用時 this 指向誰。舉個例子function Person(name) { this.name name; this.showName function() { console.log(this.name); }; } Person.prototype.sayName function() { console.log(this.name); }; const p new Person(xiaohong); const fn1 p.showName; fn1(); const fn2 () p.sayName(); fn2();這里fn1()調(diào)用時showName里的 this 指向的是 window或者 undefined取決于是否開啟嚴格模式而不是 p 實例所以輸出 undefined 或報錯。而fn2()是箭頭函數(shù)它的 this 是定義時所在作用域的 this也就是全局作用域的 this但箭頭函數(shù)內(nèi)部調(diào)用的是p.sayName()這個方法方法里的 this 依然是 p 實例所以輸出 xiaohong。這道題考察的東西很綜合普通函數(shù)的 this 動態(tài)綁定箭頭函數(shù)的 this 詞法綁定原型鏈方法的調(diào)用方式。難點不在單個知識點而在于你能不能在一段代碼里同時分析出這三層關系。我在復習時總結(jié)了兩個判斷 this 的土辦法看調(diào)用方式obj.method()形式調(diào)用this 就是 obj直接調(diào)用函數(shù)fn()this 是全局對象或 undefined看函數(shù)類型箭頭函數(shù)直接忽略調(diào)用方式只看定義時所在的作用域如果是構(gòu)造函數(shù)里的 this那就看它是不是被new調(diào)用了。new會創(chuàng)建一個新對象并把 this 綁定到新對象上然后構(gòu)造函數(shù)里的 this 就是那個新對象。有時候選擇題里還會加上嚴格模式這個變量。如果你看到代碼開頭有use strict那么fn()直接調(diào)用時 this 就是 undefined而不是全局對象。很多老八股題默認非嚴格模式但新題會專門加嚴格模式來釣魚審題時一定注意看。3.3 HTTP 緩存與瀏覽器渲染的配合題前端筆試卷子里幾乎必考 HTTP 緩存。我記得那次考的是兩問第一問問強緩存和協(xié)商緩存的區(qū)別第二問問「Cache-Control: no-cache」和「Cache-Control: no-store」有什么區(qū)別。這類題特別容易混。我的記憶方法是no-cache允許緩存但使用前必須去服務器驗證是否新鮮即可以緩存但必須協(xié)商no-store完全禁止緩存不能存到任何地方名字上看著no-cache像是不緩存但它實際上是每次都要確認而 no-store 才是真正的絕不緩存。這是幾乎所有前端都會踩的坑筆試里出這道題基本就是送分題變送命題就看你記不記得準。瀏覽器渲染過程也是高頻考點從輸入 URL 到頁面展示完整鏈路是DNS 解析 → TCP 連接 —— 如果 HTTPS 還需要 TLS 握手 → 發(fā)送 HTTP 請求 → 服務器返回資源 → 瀏覽器解析 HTML 構(gòu)建 DOM 樹、解析 CSS 構(gòu)建 CSSOM 樹 → 合并成渲染樹 → 布局Layout→ 繪制Paint→ 合成Composite。選擇題里它不會讓你寫全鏈路而是會在某個環(huán)節(jié)設置陷阱比如DOM 樹構(gòu)建過程中遇到 script 標簽會怎樣——答案通常是暫停 DOM 構(gòu)建先執(zhí)行腳本如果有 defer/async 則不同。你要是沒有實際做過性能優(yōu)化很容易在這類題上栽跟頭。3.4 Vue 與 React 的雙壓考點小紅書前端崗的筆試里Vue 和 React 都會考。不考框架細節(jié)的 API 怎么拼寫而是考思想層面的東西比如Vue 的響應式原理Object.defineProperty / Proxy 的區(qū)別虛擬 DOM 和 diff 算法的基本流程組件通信方式父傳子、子傳父、兄弟組件、跨層級Vue 用 provide/inject 或 Vuex、React 用 Context 或 Redux生命周期鉤子的執(zhí)行時機我記得選擇題里有一道是關于 Vue 3 響應式原理的題目給出的幾個選項分別描述了Proxy和Object.defineProperty的行為差異。這道題本身不難選「Proxy 可以監(jiān)聽對象屬性的新增和刪除」就行但當時還是有很多人漏選了「Proxy 可以監(jiān)聽數(shù)組索引變化」這個選項。很多人只知道 Object.defineProperty 監(jiān)聽數(shù)組有局限但不知道為什么。原因是Vue 2 改寫數(shù)組的 7 個方法push、pop、shift、unshift、splice、sort、reverse來觸發(fā)更新但直接通過索引修改數(shù)組元素arr[0] x無法被偵測到。而 Proxy 天然支持對整個數(shù)組的代理包括索引賦值。這種細節(jié)題在筆試里很受歡迎因為它能精準地區(qū)分背過文檔和真正理解原理的人。4. 簡答/場景題手動實現(xiàn)一個可取消的請求工具筆試的最后有一道場景題我記得題目大概是這樣的在小紅書的信息流場景中用戶快速滑動頁面時會頻繁觸發(fā)網(wǎng)絡請求。請設計一個可取消的請求工具函數(shù)要求支持傳入一個 Promise 并返回一個合并了取消邏輯的新 Promise。當取消被觸發(fā)時該新 Promise 的狀態(tài)變?yōu)橐讶∠⑶也粫绊懞罄m(xù)代碼的異常捕獲。這道題考察的核心其實就是AbortController或手動控制 Promise 狀態(tài)的技巧。在瀏覽器端最常見的是用 AbortController 來取消 fetch 請求在通用場景下可以用一個外部的 resolve/reject 來控制 Promise。我當時給的實現(xiàn)大概是這樣的/** * 包裝一個 Promise使其支持外部取消 * param {Promise} promise 原始請求 * param {AbortSignal} signal 用于取消的信號 * returns {Promise} 可取消的包裝 Promise */ function withAbort(promise, signal) { return new Promise((resolve, reject) { // 如果已經(jīng)取消了直接拒絕 if (signal.aborted) { reject(new DOMException(The operation was aborted., AbortError)); return; } const abortHandler () { reject(new DOMException(The operation was aborted., AbortError)); }; signal.addEventListener(abort, abortHandler, { once: true }); promise.then( (value) { signal.removeEventListener(abort, abortHandler); resolve(value); }, (error) { signal.removeEventListener(abort, abortHandler); reject(error); } ); }); }這樣調(diào)用的時候你可以給 fetch 請求傳入一個 AbortSignal然后在組件卸載或用戶離開頁面時調(diào)用controller.abort()從而取消請求。這個題的加分點在于你能不能答出為什么需要在finally或then里移除事件監(jiān)聽。如果一直掛在 signal 上不移除每次請求都會多一個永遠執(zhí)行不到的 abort 回調(diào)長時間運行后可能造成內(nèi)存泄漏。雖然影響不大但面試官問你這里有什么隱患時你能答出來就是亮點。另外還順帶考察了一個常見的架構(gòu)設計問題請求失敗時要不要彈全局錯誤提示我的思路是要在請求工具層做統(tǒng)一的錯誤碼判斷但不是所有失敗都彈 toast只有「用戶被動感知」的錯誤才彈比如登錄過期、網(wǎng)絡中斷而「代碼主動捕獲」的錯誤比如參數(shù)錯誤、業(yè)務返回碼為 0應該由業(yè)務代碼自己處理。這種場景題沒有標準答案核心是你能否在通用性和業(yè)務侵入性之間找到平衡。5. 筆試備考的三個核心策略5.1 刷題別貪多把 Hot 100 吃透就夠了如果你只剩兩周就要筆試我強烈建議你放棄刷完 500 題的幻想老老實實把 LeetCode 熱題 100Hot 100給刷透。小紅書的筆試題基本就是 Hot 100 的原題或簡單變體。我當時整理了一個優(yōu)先級清單你可以參考優(yōu)先級題型代表題目筆記重點P0滑動窗口無重復字符最長子串、最小覆蓋子串窗口擴展/收縮的邊界條件P0雙指針三數(shù)之和、接雨水排序 左右指針的移動邏輯P0二叉樹遍歷層序遍歷、最近公共祖先遞歸/迭代兩種寫法P1動態(tài)規(guī)劃最長遞增子序列、打家劫舍dp 狀態(tài)的轉(zhuǎn)移方程推導P1圖島嶼數(shù)量、課程表拓撲排序深搜/廣搜都能解決的模板P2堆前 K 個高頻元素、合并 K 個有序鏈表手寫堆/使用優(yōu)先隊列重點不是刷了多少道而是每種題型都能不看答案寫對。我見過太多同學看答案秒懂、自己寫卡死的情況這在筆試里是最致命的——筆試考的是你在 30 分鐘內(nèi)的寫出正確代碼能力不是理解能力。5.2 JS 核心知識點以手寫實現(xiàn)為綱前端筆試的選擇題和簡答題歸根結(jié)底都在考你能否手動實現(xiàn)某個功能。比如讓你手寫Promise.all、手寫debounce、手寫event emitter、手寫深拷貝。這些內(nèi)容在牛客上搜前端手寫題能找到一大堆。我的備考方式是以手寫實現(xiàn)為綱來復習知識點。比如復習事件循環(huán)我就手寫一個簡單的scheduler來控制并發(fā)復習閉包我就手寫一個once函數(shù)復習原型鏈我就手寫new操作符。每寫一個實現(xiàn)你對這個知識點的理解就會深一層。手寫題有幾個高頻考點我列出來你在家可以自己練Promise.all / Promise.race / Promise.allSettleddebounce / throttlenew操作符的模擬實現(xiàn)instanceof的模擬實現(xiàn)call / apply / bind的模擬實現(xiàn)Object.create深淺拷貝一定要記住手寫題不是背代碼而是在寫的過程中理解每一步的觸發(fā)條件和邊界情況。比如bind實現(xiàn)里有當返回的函數(shù)作為構(gòu)造函數(shù)被 new 調(diào)用時this 失效這個邊界情況你不親手寫一遍很難記住。5.3 場景題/簡答題積累業(yè)務話術與方案儲備場景題不像算法題那樣有唯一答案它考的是你怎么把一個業(yè)務需求拆解成可落地的技術方案。我建議你在準備時把常見的場景題分類整理性能優(yōu)化類首屏優(yōu)化、列表渲染優(yōu)化、大量數(shù)據(jù)渲染防卡頓工程化類如何設計組件庫、如何管理公共狀態(tài)、如何做權(quán)限控制網(wǎng)絡請求類請求取消、并發(fā)請求控制、請求重試、接口緩存前端安全類XSS、CSRF、點擊劫持、CSP回答這類問題時我總結(jié)了一個現(xiàn)象 → 原因 → 方案 → 收益的答題模板。先描述業(yè)務場景里出現(xiàn)的具體問題再分析問題的本質(zhì)原因接著給出技術方案最后說這個方案帶來什么收益。筆試的簡答題通常沒有字數(shù)要求嚴格限制但一份結(jié)構(gòu)完整的答案一定會比卷面混亂的得分高。比如上面那道請求取消題我的答案結(jié)構(gòu)就是先說取消請求的常見情境用戶快速滑動頁面再說瀏覽器級方案AbortController然后給出通用 Promise 包裝方案最后補充事件監(jiān)聽的清理細節(jié)。這就能讓閱卷人一眼看到你的技術深度和工程思維。6. 筆試現(xiàn)場的一些真實體會最后聊幾句現(xiàn)場的體會吧這些在正規(guī)面經(jīng)里很少人寫但我覺得比多刷幾道題更有價值。第一牛客筆試環(huán)境的編輯器很基礎沒有代碼補全和格式化所以你平時寫代碼時不要過度依賴編輯器的自動補全。變量名寫全、括號括號對上這些基礎習慣在筆試現(xiàn)場能幫你省下大量 debug 時間。我第一題就吃過少寫一個右括號、編輯器不報錯的虧肉眼排查浪費了 3 分鐘。第二遇到不熟悉的題先跳過別死磕。編程題總耗時只有 55 分鐘左右如果某道題卡了 15 分鐘還沒有清晰思路立刻切下一題。等做完后面有把握的題再回頭啃難點。我當時第三題雖然一開始想錯了方向但因為我保證前兩題都 AC心里比較穩(wěn)才有余裕去 debug 第三題的 BFS 問題。第三選擇題的得分策略是拿不準就不選。不定項選擇少選可以嗎大部分情況下不可以。小紅書這個考試是不定項選擇少選、多選、錯選都不得分。所以如果你對某個選項沒有十足把握寧愿不選也不要碰運氣。再強調(diào)一遍這個規(guī)則和漏選得一半分的多選不一樣一定要看清題目要求。現(xiàn)在回想起來小紅書這批筆試的整體風格很務實算法題不偏不怪選擇題重基礎原理場景題貼近真實社區(qū)業(yè)務的痛點。只要前期準備充分、心態(tài)不崩通過筆試并沒有想象中那么難。希望這份復盤能幫到后面參加筆試的學弟學妹。