一場模擬考，三道代碼題，最后掛在了一個組件命名上。這是韓國開發(fā)者社區(qū)最近流傳的一份前端基礎?？紡捅P，出題人沒考算法，?？?代碼該放哪"的直覺。

核心矛盾很簡單：數據請求（query）該寫在父組件還是子組件里？

考生拿到的場景是預約狀態(tài)頁面。父組件`ReservationStatusPage`調了`useMyReservations`，拿到數據后傳給子組件`MyReservationSection`?？雌饋順藴剩腥私涣肆硪环荽鸢浮裛useMyReservations`直接塞進子組件。

兩種寫法都能跑，評分卻天差地別。

命名即契約

關鍵在`MyReservationSection`這個名字。一旦加了"Reservation"這個業(yè)務域前綴，組件就自動背負了一條隱性契約：我處理的是預約相關的完整邏輯，不是單純的數據展示框。

出題人點評：「外部傳數據，等于強迫父組件了解子組件的內部菜單。子組件自己拉數據，抽象層級才對齊?！?/p>

這個判斷標準被考生稱為"命名審計"——讀一遍組件名，如果它暗示了業(yè)務域，那數據自治就是本分。

Compound Pattern的陷阱

另一道題考的是`TimeSelect`組件的復合模式寫法?？忌鷮懗隽饲短捉Y構：`TimeSelect.Title`、`TimeSelect.Option`層層包裹，語法糖拉滿。

但樣例代碼里藏了個低級錯誤：兩個`Option`都寫了`10:30`，第二個還錯把閉合標簽寫成`TimeSelect.Title`。

更隱蔽的問題是——這種API設計在真實業(yè)務里怎么擴展？如果產品經理突然要加"已約滿"狀態(tài)，是新增`TimeSelect.DisabledOption`，還是給`Option`加props？復合模式的優(yōu)雅往往停在Demo階段，遇到需求變更就開始漏風。

模考背后的真實篩選邏輯

這套題出自韓國某頭部電商的前端團隊，他們招人的核心標準不是"會不會寫"，而是"寫之前能不能聞到代碼的氣味"。

`useMyReservations`放哪里的爭論，本質是考你對"關注點分離"的理解深度。放父組件，父子之間多了條數據管道，未來任何一方改動都可能扯斷這條線；放子組件，父組件徹底變成布局容器，兩邊各自獨立演化。

有考生復盤時吐槽：「考前刷了200道算法，結果輸在命名品味上?！?/p>

出題團隊在討論區(qū)補了一刀：「我們團隊去年重構了17個頁面，14個的bug追溯到'數據該放哪'的初始決策。算法題能刷出來，這種直覺刷不出來?！?/p>

這份?？寄壳氨环g成中文在前端社區(qū)小范圍流傳，有人做了在線版本，正確率不到四成。最扎心的反饋來自一位五年經驗開發(fā)者：「看完答案覺得簡單，但讓我現場寫，肯定選錯?！?/p>

如果讓你重考，`useMyReservations`會放在哪？