一個題目被換了三次外套：攜程前端的一面，是一條被排好坡度的題流

10 月 8 日，牛客網上流傳出一則攜程 27 屆秋招前端開發一面的面經。發文者把整場面試列成二十七個條目，從自我介紹開始，到反問收尾，中間近一個小時的對話被壓縮成一份編號清單。這份清單本身，就是這場面試留下來最完整的介面。

先從第三題看起：「數組怎麼去重」。這是前端面試裡最老的一種題，老到幾乎所有求職者都背過 Set、includes、indexOf 幾種寫法。但它的位置值得注意：它排在第二題「數組和鏈表的區別」之後。一題考資料結構的常識，一題考程式碼的手感，兩題相鄰，把「你知道什麼」和「你寫得出什麼」放在同一個段落裡量了一次。

再往下，第五到第七題是純 CSS 地帶：flex 屬性、響應式佈局、怎麼畫三角形。這三題有一個共同點，它們都在考「畫面是怎麼被排出來的」。三角形尤其誠實，border 的透明邊、寬高歸零，這個小手法最能看出一個人是否真的理解盒模型，因為它沒有別的用處，純粹是理解的展示。

真正的設計出現在第十三到十五題。防抖和節流先被問了定義，緊接著第十四題換了場景：「以攜程 app 用戶頻繁點擊圖片為例，是防抖還是節流，為什麼」。同一個知識點，先考背誦，再考判斷。留言區裡也有人點出這一題的用意：考的不是定義，是先判斷觸發頻率。這種「定義加場景」的連問結構，讓題目從查核變成了推理，也讓清單在視覺上出現了節奏的變化。

長列表那兩題是另一處。第十九題問卡頓解決方案，第二十題追問不定高虛擬列表如何計算位置。虛擬列表是前端效能裡最能體現工程思維的題目之一，因為它要求在已知方案上處理現實的不完美。這條追問線一路延伸到第二十一題的效能瓶頸排查，形成這份題單裡最長的一段深挖，與我們先前分析的攜程支付前端一面的 React 題組有相似的深挖節奏。

最後七題轉向 AI：大模型為何兩次回答不一致、RAG 召回機制、prompt 優化如何驗證。發文者自己標註了「後面是 ai 相關的問題」。從陣列一路排到 LLM 的輸出是概率事件，這條題流記錄的其實是 2025 年前端工程師技能邊界的移動：打包工具之後，緊接著就是 agent。

發文者最意外的一點是「面了近一個小時，居然一點項目沒問」。兩段大廠實習產出完全沒被碰到，這對一份面經來說是最大的訊息：這場面試被設計成純知識與推理的篩選介面，經驗不在量測範圍內。留言區裡另一位湖北的求職者回覆「感覺跟你是一個面試官，問的問題基本都一樣」，說明這份題單可能是一套被反覆使用的模板。模板化意味著可預期，也意味著篩選的維度被固定在了題目的坡度上，而不是候選人的經歷上。

這類題單的排版值得多看一眼。求職者把口語的對話壓縮成編號條目，追問被摺進主題裡，情緒只剩結尾一句「答的很爛很緊張，希望能過」。整場面試的焦慮與表現，最後被收攏成一份任何人都能對著複習的清單。面經作為一種介面，它的設計目標從來不是重現面試，而是讓下一次面試變得可準備。這一點，它做得比大多數正式文件都好。