key 被連續問了四次：攜程支付前端一面，是一份被排好深度的題單

先看那份清單的骨架。2026 年 9 月 8 日，一場攜程支付部門（國內與國際及海外支付方向）的前端一面，事後被整理成面經貼上牛客網。整份清單分三段：實習與項目經歷、JavaScript 基礎、React。段與段之間用整齊的中文章節標題切開，每一題前面掛一個編號。這種版面本身沒有什麼特別，特別的是題目的排列方式：它不是隨機抽取的知識點，而是一條被設計過的下行階梯。

第一段只有五題，全部圍繞實習：負責哪些工作、有什麼具體產出、開發工作流的樣子、Skill 相關工作怎麼設計與使用、定時任務怎麼實現。這裡的訊號很清楚，面試官先要的不是知識，是「你真的做過什麼」。五題裡有兩題落在非常具體的功能名詞上（Skill、定時任務），這種問法逼的是細節，背不出來的答案一追問就會塌。

第二段短得幾乎像過場：閉包是什麼、閉包在實際開發中有哪些應用場景。兩題，一個概念，一個應用。從面試節奏看，這是一段熱身，把候選人從專案敘事切換到語言層，但只停留一下就往下走。真正的重心在第三段。

十題 React，其實是一條被排好的縱深

第三段十題，全數指向 React。前面三題落在 useState、useMemo 與 useCallback、useEffect 與 useLayoutEffect，這是 Hook 的基本盤。但從第六題開始，畫風變了：Diff 過程是怎樣的、key 起什麼作用、為什麼要求 key 唯一且穩定、什麼樣的 key 才算好的 key、同層節點 Diff 時 React 如何利用 key 進行匹配。

同一個名詞被連續追問四次。從「是什麼」到「為什麼」再到「怎麼算好」，最後落到實作層面的匹配機制。這種排列方式本身就是一種介面設計：它假設候選人第一題答得出來，於是用後續題目不斷收窄，直到探到知識的底部。對照我們先前觀察過的蔚來實習面經的題目順序，兩份清單的邏輯一致，篩選的深度都藏在追問的密度裡，第一段的編號只是門面。

評論區也給了基準。有人留言「問的都很基礎」，另有人回「JS 問得深」。兩種讀法其實都對，取決於你把清單讀成點還是線。單看每一題，閉包、useMemo、key，都是前端面試的常見物；把它連成線看，從 Hook 用法一路壓到 Fiber 架構與 Diff 匹配演算法，這條線的坡度並不緩。第五題「React 為什麼要引入 Fiber 架構」插在 Hook 題與 Diff 題之間，像一個轉軸，把話題從「怎麼用」轉到「底層為什麼長這樣」。

支付部門的視角，決定了題單的配色

值得注意的是部門屬性。這是支付部門的面試，涉及國內與國際及海外支付方向。支付場景的前端對狀態一致性的要求極高，一筆訂單的狀態更新、一次清單的重繪，都直接對應金流。回頭看題單，useState 的狀態更新過程、useEffect 與 useLayoutEffect 的時序差異、key 不穩定導致的節點錯配，這些題目在支付語境下都不是純知識，是事故現場的預演。key 用索引還是用業務唯一標識，在行銷頁上可能只是效能問題，在支付頁上就是列表項與金額對錯位的風險。

換個比較對象，來源頁面同時推薦的騰訊音樂前端面經裡，出現的是重繪重排、HTTP 請求頭、BFC、事件循環這類橫向鋪開的題目；而字節 AIDP 的面經則把重心放在 skills 與大模型輸出結構化資料，這與我們先前分析過的字節秋招二面的 AI coding 評估介面走向一致。攜程這份清單的不同處在於縱深：它捨棄了廣度，把十題全押在同一個框架的內部結構上。這種取捨本身就是部門性格的排版。

面經作為一種被閱讀的介面

最後看這份文件為什麼會被流傳。一份面經要能傳播，靠的是可讀性：日期、部門、編號題目、章節分段，這些格式把一場一小時左右的對話壓縮成一張可以收藏的清單。後來的讀者拿它當考古地層，從題目分布反推部門的技術棧與用人偏好；面試者拿它當複習範圍，把 key 的四連問當成必背。清單越具體，它作為介面的價值越高。

這份攜程支付面經給出的觀察是：一份好的技術面試題單，長得就像一份好的介面文件。段落的優先級、追問的層次、名詞重複出現的節奏，都在告訴讀者這個團隊在意什麼。基礎題不代表淺，當同一個 key 被問到第四次，深度就已經被排進版面裡了。