資深前端模擬面試：從效能觀念題到 useRef 實作題的深度驗收

1. 效能優化：從程式碼內到打包外 0:00–2:55

第一題直接問「你怎麼改善應用程式效能」。答題者建立了一條由內而外的檢查順序：先用 profiling 工具找不必要的 re-renderi，用 memo / useMemo / useCallback 擋掉；再看 state 結構是否造成連鎖 re-render，把 prop drillingi 的狀態上移到 Redux 等全域狀態；再把圖表這類重元件改成 dynamic importi 搭配 Suspense。最後才走出程式碼，看 bundlei 大小、tree shakingi 與 gzip。面試官追問 tree shaking，答題者說明它是把沒被用到的 import 從 bundle 移除。

推理因為開場題必須讓受試者自己攤開知識地圖，所以面試官挑了範圍最大的效能題；而受試者的回答方式本身就是答案的一部分——他沒有隨口丟名詞，而是建立了一條由內而外的檢查順序：先看元件層（不必要的 re-render，用 memoizationi 擋掉）、再看狀態層（結構不良與 prop drilling 造成連鎖 re-render，把狀態上移到全域）、再看載入層（重元件改 dynamic import 搭 Suspense），最後才走出程式碼看 bundle 本身（大小、tree shaking、gzip）。面試官在他說出 tree shaking 之後立刻回頭追問定義，這是在確認名詞是背來的還是懂的。

• R受試者的效能檢查順序→ 存＋回想
• P依四層(元件/狀態/載入/bundle)做一次效能檢查→ 練習

AI 補充這條順序值得記下來，因為它同時是一份除錯清單：從「畫面重畫太多次」往「送給瀏覽器的東西太多」走。受試者省略了一步——他說「用 profiling 工具找不必要的 re-render」，但沒說怎麼判定「不必要」。實務上的判準是：這次 re-render 有沒有讓畫面的任何一個像素改變；React DevTools Profiler 的 highlight updates 可以直接看出哪些元件重畫了卻沒改變外觀。另外他把 memoization 講得像萬用解，但 React.memo / useMemo 本身也有比較成本，只有在元件重、或它的 props 幾乎不變時才划算；先修 state 結構通常比到處包 memo 有效。至於他最後說「用 React 這類框架大多會自動處理」，指的是 bundler（webpack / Vite / Turbopack）在 production build 預設就會做 tree shaking 與壓縮，不是 React 本身做的。

2. Reconciliation 與 diffing 演算法 2:55–3:48

面試官從「效能」轉向「React 為什麼能只更新一部分」。答題者說明 React 維護一份 virtual DOMi（真實 DOM 的副本），變動時拿新舊 virtual DOM 比對，用 diffing 演算法找出改變的部分再更新真實 DOM，整個比對加更新的流程就叫 reconciliationi。

推理因為上一段整段都在談「少做一點事」，所以面試官接著問 React 內部本來就在做的那件「少做一點事」是什麼。受試者的推導是三步：React 在記憶體裡維護一份 virtual DOM，也就是真實 DOM 的輕量副本；狀態變動時產生一份新的 virtual DOM，拿去和舊的比對；比對用的是 diffing 演算法，找出差異後只把那部分寫回真實 DOM。他明確把「比對 + 更新」這整條流程命名為 reconciliation，把演算法本身命名為 diffing。

• CReact維護virtual DOM，狀態變動時用diffing演算法比對，只把差異寫回真實DOM→ 畫地圖
• Ediffing演算法的兩個關鍵假設：不同型別整棵重建、同層子元素靠key配對→ 存＋演練

AI 補充這個回答正確但少了關鍵的一步：為什麼要多維護一份副本？因為直接操作真實 DOM 很貴——每次寫入都可能觸發瀏覽器重算 layout。virtual DOM 是用便宜的 JavaScript 物件比對，換掉昂貴的 DOM 寫入。另外受試者沒提到 diffing 演算法的兩個關鍵假設，而這正是上一段 re-render 問題的根源：第一，不同型別的元素直接整棵重建，不往下比；第二，同一層的子元素靠 key 來配對，這就是列表沒給 key、或拿陣列 index 當 key 會出錯的原因。理解這兩點，才知道為什麼上一段說的「memo 擋 re-render」是在 reconciliation 之前就先剪掉一整棵子樹，效果比讓 diffing 慢慢比對好得多。

術語:diffing algorithmi

3. 瀏覽器渲染流程：Critical Rendering Path 3:48–4:36

問題再往下一層：瀏覽器拿到 bundle 之後怎麼變成畫面。答題者依序拆解——解析 HTML、解析 CSS、建 DOMi、建 CSSOMi，接著算 layouti、painti，最後交給 GPU 合成並輸出像素，並指出這整條流程叫 critical rendering pathi。

推理因為上一段把責任交棒給了瀏覽器，所以面試官順勢把層級再往下推一層。受試者依序拆出這條流水線：解析 HTML、解析 CSS，分別建出 DOM 與 CSSOM；把兩者合起來算 layout，決定每個元素的位置與大小；接著 paint 畫出各層的內容；最後交給 GPU 合成，輸出成螢幕上的像素。他自己把整條流程命名為 critical rendering path。

• C解析HTML/CSS建出DOM與CSSOM→算layout→paint→合成後交GPU輸出像素→ 畫地圖
• Rcritical rendering path漏掉的哪一層決定CSS屬性貴賤→ 存＋回想

AI 補充順序正確，但中間漏了一個對前端最有實務意義的環節：paint 之後、送 GPU 之前還有 compositing（合成）這一層，瀏覽器把畫面拆成多個 layer 分別上傳 GPU，再由 GPU 疊起來。這一層之所以重要，是因為它決定了哪些 CSS 屬性便宜、哪些貴：改 width / top 會回到 layout 重算（reflow），改 background-color 從 paint 開始重來，而改 transform / opacity 只動到合成階段，可以完全交給 GPU。這正是「動畫用 transform 不要用 top / left」這條老規則的來源。另外他也沒提到這條路徑會被阻塞——外部 CSS 是 render-blocking，沒有 defer / async 的 script 會擋住 HTML 解析，這才是上一段講的 bundle 大小之所以會拖慢首次畫面的真正機制。

4. Debounce 與 Throttle 的差別 4:36–6:20

面試官問兩者差異。答題者先說共同目的：減少連續觸發的使用者事件；差別在「怎麼減」。debouncei 是等使用者停手後延遲時間到才觸發一次；throttlei 是在每段延遲區間內最多觸發一次。他用 300ms 搜尋框舉例：連續輸入時 debounce 只在停下後發一次，而 throttle 在同樣情境會固定間隔各發一次。面試官複述確認 throttle 是固定間隔執行。

推理因為前三段都在談「一次更新有多貴」，所以面試官接著問「怎麼少觸發幾次」。受試者先點出兩者的共同目的：減少連續的使用者事件；再把差別收在一句話上——debounce 是延遲之後只發一次，throttle 是每段延遲區間內最多發一次。接著他用 300 毫秒的搜尋框把差別演出來：連續打字時 debounce 會一路等到使用者停手、再過 300 毫秒才發一次；同樣的輸入在 throttle 下則會固定每 300 毫秒發一次。面試官複述「throttle 是固定間隔執行」來確認理解一致。

• Cdebounce是延遲後只發一次，throttle是每段區間內最多發一次→ 畫地圖
• R選debounce還是throttle的判準→ 存＋回想

AI 補充受試者的定義正確，但漏了選擇的判準，而那才是面試想聽的：問「中間過程的結果有沒有用」。搜尋建議只有最後一次輸入有意義，用 debounce；捲動位置、滑鼠拖曳、視窗縮放這類過程本身就要即時反饋，用 throttle。另一個他沒提的細節是 leading / trailing——debounce 預設在延遲結束時執行（trailing），但按鈕防連點需要的是 leading：立刻執行第一次、後續忽略。這一點在本片最後的實作題裡會再出現一次，因為受試者遇到連按 start 的問題時第一個想到的正是 debounce。

5. Closure：函式記得外層變數 6:20–7:07

轉進 JavaScript 語言本身。答題者定義 closurei 為：內層函式能記住並存取外層函式的變數，即使外層函式已經執行完畢。他用 count 變數與 increment 內層函式舉例，並點出這在多數其他語言不會發生，是 JavaScript 的特性。

推理因為前面幾題都靠框架 API 就能答，面試官需要確認地基是不是也穩，所以問了 closure。受試者的定義是：一個函式能記住並存取它外層函式的變數，即使外層函式早已執行完畢。他用最小的例子演示——外層函式裡有一個 count 變數與一個 increment 內層函式，呼叫 increment 時仍然能存取 count。他還補了一句對照：這在多數其他語言不會這樣運作，是 JavaScript 的特性。

• C函式記得並能存取它出生時的外層變數，即使外層函式早已執行完畢→ 畫地圖
• Aclosure像搬到外地工作的人依然記得家鄉地址，即使已離開很久→ 批判類比

AI 補充定義正確，但少了「為什麼」。關鍵在於 JavaScript 的函式在被建立時，會帶著一個指向它出生環境的參照；只要這個函式還活著，那個環境就不會被垃圾回收，即使建立它的函式已經 return。所以 closure 不是函式「複製」了變數，而是「共用」了同一個變數——這解釋了為什麼在迴圈裡用 var 建立多個函式時，它們最後拿到的是同一個值，而 let 因為每圈都建立新的綁定就不會有這個問題。closure 也是這一場後半實作題的隱形主角：受試者把 setInterval 的 id 存進區域變數時，那個變數確實被 closure 記住了，但每次 re-render 都會建立一份新的，於是 stop 按鈕拿到的是新的那份、清不掉舊的計時器。

6. this 的指向與三種調整方式 7:07–8:38

延續語言特性，面試官問 thisi。答題者給的定義是：this 指向「呼叫該函式的那個物件」，物件呼叫自己的方法時 this 就是該物件，否則落到全域 this。接著補上箭頭函式i沒有自己的 this、會從語彙作用域i往外拿，以及可用 bind / call / applyi 指定 this，並提到 explicit binding 與 implicit binding 兩種綁定。

推理因為上一段已經建立了「作用域由出生位置決定」的框架，所以這一題自然是它的對照。受試者給的定義是：this 指向呼叫該函式的那個物件；用 obj.fn() 呼叫時 this 就是 obj，否則落到全域 this。接著他主動加上一層對比：箭頭函式沒有自己的 this，會從語彙作用域往外拿——也就是回到上一段那條「由出生位置決定」的規則。最後他補上第三層：想要更大的彈性可以用 bind、call、apply 明確指定 this，並把這兩類情況命名為 explicit binding 與 implicit binding。

• Cthis指向呼叫該函式的物件；箭頭函式沒有自己的this，從語彙作用域往外拿→ 畫地圖
• Rthis的四種綁定優先順序→ 存＋回想

AI 補充這是全場最完整的一個回答，三層結構清楚。可以補的是完整的優先順序，實務上按這個順序判定：new 綁定（this 是新建的物件）> 明確綁定（bind / call / apply）> 隱式綁定（obj.fn()）> 預設綁定（非嚴格模式下是 globalThis，嚴格模式下是 undefined）。而箭頭函式不參與這整套規則，它根本沒有自己的 this。另外要注意一個受試者沒點破的陷阱：隱式綁定會在函式被「取出來」時消失——const f = obj.fn; f() 的 this 就不是 obj 了，這正是把方法直接當 callback 傳進 addEventListener 或 setTimeout 時會出錯的原因，也是 class 元件時代要在 constructor 裡寫 this.handleClick = this.handleClick.bind(this) 的理由。

7. useRef 與 useState 的分工 8:38–9:49

回到 React。答題者用「會不會觸發 re-render」切開兩者：useRefi 用來記住一個跨 re-render 仍然存在的值，更新它不會重新渲染；useStatei 是會觸發 re-render、進而更新畫面的狀態。他用 focus 元素當例子說明何時該選 useRef，面試官複述確認「useState 才觸發 re-render」。

推理因為第 4 段的 debounce / throttle 已經證明受試者能用一句話切開相近的概念，面試官再用同型題確認他在 React 上也做得到。受試者抓的判準是「會不會觸發 re-render」：useRef 用來記住一個跨 re-render 仍然存在的值，改它不會重新渲染；useState 是會觸發 re-render、進而讓畫面更新的狀態。他用「想 focus 某個元素、但不想為此重新渲染」當例子。面試官複述確認只有 useState 會觸發 re-render。

• CuseRef記住跨re-render仍存在的值，改它不會觸發re-render；useState才會→ 畫地圖
• AuseRef像口袋隨身記事本寫了馬上看得到；useState像公告欄要等下次巡視才更新→ 批判類比

AI 補充判準抓得準，但少了一個更根本的差別：useRef 的更新是同步且立即可見的，ref.current = 1 之後馬上讀就是 1；而 useState 的更新是排程的，setState 之後在同一次 render 裡讀到的仍是舊值。這條差別決定了什麼東西該放進 ref——凡是「需要立刻讀到最新值、而且不該影響畫面」的東西：計時器 id、上一次的值、DOM 節點、是否為首次 render 的旗標。反過來說也有一條硬規則：ref 的改變不會通知 React，所以任何要顯示在畫面上的東西都不能只放在 ref 裡。這一段的內容會在二十分鐘後的實作題被逐字驗收——那題的正解就是「把 interval id 放進 ref」，而受試者在這裡明明答對了定義，實作時卻卡住。

8. 生命週期方法到 useEffect 9:49–11:02

面試官問 React 的生命週期。答題者以 hooks 出現為分界：以前有 componentDidMount、componentDidUnmount 等在元件誕生與銷毀時觸發的方法；hooks 之後改由 useEffecti 承接。他說明依賴陣列i的三種行為——空陣列時只在掛載時跑、回傳的函式在卸載時跑、陣列內的值變動時重新觸發。

推理因為上一段確認受試者熟悉 hooks，面試官用生命週期題測他知不知道 hooks 取代了什麼。受試者以 hooks 的出現為分界線推導：以前有 componentDidMount、componentDidUnmount 這類在元件掛載與卸載時觸發的方法，統稱 lifecycle methodsi；hooks 之後這些職責改由 useEffect 承接。接著他拆解依賴陣列的三種行為——空陣列時只在掛載時跑一次、回傳的函式在卸載時跑、陣列裡的值變動時重新觸發。

• Chooks之後生命週期方法改由useEffect承接，依賴陣列決定何時重跑→ 畫地圖
• RuseEffect依賴陣列的思考方式跟lifecycle有什麼不同→ 存＋回想

AI 補充推導正確，但有兩處需要修正。第一，正確的方法名是 componentWillUnmount，不是 componentDidUnmount——元件卸載後就沒有實例可以呼叫方法了，所以只有 will 沒有 did。第二，他在描述空依賴陣列時說「會在元件 unmounted 時觸發」，前後文顯示他要說的是 mounted，這是口誤但值得記住正確版本：空陣列 = 只在掛載後跑一次。更重要的是一個他完全沒提到的觀念轉向：useEffect 不是 lifecycle 的一對一替代品。React 官方文件明確指出，思考方式應該從「在哪個時間點做什麼」換成「這個 effect 要跟哪些值同步」。依賴陣列不是效能開關，而是宣告「我用到了這些值」；漏填就會造成上一段提過的 stale closure。React 18 的 StrictMode 在開發模式下會刻意把 effect 掛載、卸載、再掛載一次，就是為了逼出沒有正確清理的 effect。

9. SSR 為什麼快，又為什麼利於 SEO 11:02–13:02

問題擴大到 Next.js 的 SSRi。答題者說明伺服器先算好、建好 DOM 再把 HTML 交給客戶端，因此渲染是即時的；且 SSR 每一個 request 都會執行，適合資料頻繁且不可預期更新的頁面，例如電商的商品列表頁。面試官追問其他好處，答題者提到效能，面試官補上 SEOi，答題者接著說因為 HTML 已在伺服器產好，LCP、FCP 這些指標會比較好看。

推理因為前面幾段都在談「畫面在瀏覽器裡怎麼產生」，面試官把同一個問題挪到伺服器端：如果 HTML 在伺服器就先算好，會怎麼樣？受試者的推導是：伺服器先計算資料、建好 DOM 元素、把完成的 HTML 交給客戶端，所以渲染是即時的，不必等客戶端再發 API 請求。接著他補上 SSR 的一個特性——每一個 request 都會重新執行，因此適合資料頻繁且不可預測更新的頁面，並以電商的商品列表頁為例。面試官追問還有什麼好處，受試者只答得出效能，面試官直接補上 SEO；受試者接住並說明因為 HTML 已在伺服器產好，LCP、FCP 這些指標會比較好看。

• RSSR改善的是什麼時間，不是什麼時間→ 存＋回想

AI 補充回答方向正確，但把兩件事混在一起了。SSR 讓使用者「更早看到內容」是真的（改善 FCP、LCP），但頁面要能互動還得等 JavaScript 下載並完成 hydrationi——在那之前按鈕是沒反應的。所以 SSR 改善的是「看得到」的時間，不是「用得動」的時間，有時甚至會讓可互動時間變晚。另外受試者說 SSR 適合「頻繁不可預測更新的頁面」是對的，但漏了 Next.js 真正的決策矩陣：內容幾乎不變用 SSG（build 時產生）、會變但可容忍幾秒延遲用 ISR（定時重新產生）、必須每次都最新或跟使用者身分有關才用 SSR。電商商品列表其實最常用 ISR，因為它比 SSR 便宜得多。至於 SEO，現代 Google 爬蟲確實會執行 JavaScript，但排隊渲染會延遲索引，而且其他社群平台的爬蟲多半不執行 JS——這才是 SSR 對 SEO 真正的價值。

術語:LCP / FCPi

10. 全域錯誤邊界：卡關與正解 13:02–15:40

這題答題者答不出來。他先把 global error boundaryi 理解成「出錯時顯示的 fallback 畫面」，提到 Next.js 的 error page，又轉去講在 API 共用函式裡用 try/catch。面試官兩次把問題拉回「任何元件出錯時如何全域捕捉、避免整個 app 崩潰」，並問他有沒有 class componenti 經驗；答題者說只用過 function component。最後面試官直接給出答案：class component 的 componentDidCatchi 方法，包住整個應用來攔截錯誤，而 function component 沒有對應寫法。

推理因為前面確認了受試者的 React 知識建立在 hooks 之上，面試官問 global error boundary 就是要測那條界線在哪。受試者的推導繞了三圈：先把它理解成「出錯時顯示的 fallback 畫面」，提到 Next.js 有 error page 功能；再轉去講在共用的 API 函式裡用 try / catch 捕捉。面試官兩次把問題拉回精確的定義——任何元件裡發生錯誤時如何全域捕捉、避免整個應用崩潰——並直接問他有沒有 class 元件經驗，受試者答只用過函式元件。他最後猜了 AggregateError，仍不對。面試官於是揭曉：class 元件有 componentDidCatch 方法，用它包住整個應用就能即時攔截錯誤；而函式元件沒有對應的寫法。

• C任何元件出錯時全域捕捉、避免整個應用崩潰；目前只有class元件有原生解→ 畫地圖
• Rerror boundary攔不住哪些錯誤→ 存＋回想

AI 補充面試官的正解正確但講得太短，有兩點值得補。第一，error boundary 需要兩個方法搭配：getDerivedStateFromError 負責更新 state 以顯示 fallback UI，componentDidCatch 負責記錄錯誤（送到 Sentry 之類的服務）。第二，也是最實用的一點——實務上今天沒有人手寫 class，大家用的是 react-error-boundary 這個套件，它把 class 包好，對外提供函式元件的 API 與 useErrorBoundary hook。至於受試者提到的 Next.js error page 其實不算離題：App Router 的 error.tsx 就是框架幫你套好的 error boundary，只是它綁定路由層級，無法像手動放置的 boundary 那樣精細地包住某一個 widget。還有一個兩邊都沒提的邊界：error boundary 只攔得住 render 階段的錯誤，事件處理器、setTimeout、以及非同步程式碼裡的錯誤它一律接不到——那些仍然要靠 try / catch，也就是受試者最先講的那個方向。所以他其實答對了一半，只是沒能把兩半接起來。

11. 一萬筆列表與 code splitting 15:40–17:45

兩題共用同一個想法：不要一次把全部東西交出去。列表題答題者提出 virtual list——只渲染使用者看得到的項目，捲動時再把其他項目掛上 DOM；面試官追問函式庫，答案是 react-window。code splittingi 題他用五、六頁的應用舉例：使用者只進 settings 頁時，就只送該頁需要的程式碼，面試官順勢把它歸結為「降低 bundle 大小」。

推理因為要在進入實作前確認基本盤穩固，面試官連問兩題「怎麼不要一次全給」。列表題受試者答 virtual list——只渲染使用者視窗內看得到的項目，捲動時再把後續項目掛上 DOM，把一萬個節點壓到十幾個；面試官追問函式庫，受試者猜了「React Virtual DOM」，面試官補正為 react-window。code splitting 題他用五、六頁的應用舉例：使用者只進 settings 頁時就只送該頁需要的程式碼，不必把全部頁面的程式一起下載；面試官順勢把它歸結成一句「就是降低 bundle 大小」。

• R虛擬列表最難的部分→ 存＋回想

AI 補充兩題的答案都對，但可以各補一層。虛擬列表最難的不是「只渲染看得到的」，而是撐出正確的捲軸高度與處理高度不固定的項目——項目高度不一時要邊捲邊量測、動態修正，這是 TanStack Virtual 這類函式庫的主要價值。另外現在有純 CSS 的輕量方案 content-visibility: auto，適合結構簡單的長列表。至於 code splitting，受試者說得像是伺服器有選擇性地送——實際上是 bundler 在打包時就把程式切成多個 chunk，瀏覽器依路由或 dynamic import 去要對應的檔案。這正好接回第 1 段他自己提過的 dynamic import：那是寫在原始碼裡的切點，code splitting 是它在打包層的結果。要注意切得太碎反而變慢，因為每個 chunk 都是一次額外的網路往返。

術語:virtualizationi

12. WebSocket 與請求／回應模型的差別 17:45–18:48

最後一題觀念題。答題者以 HTTP 的「一個 request 對一個 response」作對照：WebSocketi 是先建立連線、監聽某個 room，之後送進該 room 的資料會持續推給客戶端，不需要客戶端不斷發請求。面試官複述為「即時資料傳輸」，答題者補上股票即時報價的使用情境。

推理因為前面所有題目都預設 HTTP 的請求／回應模型，面試官用最後一題觀念題檢查受試者知不知道還有別的模型。受試者的推導從對照開始：HTTP 是一個 request 對一個 response；WebSocket 則是先建立連線、開始監聽某些 room，之後只要有資料送進那個 room 就會持續推給客戶端，客戶端不需要一直發請求。面試官把它複述成「即時資料傳輸」，受試者補上股票即時報價當使用情境。

• CWebSocket建立連線後持續推資料給客戶端，不必一直發請求，跟HTTP請求/回應相反→ 畫地圖
• RWebSocket的room是原生功能嗎→ 存＋回想

AI 補充描述正確，但「room」其實不是 WebSocket 本身的概念——那是 Socket.IO 這類函式庫在協定之上加的抽象。原生 WebSocket 只給你一條雙向管線，房間、自動重連、斷線緩衝都要自己或靠函式庫實作。另外面試官沒追問、但資深職位通常會考的是選型：只需要伺服器單向推播（通知、進度條、AI 逐字輸出）時，Server-Sent Eventsi 更簡單——它走 HTTP，瀏覽器內建自動重連，也不需要另一套基礎設施。真正需要 WebSocket 的是雙向且高頻的場景：協作編輯、多人遊戲、聊天室。至於受試者舉的股票報價，兩者都可行，取決於客戶端要不要送東西回去。還有一個常被忽略的實務點——WebSocket 是長連線，伺服器端要處理連線數上限、心跳偵測與水平擴展時的訊息廣播，成本比看起來高。

術語:pollingi

13. 實作題開場：碼表的三個要求 18:48–21:09

進入螢幕分享的實作題。面試官示範需求：兩顆按鈕，按 start 每秒累加，按 stop 立即停住，再按 start 從停下的數字接著跑，而且連按多次 start 也不能加速。答題者打開本機編輯器（提到公司目前用 Claude Code），先用 setIntervali 寫出第一版，面試官提醒先把 CTA 做成按鈕、外觀不用管。

推理因為前面的問答已經證明受試者的知識廣度足夠，面試官改測執行力。他先在瀏覽器裡示範預期行為，把需求壓縮成三條可驗收的規則：按 start 每秒累加一次；按 stop 立刻停住；再按 start 從停下的數字接著跑。示範完他追加了第四條，也是這題真正的考點——連按多次 start 不能讓數字加速。受試者打開本機的 Cursor 編輯器（順帶提到公司目前用的是 Claude Code），用 useState 存 count、用另一個 isCounting 狀態當開關，在 useEffect 裡依 isCounting 呼叫 setInterval。面試官只提醒把 CTA 做成按鈕、外觀不用管。

AI 補充從截圖可以看出第一版的結構已經埋好了後面所有的坑。程式碼是：useEffect 監看 isCounting，為真時呼叫 setInterval 每秒 setCount(prev => prev + 1)；兩顆按鈕分別把 isCounting 設成 true 與 false。setCount 用函式形式是對的（呼應第 7 段提過的批次更新），但有兩個結構性問題。第一，setInterval 回傳的計時器 id 沒有被接住——它只存在於那次 effect 的 closure 裡（見第 5 段），一旦元件因為 count 改變而 re-render，就再也沒有人握著那個 id 可以清掉。第二，effect 沒有回傳清理函式，所以 isCounting 每次變動都會疊加一個新的 interval，舊的照跑。值得注意的是，這一題的正解正是他在第 7 段親口說對的那句話——「useRef 用來記住跨 re-render 仍然存在的值」，而計時器 id 正是這種值。

14. clearInterval 失效：提示改用 useRef 21:09–24:15

第一版的 stop 沒有作用。面試官指出問題在 clearIntervali 拿不到正確的 interval id，並給提示：把 interval 存進 useRef 的 context 裡。答題者卡在「怎麼把值放進 ref」，以為 useRef 一定要綁在某個元素上；面試官說明可以直接把任意值存進 ref.current，停止時再從那裡拿來清掉。

推理因為 stop 按鈕沒有作用，面試官直接指出病灶：這裡清不掉 interval，因為你手上沒有正確的計時器 id。他給的提示只有一句——把 interval 放進 useRef 的 context 裡，刻意不給寫法。受試者卡住的點不是不知道 useRef 是什麼（他在第 7 段才剛正確定義過），而是他認定 useRef 一定要綁在某個 DOM 元素上，於是不斷問「怎麼把值放進 ref」。面試官最後把那層誤解拆掉：ref 不需要綁任何元素，可以直接把任意值指派給 ref.current，停止時再從那裡取出來清掉。

• Estop按鈕寫onClick={() => clearInterval(1000)}，把延遲毫秒數當成計時器id傳了進去→ 存＋演練

AI 補充截圖裡看得到當時的中間狀態：stop 按鈕寫的是 onClick={() => clearInterval(1000)}——把延遲毫秒數當成計時器 id 傳了進去。這個寫法不會報錯，因為 clearInterval 收到不存在的 id 只會靜靜地什麼都不做，這正是這類 bug 難找的原因。同時 useEffect 的 else 分支裡還留著兩行註解掉的 clearInterval(interval)，可以看出他原本想用區域變數接住 id，發現作用域不對之後就註解掉了——他其實摸到了正確方向，只差把那個變數換成 ref。這段暴露的是一個很典型的落差：受試者對 useRef 的記憶是「用來取得 DOM 元素」這個最常見的用例，而不是它的本質「一個跨 render 不變的容器」。判斷什麼該放進 ref 的標準只有一條——這個值變了，畫面需不需要跟著變？計時器 id 不需要，所以它屬於 ref。

15. hook 不能巢狀，與命名的建議 24:15–26:21

答題者把 useRef 寫進 useEffect 裡而報錯。面試官反問原因並揭曉：hook 不能放在另一個 hook 裡面。接著他建議這題根本不需要 useEffect，只要在 start／stop 事件裡處理即可，而且真實面試時應該把邏輯抽成獨立函式、取 startCounter / stopCounter 這類有意義的名字，而不是用一個共用函式靠參數分流。

推理因為錯誤已經跳出來，面試官先反問受試者知不知道原因，確認他是照著提示改還是真的理解。受試者答不出來，面試官揭曉：不能在一個 hook 裡面呼叫另一個 hook。接著他做了一件更有價值的事——不只修錯，還修結構。他指出這題根本不需要 useEffect，只要在 start 與 stop 的事件處理器裡直接處理就好；並且建議真實面試時應該把邏輯抽成獨立函式，取 startCounter、stopCounter 這種有意義的名字，而不是像受試者打算的那樣寫一個共用函式、靠參數字串分流。

• Chook只能在元件或自訂hook的最頂層呼叫，不能寫在條件、迴圈或巢狀函式裡→ 畫地圖
• P判斷邏輯該寫進事件處理器還是useEffect→ 練習

AI 補充面試官的說法要精確一點：Rules of Hooksi 的規定是 hook 只能在元件函式或自訂 hook 的最頂層呼叫，不能寫在條件、迴圈或巢狀函式裡。useEffect 的 callback 就是一個巢狀函式，所以在裡面呼叫 useRef 違規。理由是 React 靠呼叫順序而不是名稱來對應每次 render 的 hook 狀態，順序一變就會錯位。從截圖可以看到當時的畫面：整個 useEffect 被註解掉了一大半，只剩 stopWatchRef = setInterval(...) 這行留在按鈕的 onClick 裡——注意它寫的是 stopWatchRef 而不是 stopWatchRef.current，這個遺漏會在下一段被面試官抓出來。至於「不需要 useEffect」這條建議，值得單獨記住：React 官方文件有一篇專門講「你可能不需要 effect」，判準是——這件事是回應使用者的操作而發生的嗎？是的話就寫在事件處理器裡；只有需要跟外部系統同步時才用 effect。碼表由按鈕觸發，屬於前者。

16. 連按 start 的 bug 與錯誤方向 26:21–29:25

面試官先修正寫法：值要存進 stopwatchRef.current（第 12 行）。接著請答題者連按三四次 start，暴露出計數加速的 bug。答題者依序提出 debounce、加一個 hasStarted 狀態、useCallbacki 記憶化，面試官逐一擋掉並要求「不要多寫程式碼，只找出這個 bug」。

推理因為結構已經修好，面試官先處理最後一個語法層面的問題：值必須存進 stopWatchRef.current，位置在第 12 行。改完之後他請受試者連按三、四次 start，數字立刻加速——第 13 段開場就宣告過的第四條要求現在被驗收了。受試者依序提出三個方向：先想到 debounce，自己隨即發現不行（間隔久一點的兩次點擊仍會各觸發一次）；再提出加一個 hasStarted 狀態來擋；最後猜是要用 useCallback 記憶化。面試官逐一擋掉，並收緊題目——不要多寫任何程式碼，只要找出這個 bug。

• E受試者想到debounce時自己發現不行——就算兩次點擊隔十秒仍各觸發一次→ 存＋演練
• E編輯器跳出Type 'Timeout' is not assignable to type 'null'的錯誤→ 存＋演練

AI 補充面試官擋掉這三個方向的理由值得拆開看，因為它們代表三種常見的思考偏差。debounce（第 4 段定義過）是在「事件太密集」時用的，但這裡的問題不是點擊太密集，而是每一次點擊都合法地又開了一個計時器——就算兩次點擊隔十秒，一樣會有兩個 interval 在跑。hasStarted 狀態方向是對的，但它是在原本就該存在的資訊之外，額外再造一個平行的真相來源；ref 裡有沒有值本來就已經代表「有沒有在跑」了，多一個 state 就多一個要同步的東西。useCallback 則完全無關——它只影響函式的參照是否穩定，不影響按鈕被按幾次。受試者自己也馬上意識到這點。從截圖可以看到此時程式碼已經重構成一個 updateCountLogic('start' | 'stop') 的共用函式，而編輯器正跳出 TypeScript 錯誤 Type 'Timeout' is not assignable to type 'null'——這其實是個線索：ref 的型別被宣告成可以是 null，但程式從來沒有把它設回 null 過。

17. 真正的修法：清掉 ref 並在啟動前檢查 29:25–30:36

面試官給出答案：stop 時只呼叫 clearInterval，ref 裡仍留著舊值，所以要一併把 ref 設為 null（第 16 行）。改完仍不動，因為 start 還缺一個守門條件——只有在 ref.current 沒有值時才啟動 interval，加上否定判斷後功能正常。面試官宣布面試結束，答題者只要求回饋。

推理因為受試者始終在「加東西」而不是「看現有狀態」，面試官直接給出診斷：stop 只呼叫了 clearInterval，ref 裡仍留著舊的計時器 id，所以程式無從判斷現在到底在不在跑。修法是在 stop 時一併把 ref 設成 null（第 16 行）。改完仍然沒解決連按的問題，因為還缺另一半——面試官補上最後一塊：只有在 ref.current 沒有值的時候才啟動 interval。受試者先把判斷式寫反了，加上否定之後碼表終於符合全部四條要求。面試官宣布面試結束，受試者只要求回饋。

• Aref有沒有值就是有沒有在跑的答案，像倉庫有沒有貨就代表訂單有沒有在處理→ 批判類比
• P把計時器id存進ref、啟動前檢查、停止後設回null→ 練習
• R這題最終的完整解法是什麼形狀→ 存＋回想

AI 補充把兩塊拼起來，這題的完整解法只有三行的形狀：start 時先檢查 if (!ref.current) 才 setInterval 並把 id 存進 ref.current；stop 時 clearInterval(ref.current) 之後把 ref.current 設回 null。ref 在這裡同時扮演兩個角色——既是計時器 id 的保管處，也是「現在有沒有在跑」這個狀態本身。這正是第 16 段裡 hasStarted 那個方向被擋掉的理由：那個資訊本來就已經存在，只是沒被清乾淨所以不可信。從兩張截圖的對照可以看出修好的過程：第一張 count 停在 39、按鈕沒反應，第二張 count 從 5 開始正常累加。這一段也回頭驗證了整場面試的推論——受試者在第 7 段就正確說出「useRef 用來記住跨 re-render 存在的值」，在第 14 段拿到了「把 interval 存進 ref」的明示提示，卻仍需要面試官逐行帶著走完。知道一個 API 的定義，和知道它在一個具體問題裡該承擔什麼角色，中間隔著的正是這場面試想量的距離。

術語:single source of truthi