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