去年一個前端工程師在GitHub吐槽：刷了300道LeetCode，面大廠時卻被問懵了——"說說你設(shè)計的UI系統(tǒng)有哪些架構(gòu)權(quán)衡"。他以為考的是框架熟練度，對方要的卻是系統(tǒng)思維。這種錯位正在批量制造面試悲劇。

從"會用React"到"懂React"，中間隔著一座山

第一道題就暴露了分水嶺：React的協(xié)調(diào)（Reconciliation）機制如何工作，什么場景會觸發(fā)重渲染？

初級回答往往停留在"props變了就渲染"。Senior工程師會拆解成三層：虛擬DOM比對算法、Fiber架構(gòu)的優(yōu)先級調(diào)度、以及被忽略的 bailout 機制——為什么同樣的狀態(tài)變更，有時跳過整棵子樹，有時卻全量計算。這背后是React團隊用五年時間把O(n3)的diff降到O(n)的工程取舍。

更隱蔽的考點在第8題：內(nèi)存泄漏排查。大多數(shù)人能說出useEffect的cleanup，但生產(chǎn)環(huán)境的泄漏往往藏在閉包陷阱、事件訂閱未解綁、或者第三方庫的全局緩存里。Senior的簡歷里通常寫著一行："為XX平臺定位并修復了導致頁面崩潰的內(nèi)存泄漏，首屏停留時長提升23%"。

Bundle優(yōu)化不是砍庫，是算經(jīng)濟賬

第3題問大包體優(yōu)化，常見誤區(qū)是羅列Tree Shaking、Code Splitting、Gzip三板斧。真正的大廠追問的是：你量化過每個策略的收益嗎？

一個真實案例：某電商App把lodash全量引入，打包分析顯示它占了首屏JS的18%。但直接替換為按需加載后，轉(zhuǎn)化率反而掉了——因為拆分出的幾十個chunk在弱網(wǎng)環(huán)境下瀑布請求，TTI（可交互時間）惡化。最后的解法是用babel-plugin-lodash做編譯時裁剪，配合預(yù)加載關(guān)鍵路徑，才拿到體積和性能的平衡。

這類問題的本質(zhì)是資源博弈。優(yōu)化不是技術(shù)正確，是業(yè)務(wù)正確。

最狠的題根本不考技術(shù)

第6題讓候選人描述與設(shè)計師、產(chǎn)品經(jīng)理的協(xié)作方式。表面是軟技能，實際在測工程影響力：你能不能把自己的技術(shù)判斷翻譯成業(yè)務(wù)語言？

一個典型場景：設(shè)計師堅持要用復雜的交互動畫，你如何用性能數(shù)據(jù)說服對方？Senior的做法不是甩Lighthouse報告，而是建一個A/B測試框架，把"動畫幀率"翻譯成"跳出率變化"，讓決策變成數(shù)據(jù)問題而非立場問題。

第4題更直接——"講一個你最近交付的功能，以及它產(chǎn)生的影響"。沒有數(shù)據(jù)支撐的回答，在這里直接出局。

accessibility 是門檻，不是加分項

第5題關(guān)于跨區(qū)域、跨能力的無障礙設(shè)計，在北美大廠已經(jīng)是硬性要求。但國內(nèi)很多團隊把它當"政治正確"應(yīng)付。真正做過國際化的人會知道：RTL（從右至左）布局不是簡單翻轉(zhuǎn)CSS，阿拉伯語的連字規(guī)則會讓你的組件庫底層架構(gòu)推倒重來；而屏幕閱讀器的兼容，需要從DOM語義化一路測到焦點管理。

這25道題的編排本身就在傳遞信號：前端工程師的晉升路徑，已經(jīng)從"實現(xiàn)需求"轉(zhuǎn)向"定義問題"?？蚣軙^時，但系統(tǒng)思維、性能嗅覺、跨團隊協(xié)作的方法論，是穿越周期的硬通貨。

最后留一道題——第7題問多團隊共用代碼庫的狀態(tài)管理。你的方案是Redux、Zustand、還是Context？或者，你有沒有想過這個問題本身就是偽命題：當五個團隊往同一個store里寫邏輯時，真正的解法可能不是選什么工具，而是重新劃分服務(wù)邊界？