React 面試題庫

openAI

React 面試題庫

以下題庫按模塊分類（React 架構與運行機制、核心 API、Diff 算法與事件機制、Fiber 架構與調度、并發模式與過渡、生命周期及新版生命周期對照、綜合源碼題、擴展專題、React 與 Vue 對比），并按難度（初級、中級、高級）分組。每題附參考答案，包含原理解析和關鍵源碼思路，并引入文獻資料說明。

React 架構總覽與運行機制

初級問題

問：React 的核心架構由哪些部分組成？
答： React 核心包含兩個主要模塊：調和器（Reconciler）和渲染器（Renderer）。調和器負責執行組件的 render 方法生成虛擬 DOM（Virtual DOM）并對比新舊虛擬 DOM 樹以找出差異；渲染器（如 ReactDOM）負責將這些差異應用到真實 DOM 或目標環境中。React 通過虛擬 DOM 實現聲明式編程：開發者只需描述 UI 應處于什么狀態，React 會負責把真實 DOM 同步到該狀態。
問：什么是 Virtual DOM？它有什么作用？
答： Virtual DOM 是一種在內存中的虛擬表示，用來模擬真實 DOM。React 在內存中維護虛擬 DOM 樹，當組件狀態或屬性發生變化時，生成新的虛擬 DOM 樹并與舊樹進行對比（協調/Reconciliation），只將變化部分更新到真實 DOM。這種方式使得開發者可用聲明式 API 編寫界面，只需指定 UI 應該是什么樣子，React 會通過 Virtual DOM 高效更新真實 DOM。
問：React Fiber 是什么？為什么引入 Fiber？
答： Fiber 是 React 16 引入的新型協調引擎（即新版本的調和器），其主要目的是支持增量渲染和任務調度。在 React 16 之前，調和過程是遞歸且同步的，一次更新可能耗時很長，影響瀏覽器幀率。Fiber 將渲染工作拆分為可中斷的任務片段，引入任務優先級調度機制，可以將高優先級任務插隊執行，從而讓界面保持更好響應性。

中級問題

問：React 協調（調和）過程是什么？Diff 算法的核心原則有哪些？
答：協調（Reconciliation）是 React 同步虛擬 DOM 與真實 DOM 的過程。其核心就是 Virtual DOM 的 diff 算法。React 的 diff 算法主要有三條原則：同級比較（只比較同一層級的節點，不跨層查找）、類型不同則整體替換，類型相同則遞歸比較（不同類型元素直接替換，類型相同則保留原節點并更新屬性，然后對子節點遞歸比較）、列表節點通過 key 來復用（若列表中節點有唯一 key，React 會根據 key 來復用節點，避免不必要的刪除和重建）。這些原則讓 diff 過程高效，復雜度從指數級降為線性級。
問：React 15 的架構有哪些缺點？React 16 是如何改進的？
答：在 React 15 中，調和器為棧調和器（Stack Reconciler），即更新過程是同步執行的遞歸操作。由于瀏覽器每 16.7ms 重繪一次，如果一次更新遞歸遍歷的組件樹很深且復雜，可能導致更新耗時超過一幀，造成頁面卡頓。React 16 引入了 Fiber 調和器（Fiber Reconciler）和調度器（Scheduler），將更新拆分為小任務，按優先級調度執行，使得高優先級的任務能打斷低優先級的更新，以保持界面流暢。Fiber 在執行中分為兩個階段：渲染（Reconciliation）階段可以被中斷，用于創建新的 Fiber 樹并找到變更節點；提交（Commit）階段一次性將修改同步到真實 DOM，過程不可中斷。
問：React 如何支持多平臺渲染（如瀏覽器端和原生端）？
答： React 將渲染器（Renderer）抽象為可替換的模塊。常見渲染器有 ReactDOM（瀏覽器 DOM）、React Native（原生移動端）、React Test（測試場景下純 JS 對象）、React ART（畫布、SVG）等。無論哪個渲染器，都復用相同的協調器算法，只需要提供將虛擬 DOM 對象最終轉換為目標環境元素的方法。這樣 React 通過不同渲染器適配多種平臺，同時保留了相同的組件和協調邏輯。

高級問題

問：在 React 中，一個組件更新的觸發路徑是怎樣的？
答：當組件狀態或屬性改變時，會觸發調度更新過程。大致步驟：用戶代碼調用 setState（類組件）或更新 Hooks 狀態，內部會調用調度函數 scheduleUpdateOnFiber；調度器將更新放入更新隊列，并啟動執行工作循環 workLoopSync。workLoopSync 遍歷 Fiber 樹：每個工作單元通過 performUnitOfWork 調用 beginWork，為當前 Fiber 計算新的輸出 Fiber，并將下一個單元推進（深度優先遍歷）。完成整棵樹后，進入提交階段（調用 commitWork 等），一次性將所有變更應用到真實 DOM。核心源碼中涉及函數包括 createFiberFromTypeAndProps（根據元素類型創建 Fiber）和 beginWork、completeWork 等。
問：React 更新過程中的優先級調度是如何組織的？
答： React 在協調器中引入了任務優先級的概念，將更新任務分為幾個等級：同步（synchronous）、任務（task）、動畫（animation）、高（high）、低（low）、離屏（offscreen） 等級。Fiber 調和器將更新拆分為多個小片段執行，每個片段結束后會檢查是否有更高優先級任務需要插隊。例如，渲染周期內如果有用戶輸入（高優先）和普通數據刷新（低優先）同時發生，調度器可先中斷低優先渲染，優先處理用戶輸入事件。每種優先級對應不同的調度隊列，使得 React 能保持對高優先級更新的快速響應。

React 核心 API（Hooks）

初級問題

問：useState 的基本用法和特性是什么？
答： useState 是函數組件中用于聲明狀態變量的 Hook。調用 const [state, setState] = useState(initialValue)，返回當前狀態 state 和更新函數 setState。setState 可以直接傳入新值，也可以傳入一個接收舊狀態并返回新狀態的函數（函數式更新）。若傳入函數，則會在更新時基于最新狀態計算新值。注意：在一次渲染中，直接使用變量更新（setState(state + 1)）不會累加，因為 state 在當前閉包中是固定的；而使用函數式更新（setState(prev => prev + 1)）會以最新值為基礎依次累加。
問：useEffect 有什么作用？默認情況下何時執行？
答： useEffect 用來在函數組件中執行副作用（例如數據獲取、DOM 操作、訂閱等）。它接收一個副作用函數和可選的依賴數組。默認情況下，副作用函數會在每次組件渲染完成后執行。比如，我們希望組件掛載后更改網頁標題，則需要在 useEffect 中執行該操作。React 文檔說明：每次渲染后執行 effect，如果指定了依賴數組，僅在依賴變化時才執行。在組件卸載時，可返回一個清理函數來撤銷副作用（如移除事件監聽）。
問：useRef 有什么用途？
答： useRef 返回一個可變的 ref 對象，其 current 屬性可保存任意值。與 useState 不同，修改 ref 的 current 不會觸發組件重新渲染。常用的用法是獲取 DOM 節點引用或在組件渲染之間保持某個值。例如，const inputRef = useRef(null) 后可把 <input ref={inputRef}> 綁定到 DOM 元素上，組件渲染后 inputRef.current 就指向該 DOM 元素。也可將其用作實例變量，保存不需要參與渲染的值。
問：useMemo 和 useCallback 的區別是什么？
答：兩者都是性能優化的 Hook，但用途不同。useMemo 接收一個 “計算函數” 和依賴數組，僅在依賴變化時重新執行函數并返回值，否則返回上一次緩存的值。主要用于避免在每次渲染時做昂貴的計算。useCallback 接收一個函數和依賴數組，只有在依賴變化時才返回一個新的函數實例，否則返回上一次的同一個函數。因此，useMemo 緩存的是計算結果值，useCallback 緩存的是函數本身。底層原理中兩者實現機制相同，都是通過比對依賴項決定是否更新。

中級問題

問：useState 的更新是同步還是異步？多次調用有何區別？
答：在 React 中，函數組件內調用 setState 并不會立即更新 state 變量，它是異步批量調度的。這意味著在同一個渲染周期里直接使用舊的 state 計算新值會無效。例如連續三次 setCount(count + 1) 只會導致最終值加 1；而如果使用函數式更新 setCount(prev => prev + 1) 三次，則最終加了 3。這是因為前者三次執行時閉包中的 count 不變，而后者通過函數參數拿到最新狀態逐次累加。在需要基于先前狀態連續更新時，應使用函數式更新形式。
問：useEffect 與 useLayoutEffect 有何區別？
答：兩者 API 相同，唯一區別是執行時機不同。useEffect 的副作用在瀏覽器完成畫面更新后異步執行，適用于一般的異步操作（數據請求、訂閱等）。而 useLayoutEffect 的副作用會在 DOM 變更并渲染到屏幕之前同步執行，常用于需要同步測量 DOM 或做防閃爍處理的場景。簡單說，useLayoutEffect 在瀏覽器繪制前執行，useEffect 在繪制后執行，以免阻塞渲染。若無特殊需求，優先使用 useEffect。
問：useCallback 和 useMemo 底層原理一致嗎？有什么區別？
答：在 React 18 源碼中，useCallback 與 useMemo 的內部實現是相同的：都調用了名為 areHookInputsEqual 的依賴項比較函數。當依賴未改變時，兩者都會返回緩存內容；唯一區別在于：useMemo 返回新計算的值對象，useCallback 返回新創建的函數實例。因此，兩者實際上都是在對比依賴數組后決定是否更新緩存，只是緩存內容不同，一個緩存數據，一個緩存函數。

高級問題

問：React Hooks 的更新隊列是如何管理狀態更新的？
答：在 React 源碼中，每個函數組件對應的 Fiber 節點上，會維護一個 Hook 鏈表，每次 useState 調用都會往鏈表上掛鉤子（Hook）對象。調用 setState 時，React 會將更新（Update 對象）放入對應 Hook 的更新隊列，并通過調度函數 scheduleUpdateOnFiber 觸發 Fiber 樹的重新協調。在下次渲染時，React 會遍歷該組件的 Hook 鏈表，依次取出每個 Hook 的更新隊列，按順序應用各個更新（隊列采用環形結構，每次重置）。這樣，組件會基于先前狀態逐步計算出最新狀態并渲染。
問：useState、useEffect 等 Hooks 的調用順序有什么要求？為什么？
答： React 要求 Hooks 在組件頂層按照固定順序調用，不能放在條件、循環或子函數中。這是因為 React 通過調用順序將每個 Hook 對應到 Fiber 節點上的 Hook 存儲結構：每次渲染都會按調用順序依次“消費”對應的 Hook 緩存位置。如果調用順序不一致，就會導致前后渲染時 Hook 對應錯亂，狀態錯位。因此所有 Hook 必須在組件體頂部或自定義 Hook 內部，并且條件分支中要保持所有分支調用相同數量的 Hooks。

React Diff 算法與事件機制

初級問題

問：React 的 Diff 算法有哪些重要特性？
答： React 的 Diff 算法主要針對同層級節點進行比較，對于跨層級的節點差異采用整體替換的策略。其核心思想可以歸納為三點：一是同層比較——不同層級的節點不做跨層調整，同層內如果新節點不存在則刪除對應舊節點；二是類型匹配——如果元素類型不同，則直接銷毀舊節點并創建新節點；若類型相同（同為標簽或同為組件），則僅更新屬性和遞歸比較子節點；三是列表 Key——在可重排列表的更新中，如果給列表元素加上唯一 key，React 會根據 key 來復用節點，避免無謂的 DOM 刪除和重建。這三原則保證了更新效率并盡量減少實際 DOM 操作。
問：什么是 React 的合成事件（SyntheticEvent）？它的作用是什么？
答：合成事件是 React 對瀏覽器原生事件的跨瀏覽器封裝。React 所有事件處理函數接收到的參數都是一個合成事件對象，它模擬了標準的 DOM 事件接口，提供一致的 API。在內部，React 采用事件委托的方式，只在根容器（React 17+ 中為對應根節點）統一注冊少量事件監聽器，當事件觸發時通過合成事件對象統一派發給組件中的回調。使用合成事件的好處是：對不同瀏覽器原生事件有一致的處理方式，還可以實現如事件池機制（回收對象提高性能）等優化。合成事件的屬性和方法與原生事件類似，例如 event.target、event.preventDefault() 等都是可用的。
問：React 中如何阻止事件冒泡？
答：在 React 合成事件中，可以通過調用 event.stopPropagation() 來阻止事件傳播（冒泡）。需要注意的是，React 的合成事件會先觸發 React 層的捕獲/冒泡回調，再觸發原生 DOM 的事件傳播。調用 stopPropagation() 不會阻止 React 內部的合成事件生命周期，但會阻止原生事件的繼續傳播。此外，也可以在JSX中直接指定 onClick={e => e.stopPropagation()} 來防止向上傳遞。

中級問題

問：解釋 React 事件委托的機制。
答： React 使用事件委托技術來處理事件。早期版本（React 17 之前）將所有事件綁定到 document 上，由 React 自己內部判斷目標并派發到對應組件；React 17+ 將事件綁定到各個根 DOM 節點上，但仍是統一管理。這樣做的優點是減少了瀏覽器事件監聽器的數量，方便統一處理。對于不能冒泡的事件（如 onScroll），React 會直接在對應元素上綁定原生監聽器。因此在 React 中，不需要手動為每個元素都添加事件監聽函數，React 在后臺自動做了委托。
問：React Diff 算法的復雜度是多少？如何通過 key 優化列表渲染？
答：默認情況下，React 的 diff 算法在比較同層子節點時，如果沒有 key，采用索引對比：新舊節點按位置一一比較，同層比較的復雜度是 O(n)。如果指定了穩定的 key，React 會基于 key 構建映射表，匹配更效率更高，以避免大量節點移動。也就是說，給列表元素設置唯一且穩定的 key 可以極大提升列表更新效率，因為 React 會復用具有相同 key 的組件和 DOM，減少不必要的刪除和重建，且更加準確地保持組件狀態。
問：在 React 中合成事件對象何時被回收？有什么注意事項？
答：早期版本的 React 使用事件池來回收合成事件對象，以降低頻繁創建對象的開銷。也就是說，React 在派發完事件后，會將合成事件對象的屬性重置并放入池中重復使用。這意味著如果在異步回調中訪問事件對象（如在 setTimeout 后），可能會遇到事件已被清空的問題。如果要在異步中使用事件，可以調用 event.persist() 來將其從池中移除。需要注意的是，React 17+ 已經移除了事件池，合成事件現在不會自動重用，所以可直接在異步中訪問事件屬性也安全。

高級問題

問：描述一次 React 組件更新時的事件處理流程。
答：當組件觸發事件（如按鈕點擊）時，React 首先在根節點捕獲到原生事件，然后創建一個合成事件對象（SyntheticEvent）。React 會按照捕獲/冒泡階段在虛擬 DOM 樹上從上往下或從下往上查找符合觸發條件的組件，并依次調用其事件處理函數。事件處理函數執行期間可以調用 event.preventDefault()、event.stopPropagation() 等方法。事件調用結束后，如果事件對象是可復用的，React 會將其屬性清空并回收到對象池。這一切都在更新組件狀態或執行副作用前完成，之后如有狀態更新會觸發組件重新渲染。
問：React 的 unstable_flushDiscreteUpdates 有什么作用？
答：（源碼級問題）unstable_flushDiscreteUpdates 是 React 內部用于同步處理離散事件（如點擊、輸入等）的低層 API。在并發模式下，用戶交互事件會優先級更高，而非緊急更新。使用 flushDiscreteUpdates 可以強制立即同步地刷新這些離散更新，保證在用戶交互中優先響應。這是 React 調度器內部處理任務優先級的一部分，通常在 React 內部自動調用，用戶代碼一般無需直接使用。其核心原理在于將某些更新標記為同步更新，從而繞過時間切片調度立即執行。

Fiber 架構與調度機制

初級問題

問：React Fiber 架構帶來了哪些變化？
答： Fiber 架構引入了**可中斷的協程（協作式調和）**機制。在舊的架構中，更新是同步且不能打斷的；Fiber 將每次更新過程拆分為多個小任務（Fiber 單元），并在兩個渲染周期之間檢查是否有更高優先級的任務需要插入。Fiber 架構將組件樹的每個節點用 Fiber 對象表示，每個 Fiber 節點包含必要的狀態和副作用信息，并通過鏈表方式鏈接。Fiber 架構允許任務優先級調度，使得高優先級任務可以中斷低優先級任務，從而提升界面響應性。
問：React 調度器的“渲染階段（render）”和“提交階段（commit）”有何區別？
答：在 Fiber 架構中更新分為兩大階段：渲染（協調）階段和提交階段。渲染階段會生成新的 Fiber 樹，并找出需要更新的節點，這一過程可以被高優先級任務打斷和暫停。提交階段則一次性將渲染階段收集的所有變更應用到實際 DOM，這是一個不可中斷的過程。簡單來說，渲染階段是構建新 UI 的步驟，提交階段是落地更新的步驟。渲染階段還會觸發新舊狀態/屬性對比和生命周期（新 API）調用，而提交階段在更新 DOM 后調用 componentDidMount/componentDidUpdate 等效果鉤子。
問：簡述 React 調度器如何處理任務優先級？
答： React 調度器為不同類型的更新任務分配不同的優先級等級，比如同步、用戶阻塞、普通、閑置等（具體名稱和數量隨版本變化）。當有多個任務排隊時，React 調度器會先執行優先級高的任務（如用戶輸入），高優先級任務可能打斷正在進行的低優先級渲染任務。每個任務執行一小段后都會檢查是否有更高優先級任務需要處理，以決定是否繼續當前任務或暫緩。通過這種策略，React 能確保關鍵渲染（如及時響應用戶交互）優先完成，而不那么緊急的更新則延后執行，提高了應用響應速度。

中級問題

問：Fiber 樹中的 alternate 屬性有什么作用？
答：在 Fiber 架構中，每個組件實例在任意時刻最多有兩個 Fiber 對象：一個是當前渲染完成的 Fiber（current fiber），另一個是正在構建中的 Fiber（work-in-progress fiber）。這兩個 Fiber 互相通過 alternate 屬性指向對方。當一次更新開始時，React 會在已完成 Fiber 樹的基礎上克隆出一個工作 Fiber 樹（work-in-progress），所有狀態更新都寫在克隆的樹上。構建完成后，工作 Fiber 樹替換為當前 Fiber 樹。這種雙樹機制使得更新變得“可撤銷”：只有當整個工作 Fiber 樹準備就緒且無錯誤時才會提交。
問：React 調度器在低優先級任務時會怎樣處理？
答：對于低優先級任務，React 會盡可能拆分成更多的小任務并使用時間切片（Time Slicing）機制。它會檢查瀏覽器剩余可用時間，如果時間耗盡就暫停當前任務，等下一次機會再繼續。如果在拆分過程中出現了優先級更高的任務（例如用戶輸入事件），React 會立即暫停低優先級任務，轉去處理高優先級任務。這樣可以保證瀏覽器主線程不會被長時間占用，從而避免界面卡頓。
問：React 的批處理（batching）機制是如何實現的？
答： React 在事件處理和生命周期回調中默認啟用了狀態更新的批處理：多個 setState 調用會合并成一次更新以減少渲染。底層原理是 React 使用隊列來收集同一事件循環中的所有更新，待事件結束后再統一執行協調。對于用戶自定義的原生事件或異步調用（如 setTimeout），React 18 開始默認也會對多次更新進行批處理（通過 flushSync 手動繞過除外）。批處理通過調度器統一管理更新隊列，保證多次更新只觸發一次協調過程，提高性能并避免重復渲染。

高級問題

問：在源碼級別，React 更新時的工作循環函數主要有哪些？
答：在 React 源碼中，調度更新的核心流程涉及多個函數。簡要流程：React 啟動調度后調用 workLoopSync()（同步模式）或 workLoopConcurrent()（并發模式）。這會循環執行單元任務，每個任務由 performUnitOfWork() 處理，它內部會調用 beginWork() 來開始對當前 Fiber 的處理。beginWork 會根據 Fiber 類型生成子 Fiber，并返回下一個待處理的子 Fiber；performUnitOfWork 收尾后會調用 completeUnitOfWork()。循環直到 Fiber 樹遍歷完成，隨后進入提交階段。可見，關鍵函數有：createFiberFromTypeAndProps（創建 Fiber）、workLoopSync、performUnitOfWork、beginWork、completeWork 和 commitWork 等。
問：React Scheduler 中的時間切片是如何檢測何時暫停的？
答：在并發模式下，React Scheduler 會定期檢查剩余的瀏覽器時間。如果時間片用完，即超過閾值（如 5ms），它會讓出控制權給瀏覽器。源碼中，通過類似 shouldYieldToRenderer() 的檢查來決定是否暫停當前工作單元。若檢測到有更高優先級任務或時間不足，則 React 會暫停當前 Fiber 樹的構建，保存工作進度，稍后再恢復。這種策略確保 React 不會長時間占用主線程，維持頁面流暢。開發者在 startTransition 等并發特性中可配置超時時間（timeout），控制切換前最大等待時間。

并發模式（Concurrent Mode）與過渡（Transition）

初級問題

問：什么是 Concurrent Mode？React 18 中如何開啟？
答：并發模式是 React 18 引入的一系列實驗性渲染特性，總體目標是讓 React 可以更靈活地調度渲染任務，從而提供更流暢的用戶體驗。它允許 React 在執行更新時可中斷、可恢復，處理多個更新任務時給予高優先級更新先行機會。要啟用并發模式，需要使用 ReactDOM.createRoot 而非 ReactDOM.render 來創建根節點。例如：ReactDOM.createRoot(rootElement).render(<App />)。啟用后，React 會在新根上啟用并發能力，包括 startTransition 等特性。
問：React 18 中 startTransition 和 useTransition 有什么作用？
答：在并發模式下，React 提供了 startTransition 和 useTransition 用于標記過渡更新（transition）。這些工具使開發者能夠將某些更新標記為“非緊急”的過渡更新，React 會把它們放入低優先級隊列。舉例來說，當點擊切換頁面按鈕時，我們可以用 startTransition 包裹實際數據加載狀態的更新，以便在內容加載完成之前先保持舊界面不變。useTransition 返回 [startTransition, isPending]：startTransition(fn) 用于標記更新，isPending 表示過渡是否進行中。當使用了過渡更新，如果更新耗時超過了設置的超時時間（如 timeoutMs），React 會顯示 loading 指示，同時在后臺等待數據加載完畢再切換頁面。總體作用是讓頁面在執行大更新（如加載新頁面）時保持響應性，而不會直接閃現空白。
問：useDeferredValue 與 useTransition 的區別是什么？
答：兩者都是并發模式下的優化工具，但用途不同。useTransition 用于將整個狀態更新標記為過渡任務，即整個更新的優先級降低；而 useDeferredValue 用于“延遲”某個值，它會返回一個緩慢更新的版本。例如，當輸入框實時更新列表過濾時，可以用 useDeferredValue 返回過濾值的延遲版本，在該值變化時先顯示舊列表，等待新的過濾結果準備好再更新。通俗地說，useTransition 是標記更新任務，useDeferredValue 是標記某個值為延遲。兩者都依賴并發模式，但場景不同：前者常用于大規模界面更新（導航、數據加載），后者用于節流高頻更新的值。

中級問題

問：給出一個使用 useTransition 的示例，并解釋其作用。
答：示例：在并發模式下，點擊 “Next” 按鈕切換用戶 ID：
```
import React, { useState, useTransition } from 'react';function App() {const [resource, setResource] = useState(fetchProfileData(initialId));const [startTransition, isPending] = useTransition({ timeoutMs: 3000 });const handleClick = () => {startTransition(() => {const nextId = getNextId(resource.userId);setResource(fetchProfileData(nextId));});};return (<><button onClick={handleClick} disabled={isPending}>Next</button>{isPending && <p>Loading...</p>}<Profile resource={resource} /></>);
}
```
在這個例子中，我們將狀態更新包裹在 startTransition 中，這告訴 React 這是一個可以延遲的過渡更新。點擊 “Next” 時，如果新頁面需要較長時間加載（超過 3000ms），React 會先繼續顯示舊頁面并在一段時間后（超時后）自動切換到新頁面。isPending 用于指示過渡是否進行中，此時可以顯示加載指示符。這樣用戶不會看到短暫的空白頁，而是更流暢的過渡效果。
問：在并發模式下，React 如何處理數據獲取（Suspense）？
答：并發模式下，React 對數據獲取和異步操作提供了 Suspense 機制。組件可以使用 <Suspense> 包裹異步加載的部分，當內部發生數據加載（或組件惰性加載）時，React 會顯示回退 UI（fallback），而非整個頁面掛起。結合并發模式，React 可以同時渲染多個狀態下的 UI。例如，在頁面切換時，我們可以通過將包含數據獲取的組件放入 Suspense 中，實現當新數據未就緒時，先展示舊內容或 loading 指示，提升用戶體驗。React18 進一步提供了 startTransition 和 Suspense 的結合，使得復雜場景下界面切換更自然。簡單說，Suspense 讓數據獲取可暫停并顯示優雅的占位界面，而并發模式讓整個過程更可控。
問：如何讓 React Server Components 與并發模式一起工作？
答： React 服務器組件（RSC）與并發模式結合使用時，可以在服務器端預渲染部分組件并發送給客戶端，客戶端在并發模式中繼續渲染剩余組件。在使用并發模式的應用中，可以將部分無需客戶端交互的界面邏輯標記為服務器組件，它們會在構建或請求時在服務器執行（例如獲取數據、生成靜態內容）。客戶端接收到服務器組件輸出后，將其作為靜態內容合并到頁面中，其間可以使用 <Suspense> 等并發特性來處理異步加載的客戶端組件。具體實現依賴構建工具，但核心思想是“服務端完成它擅長的工作，將少量數據/渲染結果傳給瀏覽器，瀏覽器負責剩余的交互渲染”。

高級問題

問：并發模式和過渡機制的底層調度邏輯是怎樣的？
答：在并發模式下，React 調度器通過 Fiber 架構將更新任務分片，并維護多個優先級隊列。startTransition 將更新標記為低優先級任務。調度器在每次工作循環后檢查是否有更高優先級任務并中斷當前任務。對于過渡更新，React 會在后臺執行，并依據 timeoutMs 參數決定顯示加載指示的時機。具體來說，startTransition 內部會調用 setState，該更新被放入低優先級隊列；然后 React 調用渲染任務時，會允許其他高優先級事件先行。若超過超時閾值，還未完成過渡更新，React 會把過渡更新視為失敗，立即渲染 fallback UI，并繼續后續更新。完成后，新內容會自動取代舊內容。這樣底層調度結合時間切片、任務優先級和等待超時，確保過渡體驗順滑且響應迅速。
問：如何在并發模式下測試過渡和懸掛（Suspense）功能？
答：測試并發功能需要在測試環境啟用并發根容器。例如使用 React 測試庫可以調用 createRoot 而非 render 創建組件并掛載。對于 Suspense，可以模擬網絡延遲并斷言等待狀態和最終狀態。對于 useTransition，可以在測試中觸發 startTransition 包裹的更新，并通過 isPending 判斷過渡狀態。需要注意，由于并發行為和時間切片可能導致渲染順序非直觀，測試可能要使用 act() 等方法控制調度。官方文檔和社區示例中提供了并發模式下測試的指導（如等待下一個微任務或手動觸發時間片結束），這里不做贅述，但關鍵是把握好異步控制。

生命周期與新版生命周期函數對照

初級問題

問：React 類組件的生命周期有哪些階段？
答： React 類組件生命周期大致可分為掛載（Mount）、更新（Update）和卸載（Unmount）三個階段。掛載階段的常用方法包括 constructor、static getDerivedStateFromProps、render、componentDidMount。更新階段有 static getDerivedStateFromProps、shouldComponentUpdate、render、getSnapshotBeforeUpdate、componentDidUpdate。卸載階段對應方法是 componentWillUnmount。需要注意的是，React 16.3 之后引入了 getDerivedStateFromProps 和 getSnapshotBeforeUpdate，用來替代部分舊的生命周期方法（參見下文）。
問：React 中有哪些新的生命周期方法？舊方法為什么棄用？
答： React 16.3 之后，引入了兩個靜態生命周期方法：static getDerivedStateFromProps(props, state) 和 getSnapshotBeforeUpdate(prevProps, prevState)。前者在每次渲染前（掛載和更新時）被調用，用于根據新的 props 更新 state；后者在更新階段的 render 之后、DOM 提交之前執行，可用于讀取更新前的 DOM 狀態（如滾動位置）。原先的三個 “Will” 方法（componentWillMount、componentWillReceiveProps、componentWillUpdate）因為在并發模式和未來版本中會被多次調用而被棄用，被標記為 UNSAFE_ 前綴版本。React 官方建議盡量使用新的生命周期來避免潛在問題。
問：說明 componentDidMount 和 useEffect 的關系。
答： componentDidMount 是類組件在掛載完成后執行的鉤子，用于啟動數據請求、訂閱等副作用操作。等價地，在函數組件中用 useEffect（不帶依賴數組或依賴為空數組）即可模擬同樣的行為。例如，useEffect(() => { /* AJAX請求 */ }, []) 在組件首次渲染后執行，就相當于 componentDidMount。區別是函數組件的 Effect 可以在卸載時返回清理函數，而類組件需在 componentWillUnmount 中做清理。需要注意，useEffect 在開發模式下有時會被調用兩次（StrictMode），但只要編寫冪等的副作用函數即可。

中級問題

問：Vue 與 React 的生命周期有哪些異同？
答： 相似點： 兩者都提供在組件不同階段（創建、掛載、更新、銷毀）執行代碼的機會，都可以在組件掛載或更新完成后執行異步操作。
不同點： Vue 和 React 生命周期鉤子不完全相同。Vue 提供更多細致的階段，如 beforeCreate、created、beforeMount、mounted、beforeUpdate、updated、beforeDestroy、destroyed 等；而 React 主要有掛載、更新、卸載等階段，每階段以較少的方法覆蓋，且新版中使用靜態方法替代了部分舊鉤子。此外，Vue 的生命周期設計強調數據響應式與模板更新的配合，React 的生命周期更多與虛擬 DOM 協調過程和狀態驅動渲染相關。總體來說，Vue 的生命周期更傾向于響應式更新前后的細粒度控制，React 則側重于函數執行和 DOM 提交的過程。
問：React 16.3+ 之后哪些生命周期發生了變化？
答：在 React 16.3 及之后的版本中，以下變化比較重要：
- 舊的 componentWillReceiveProps 被 static getDerivedStateFromProps 替代，用于派發新的 props 到 state。
- 舊的 componentWillMount 和 componentWillUpdate 被 getSnapshotBeforeUpdate 部分替代，該方法用于在更新前從 DOM 獲取信息。舊的 componentWill* 方法被標記為 UNSAFE_，不推薦使用。
- React 新增了錯誤邊界的生命周期 getDerivedStateFromError 和 componentDidCatch（分別靜態和普通方法）來處理渲染錯誤。
  總之，新版生命周期強調“同步計算新狀態”和“讀取更新前快照”，去掉了可能被多次調用的舊鉤子，減少了副作用的不確定性。
問：比較 React 和 Vue 的組件通信方式。
答： React： 主流方式是通過 props 從父組件向子組件傳遞數據，以及通過回調函數（將函數作為 prop）讓子組件向父組件發送事件。另有 Context 提供跨層級組件共享數據的能力。Vue： 支持類似的 props 傳值機制，同時通過自定義事件（組件內使用 $emit 觸發，父組件通過 v-on 監聽）實現子到父的通信。此外，Vue 特有的 v-model 語法提供了雙向綁定支持。總體而言，兩者都強調單向數據流，但 Vue 對雙向綁定（如表單 v-model）有內置支持，而 React 中雙向需要手動管理。

高級問題

問：React 16.3+ 廢棄了哪些生命周期？為什么？
答： React 16.3+ 廢棄（標記為 UNSAFE）了以下生命周期：componentWillMount、componentWillReceiveProps、componentWillUpdate。廢棄原因是它們會在并發模式下可能被多次調用，容易導致副作用產生不確定的結果。React 官方將其替換為更安全的靜態方法：getDerivedStateFromProps 可替代 componentWillReceiveProps，getSnapshotBeforeUpdate 部分替代 componentWillUpdate。通過這兩個方法，React 保證了生命周期方法在執行時更可預測，并避免在渲染階段產生副作用。
問：React 生命周期函數中哪些可能被多次調用，為什么要避免在其中執行副作用？
答：在 Fiber 協調階段中，舊版生命周期（如 componentWillMount、componentWillUpdate、componentWillReceiveProps）在某些情形下可能被調用多次（例如在中斷后重新嘗試渲染時）。因此，React 文檔提示避免在這些方法里執行一次性副作用（如 AJAX 請求）。這也是 React 16.3+ 廢棄這些方法并引入安全替代的原因之一。在新的推薦方法（getDerivedStateFromProps 等）中，也不應放置副作用邏輯。組件掛載完成后應把副作用放在 componentDidMount 或 useEffect 中。
問：如何在 React 中實現類似 Vue beforeDestroy 的功能？
答：在類組件中，可以在 componentWillUnmount 生命周期中執行卸載前的清理邏輯（類似 Vue 的 beforeDestroy 和 destroyed）。在函數組件中，對應的鉤子是 useEffect 返回的清理函數：當組件卸載時，React 會執行該清理函數。例如：
```
useEffect(() => {// 副作用邏輯return () => {// 卸載時執行的清理邏輯};
}, []);
```
這樣可以在組件銷毀前清理定時器、取消訂閱等操作，與 Vue 的卸載鉤子作用相同。

綜合面試題（源碼層面）

問：當調用 setState 時，React 內部是如何調度更新的？
答：在類組件里，setState 會調用 enqueueSetState 將狀態更新包裹為 Update 對象插入更新隊列。然后通過調度函數 scheduleUpdateOnFiber 將包含該組件的 Fiber 標記為需要更新。調度函數確定更新優先級并安排渲染。隨后，React 將在合適時機遍歷 Fiber 樹，重新執行渲染（render）方法，構建新的 Fiber 樹。最后進入提交階段將變更應用到 DOM。以上過程包括函數調用棧 scheduleUpdateOnFiber -> performSyncWorkOnRoot -> workLoopSync -> performUnitOfWork 等，具體可以在 React 源碼中追蹤。
問：React 是如何保證函數組件 useState 的更新是基于上一次最新狀態的？
答：當使用函數式更新（setState(prev => newValue)）時，React 在更新時會讀取對應 Hook 的上一次狀態并傳給回調函數。例如，連續多次調用 setCount(c => c + 1) 時，React 會依次執行回調，每次 prev 都是上一次更新后的最新值。這是因為 Hooks 的更新隊列按順序處理，不斷將上一次的狀態傳給回調。在 Fiber 架構下，Hook 的狀態保存在 Fiber 的 memoizedState 鏈表中，每次更新都會取鏈表尾部最新的 state 傳給下一個更新。
問：解釋 React 中 key 的作用以及如何正確使用。
答： key 是 React 用于區分同層級元素的標識符，對列表渲染尤為重要。如果列表有唯一的 key，React 在 diff 時會將新舊節點按照 key 匹配，并復用不變的節點，從而只更新發生變化的部分。正確使用時，key 應該是能夠唯一標識元素且在變動中穩定的值（例如數據項的唯一 ID），不要使用數組索引作為 key（因為重新排序會導致所有元素的 key 發生變化）。這樣可以避免不必要的節點刪除與重建，保持組件狀態和內部 DOM 的穩定。
問：在服務端渲染（SSR）與客戶端渲染中，React 生命周期有何不同？
答：在 SSR（服務器渲染）時，React 只執行“掛載”過程的部分內容生成 HTML，但不會執行任何副作用生命周期，如 componentDidMount、useEffect 等，這些只會在客戶端掛載時執行。在服務器端執行的只是 renderToString 等方法生成 HTML 標記。換言之，服務器端渲染不會觸發真實 DOM 操作相關的生命周期，開發者應避免在掛載時直接訪問 document 或做客戶端-only 的初始化。在客戶端重新掛載（hydrate）后，才會觸發正常的掛載后鉤子。

擴展專題

問：簡述 React Hooks 的底層原理（例如 useState）。
答： React Hooks 通過在函數組件對應的 Fiber 節點上構建一個 Hook 鏈表來管理狀態。每次渲染，React 會沿著 Fiber 的 memoizedState 鏈表“消費”每個 useState、useEffect 等 Hook，維護一個單向鏈表保存所有 Hook 對象。useState 返回的 setState 函數實際上會將更新加入當前 Hook 的更新隊列，并通過調度觸發 Fiber 更新。Fiber 在執行時，會遍歷這些 Hook 并更新狀態值。由于 Hook 的調用順序必須固定，React 才能正確匹配更新后的狀態值與相應的 Hook。在源碼層面，Hooks 依賴于內部的調度器（Dispatcher）機制和 Fiber 上保存的 memoizedState 指針，確保每次渲染時狀態的一致性。
問：什么是 React Server Components（RSC）？其工作原理是怎樣的？
答： React 服務器組件是一種新型組件概念，允許在服務器端渲染組件并將結果發送給客戶端。服務器組件在構建時或請求時在服務器環境中執行，可以執行 I/O 操作（讀取文件、請求數據庫等），并將生成的內容作為序列化數據（例如 JSON 或 HTML）傳遞給客戶端。客戶端接收到服務器組件輸出后，會將其結果（及必要的組件元數據）作為道具傳遞給客戶端組件，繼續完成界面的渲染。通過將數據獲取和靜態渲染責任放在服務器，可以減少客戶端需要下載和執行的 JavaScript 代碼量，提高性能。簡言之，服務器組件讓服務器先做好部分渲染工作，然后客戶端接管剩余工作。
問：Redux 和 Recoil 有何區別？各自的設計理念是什么？
答： Redux 和 Recoil 都是狀態管理庫，但設計理念不同。Redux 采用單向數據流，將所有應用狀態集中在一個全局 Store 中，通過 dispatch Actions 和 Reducers 進行管理。它強調不可變狀態和顯式的更新流程，并且依賴中間件（如 thunk、saga）處理異步邏輯。Recoil 則借鑒了 React Hooks 思想，使用“原子”（atom）作為最小狀態單元，每個 atom 代表一個可獨立訂閱的數據片段。組件可以在任意位置訂閱原子，狀態更局部化。Recoil 內置了響應式機制（selector）可以自動追蹤依賴。簡而言之，Redux 適合大型應用的集中式狀態管理和嚴格數據流控制，Recoil 則更貼合 React，支持局部狀態和自動優化更新。
問：比較 React Context 與 Redux，什么時候使用哪種方案？
答： React Context 主要用于通過組件樹傳遞少量全局數據（如主題、國際化設置等），它提供了類似 “全局變量” 的功能，但并非專門為狀態管理設計。Context 更新會導致所有訂閱該 Context 的組件重新渲染，適用于全局少量狀態。Redux 則是一套完整的狀態管理方案，適合復雜應用。它提供了集中化的 Store、可追蹤的更新日志（DevTools）、中間件、嚴格的更新流程等。通常，當需要管理的狀態量較大、需要多人協作或需要更精細的調試與優化時，選擇 Redux；若只需簡單地在應用不同層級共享少量狀態，Context 就足夠了。總之，Context 更輕量而專注于跨層傳遞，而 Redux 更擅長復雜場景的狀態管理。

React 與 Vue 對比專題

問：React 和 Vue 在響應式原理上有哪些差異？
答：雖然兩者都采用虛擬 DOM 來優化渲染，但它們的數據響應機制不同。React 的核心是單向數據流：組件通過 props 接收數據，狀態更新后手動調用 setState/Hooks 來重新渲染組件。React 本身不自動跟蹤依賴，開發者需要明確設置 state。Vue 則采用雙向數據綁定和響應式系統：Vue 2 用 Object.defineProperty，Vue 3 用 Proxy 監聽數據變化，當數據改變時自動通知相關組件更新。因此，Vue 的模板數據和視圖綁定非常緊密，而 React 更強調由開發者顯式控制更新。
問：React 和 Vue 的生命周期鉤子有哪些不同？
答： Vue 的生命周期鉤子更為細致，從實例創建到銷毀有多個階段：如 beforeCreate/created（實例創建）、beforeMount/mounted（掛載）、beforeUpdate/updated（更新）、beforeDestroy/destroyed（卸載）等。React 的類組件生命周期相對簡潔：主要是掛載（constructor、componentDidMount）、更新（shouldComponentUpdate、componentDidUpdate）和卸載（componentWillUnmount）三個階段，并輔以靜態方法 getDerivedStateFromProps 和 getSnapshotBeforeUpdate。Vue 的鉤子與數據響應緊密結合，可直接訪問實例上下文，React 的鉤子則與虛擬 DOM 協調過程結合更多。總體上，Vue 提供了更多粒度的鉤子，React 的鉤子設計更關注性能和可控性。
問：比較 React 和 Vue 的組件通信機制。
答：在組件通信上，兩者有相似點也有差異。相似點： 都支持通過 props 自頂向下傳遞數據，通過事件或回調自下而上傳遞消息。
不同點： Vue 內置了更直觀的通信方式，如 $emit 觸發自定義事件，以及 v-model 雙向綁定簡化父子組件數據同步。Vue 還可以通過 $refs 或全局事件總線等方式通信。React 社區常用的方式是：父組件將處理函數通過 props 傳給子組件，子組件通過調用該函數傳遞數據；也可使用 Context、Redux 等管理跨層數據。Vue 的事件系統在模板層面上更便捷，而 React 更依賴代碼層面的模式（prop drilling 或 Context）。
問：在性能優化方面，React 和 Vue 有何不同的策略？
答： Vue： 對模板中的響應式數據和計算屬性做自動依賴跟蹤，只更新變化的部分，具有自動優化特性。然而當數據量非常大或組件嵌套深時，仍可能需要手動優化（如使用 v-once、v-for 加 key、keep-alive 等）。
React： 默認更新粒度較粗（整個組件重新運行函數/render），需要開發者手動優化。常用策略有：shouldComponentUpdate、PureComponent、memo 等控制不必要渲染；useMemo、useCallback 緩存數據和函數；列表渲染時合理使用 key。React 更強調“只渲染需要變更的組件”，但依賴開發者正確使用這些優化手段。
總體而言，Vue 傾向于自動化優化而 React 傾向于提供工具給開發者主動優化。選擇框架時應根據團隊熟悉度和項目需求綜合考慮兩者在性能優化方面的特點。
問：React 的單向數據流與 Vue 的雙向綁定有何優缺點？
答： React 的單向數據流（props down, callbacks up）使得數據流動清晰可追蹤，容易調試和理解數據來源，有助于構建可預測的應用。缺點是對于表單等場景較多的手動同步代碼。Vue 的雙向綁定（尤其是 v-model）減少了開發者手動管理數據同步的工作量，簡化表單和輸入型組件的實現。但這也可能導致邏輯不夠直觀，某些情況下難以追蹤數據流向。簡而言之，單向數據流更加顯式和可控，雙向綁定開發方便但可維護性略差，團隊應根據項目規模和復雜度選用合適的模式。