面試官從實習專案一路追到快取八股：CapCut這場前端一面，把「挖到底」三個字演滿了

9月7日，一篇標題寫著「字節秋招 CapCut 前端一面涼經」的貼文出現在牛客網。發文者段位不低：三段實習，字節剪映商業化、B站直播平臺 Agent Skill、騰訊 TEG WorkBench 評測都寫在履歷上，外加一個 CSISP Monorepo 全棧專案。這樣的背景去面 CapCut 前端，最後仍然以「涼」收場，面經本身就成了求職圈圍觀的素材。

先看這場面試的形狀

整場面試大致可以拆成三塊：自我介紹與實習深挖、前端基礎題、手撕與演算法。看起來是標準流程，但字節的問法有個明顯特徵，就是每一題都是從上一題「長」出來的，面試官不換頻道，只往深處挖。

舉個例子。發文者先講了字節剪映實習時做過的即時屬性配置抽離，把兩千行前端硬編碼搬到線上平臺配置，再用 React Hook 封裝調度。面試官接著要求用一句話總結這兩件事。回答之一是「針對重複接口請求，用 Hook 加類 Promise 狀態管理實現同快取鍵僅一次請求」。

然後點評式追問來了：這件事本質就是接口快取，那單聊接口快取你有哪些方案？

於是話題從專案滑進了八股，而且滑得毫無痕跡。這種「由專案自然延伸」的出題方式，近期的秋招面經裡越來越常見，騰訊IEG那份把AI協作開發問在八股之前的面經也曾引發類似討論，兩相對照，大廠面試的提問邏輯正在從背題轉向追人。

一道快取題，問出了三層樓

發文者對接口快取的作答，是這篇面經裡最有內容的部分，值得展開看。

第一層是 HTTP 與瀏覽器快取：Cache-Control 的 max-age、Expires、ETag、Last-Modified，瀏覽器直接命中本地快取，連實際請求都可以省掉，或者只發協商請求。第二層是服務端快取：Redis 之類的中間件擋在資料庫前面，BFF 層也可以掛 KV 快取。第三層才是前端應用層：自己設計快取鍵、做請求去重，in-flight 的請求掛起來復用同一個 Promise，持久化則看需求選記憶體、localStorage、sessionStorage 或 IndexedDB。

發文者自己下了個總結：本質是請求去重加快取的結合，等價於 SWR 或 React Query 的核心能力。這句話在留言區被不少人按讚，因為它把框架黑話還原成了原理，也是這類面經最能啟發後來人的地方。

接下來的追問順理成章：localStorage 跟 IndexedDB 差在哪、什麼業務場景用哪個。發文者的答案很有畫面感。localStorage 適合主題偏好、語言設定、登入態、引導彈窗是否已讀這種小體積低頻讀寫；IndexedDB 則適合線上畫板的操作歷史與撤銷棧、棋類對局的棋譜與悔棋棧、影片圖片編輯器的本地素材與 Blob 資源。

注意到了嗎，最後一條根本就是 CapCut 的業務本身。面 CapCut，問本地大檔案怎麼存，這題出得相當貼合崗位，也讓這篇涼經多了一層「被業務考題精準命中」的戲劇性。這種貼著業務場景出題的傾向，和美團那場把考題藏進「如果讓你設計」的Agent面試如出一轍，大廠似乎越來越不滿足於純八股的篩選效果。

涼在哪裡：一次老八股的記岔

整場面試的轉折點，發文者自己標了警告符號。

題目是展開講講瀏覽器快取。經典八股，但發文者坦承很久沒背，有些記岔了，而且岔得不輕：把「協商快取」和 CORS 的 OPTIONS 預檢請求混在了一起。

發文者事後用 AI 幫自己復盤，整理出三個概念的正確分界。協商快取是帶 If-None-Match 或 If-Modified-Since 的正式請求，服務端回 304 或 200，沒有額外預檢。預檢請求是 CORS 跨域機制，非簡單請求先發 OPTIONS，跟快取完全無關。至於「簡單請求與非簡單請求」這組分類，也是 CORS 的概念，由 method、請求頭和 Content-Type 決定，跟快取體系沾不上邊。

另外還有一個連帶的觀念修正：GET 請求默認可快取，是因為它是冪等的安全方法，跟「簡單請求」無關；要破快取，正確做法是響應頭設 Cache-Control: no-store，或者前端加時間戳、隨機 query 參數。

這段自曝失誤的復盤，反而是整篇貼文圍觀度最高的部分。求職圈向來不缺完美答案，缺的是有人願意把「我哪裡答錯了」攤開來給大家看。兩個名字相近的機制，一個在快取層、一個在跨域層，平時寫程式幾乎不會主動想起它們的差別，偏偏面試官一追就現形。

這也解釋了為什麼履歷漂亮仍然會涼。專案深挖扛住了，實習難點答了，快取三層樓也爬了，但一段基礎概念的混淆，就足以讓面試官對「基礎是否扎實」打上問號。秋招一面的篩選邏輯往往就是這樣，不需要你答得多亮眼，只需要你在某個點上露出不夠穩的訊號。

手撕與演算法：兩道經典題收尾

第三部分是手撕題與演算法題各一。手撕題是帶最大併發上限的併發調度器，演算法題是最大子陣列和，力扣第 53 題。

發文者對這兩題的評價只有一句：都是很經典的題了，詳情看文件。語氣輕描淡寫，但熟悉前端面試的人都知道，併發調度器是這兩年被問到爛的題型，考的是 Promise、佇列管理與限流思維的綜合運用；最大子陣列和則是動態規劃的入門經典。從出題難度看，這場一面沒有刁難，走的是穩健路線，難是難在前面的連環追問。

原本發文者放了一個飛書文件連結收錄完整作答，後來擔心違規拿掉了，只留正文「湊合看看」。這個小插曲本身也是牛客面經生態的縮影：外部文件、截圖、口述重建，求職者用各種方式把一場面試的記憶盡量完整地存進社羣，供下一屆的人取用。

涼經為什麼永遠有人看

把視角拉遠一點，這類涼經的價值從來不只是對答案。

對當屆求職者來說，它是雷達圖。哪些題被問了、追問停在多深、答錯在哪個概念分界，這些資訊比任何攻略都即時。對旁觀者來說，它是一份行業體感：字節的 CapCut 前端在考什麼，答案是把兩千行硬編碼抽成配置的能力、把介面快取講成三層的能力、把 localStorage 與 IndexedDB 按業務場景拆開的能力，外加不記岔協商快取與預檢請求的基本功。

發文者最後的心得沒有太多情緒，更多的是把失誤一條條列出來的工程師式坦誠。三段大廠實習的履歷配上一次記岔的八股，這個組合提醒所有正在準備秋招的人：專案可以包裝，實習可以累積，但基礎題的每一條分界線，面試官都摸得到。

一場涼掉的面試，被完整地寫下來，就成了下一個人的地圖。這大概就是牛客網上這些涼經年年流出、年年有人圍觀的原因。