diff --git a/apps/mobile/app/(tabs)/index.tsx b/apps/mobile/app/(tabs)/index.tsx
index cafc6fd..cc9c99c 100644
--- a/apps/mobile/app/(tabs)/index.tsx
+++ b/apps/mobile/app/(tabs)/index.tsx
@@ -8,7 +8,7 @@ import { useProgress } from '@/context/ProgressContext';
 import Home from '@/screens/Home';
 import ChapterMap from '@/screens/ChapterMap';
 import Quiz from '@/screens/Quiz';
-import { chapters, getLevel, MIXED_SIZE, sampleQuestions, shuffle, type Question } from '@easylearn/core';
+import { chapters, getLevel, LEVEL_SIZE, MIXED_SIZE, sampleFixedQuestions, type Question } from '@easylearn/core';
 
 type ViewState =
   | { name: 'home' }
@@ -36,12 +36,12 @@ export default function HomeScreen() {
   const startLevel = (levelId: string) => {
     const level = getLevel(levelId);
     if (!level) return;
-    setView({ name: 'quiz', levelId, questions: sampleQuestions(level.questions) });
+    setView({ name: 'quiz', levelId, questions: sampleFixedQuestions(level.questions, LEVEL_SIZE) });
   };
 
   const startMixedPractice = () => {
     const pool = chapters.flatMap((ch) => ch.levels.flatMap((l) => l.questions));
-    const picked = shuffle(pool).slice(0, MIXED_SIZE).sort((a, b) => a.difficulty - b.difficulty);
+    const picked = sampleFixedQuestions(pool, MIXED_SIZE);
     setView({ name: 'mixed', questions: picked });
   };
 
diff --git a/apps/mobile/app/(tabs)/notes.tsx b/apps/mobile/app/(tabs)/notes.tsx
index d66eda6..c35a571 100644
--- a/apps/mobile/app/(tabs)/notes.tsx
+++ b/apps/mobile/app/(tabs)/notes.tsx
@@ -13,8 +13,8 @@ import {
   getWrongEntries,
   getWrongQuestions,
   REVIEW_SIZE,
+  sampleFixedQuestions,
   sampleQuestions,
-  shuffle,
   type Question,
 } from '@easylearn/core';
 
@@ -41,7 +41,7 @@ export default function NotesScreen() {
   }
 
   const startReview = () => {
-    const picked = shuffle(getWrongQuestions(progress.wrongIds)).slice(0, REVIEW_SIZE);
+    const picked = sampleFixedQuestions(getWrongQuestions(progress.wrongIds), REVIEW_SIZE);
     if (picked.length === 0) return;
     setView({ name: 'review', questions: picked });
   };
diff --git a/apps/mobile/screens/ChapterMap.tsx b/apps/mobile/screens/ChapterMap.tsx
index 2e473f7..23bdcda 100644
--- a/apps/mobile/screens/ChapterMap.tsx
+++ b/apps/mobile/screens/ChapterMap.tsx
@@ -3,12 +3,11 @@ import { Pressable, ScrollView, StyleSheet, View } from 'react-native';
 import { Text } from '@/components/Themed';
 import Icon from '@/components/Icon';
 import { colors, fonts } from '@/constants/theme';
-import { chapters, type IconName, type Progress } from '@easylearn/core';
+import { chapters, LEVEL_SIZE, type Progress } from '@easylearn/core';
 
-type StatusIcon = 'lock' | 'check-circle' | 'play';
+type StatusIcon = 'check-circle' | 'play';
 
 const STATUS_COLOR: Record<StatusIcon, string> = {
-  lock: colors.locked,
   'check-circle': colors.cyan,
   play: colors.primary,
 };
@@ -37,15 +36,12 @@ export default function ChapterMap({ chapterId, progress, onStartLevel, onBack }
 
       {chapter.levels.map((level, i) => {
         const record = progress.completedLevels[level.id];
-        const prevDone = i === 0 || progress.completedLevels[chapter.levels[i - 1].id];
-        const locked = !prevDone;
-        const statusIcon: StatusIcon = locked ? 'lock' : record ? 'check-circle' : 'play';
+        const statusIcon: StatusIcon = record ? 'check-circle' : 'play';
         return (
           <Pressable
             key={level.id}
-            disabled={locked}
             onPress={() => onStartLevel(level.id)}
-            style={[styles.levelRow, locked && styles.levelLocked]}
+            style={styles.levelRow}
           >
             <View style={styles.levelIcon}>
               <Icon name={statusIcon} size={20} color={STATUS_COLOR[statusIcon]} />
@@ -56,9 +52,7 @@ export default function ChapterMap({ chapterId, progress, onStartLevel, onBack }
             <Text style={styles.levelRecord}>
               {record
                 ? `最佳 ${record.best}/${record.total}`
-                : locked
-                  ? '完成上一關解鎖'
-                  : `共 ${level.questions.length} 題`}
+                : `共 ${Math.min(LEVEL_SIZE, level.questions.length)} 題`}
             </Text>
           </Pressable>
         );
@@ -104,9 +98,6 @@ const styles = StyleSheet.create({
     paddingVertical: 16,
     paddingHorizontal: 18,
   },
-  levelLocked: {
-    opacity: 0.55,
-  },
   levelIcon: {
     width: 28,
     height: 28,
diff --git a/apps/web/src/App.tsx b/apps/web/src/App.tsx
index 8c5a46f..1c61df1 100644
--- a/apps/web/src/App.tsx
+++ b/apps/web/src/App.tsx
@@ -6,10 +6,11 @@ import {
   getWrongEntries,
   getSavedQuestions,
   chapters,
-  shuffle,
   sampleQuestions,
+  sampleFixedQuestions,
   REVIEW_SIZE,
   MIXED_SIZE,
+  LEVEL_SIZE,
 } from '@easylearn/core'
 import Navbar from '@/components/Navbar'
 import Home from '@/screens/Home'
@@ -51,21 +52,21 @@ const App = () => {
   const [view, setView] = useState<View>({ name: 'home' })
 
   const startLevel = (levelId: string) => {
-    // 整個題池隨機排序作答（同難度內順序每次不同）
+    // 固定抽 LEVEL_SIZE 題作答，題池不足就整包抽完（同難度內順序每次不同）
     const level = getLevel(levelId)
     if (!level) return
-    setView({ name: 'quiz', levelId, questions: sampleQuestions(level.questions) })
+    setView({ name: 'quiz', levelId, questions: sampleFixedQuestions(level.questions, LEVEL_SIZE) })
   }
 
   const startReview = () => {
-    const picked = shuffle(getWrongQuestions(progress.wrongIds)).slice(0, REVIEW_SIZE)
+    const picked = sampleFixedQuestions(getWrongQuestions(progress.wrongIds), REVIEW_SIZE)
     if (picked.length === 0) return
     setView({ name: 'review', questions: picked })
   }
 
   const startMixedPractice = () => {
     const pool = chapters.flatMap((ch) => ch.levels.flatMap((l) => l.questions))
-    const picked = shuffle(pool).slice(0, MIXED_SIZE).sort((a, b) => a.difficulty - b.difficulty)
+    const picked = sampleFixedQuestions(pool, MIXED_SIZE)
     setView({ name: 'mixed', questions: picked })
   }
 
diff --git a/apps/web/src/screens/ChapterMap.tsx b/apps/web/src/screens/ChapterMap.tsx
index 467aeef..1baef15 100644
--- a/apps/web/src/screens/ChapterMap.tsx
+++ b/apps/web/src/screens/ChapterMap.tsx
@@ -1,5 +1,5 @@
 import Icon from '@/components/Icons'
-import { chapters, type IconName, type Progress } from '@easylearn/core'
+import { chapters, LEVEL_SIZE, type IconName, type Progress } from '@easylearn/core'
 
 interface ChapterMapProps {
   chapterId: string | null
@@ -25,14 +25,11 @@ const ChapterMap = ({ chapterId, progress, onStartLevel, onBack }: ChapterMapPro
 
       {chapter.levels.map((level, i) => {
         const record = progress.completedLevels[level.id]
-        const prevDone = i === 0 || progress.completedLevels[chapter.levels[i - 1].id]
-        const locked = !prevDone
-        const statusIcon: IconName = locked ? 'lock' : record ? 'check-circle' : 'play'
+        const statusIcon: IconName = record ? 'check-circle' : 'play'
         return (
           <button
             key={level.id}
-            className={`level-row ${locked ? 'level-locked' : ''} ${record ? 'level-done' : ''}`}
-            disabled={locked}
+            className={`level-row ${record ? 'level-done' : ''}`}
             onClick={() => onStartLevel(level.id)}
           >
             <span className={`level-icon status-${statusIcon}`}>
@@ -44,9 +41,7 @@ const ChapterMap = ({ chapterId, progress, onStartLevel, onBack }: ChapterMapPro
             <span className="level-record">
               {record
                 ? `最佳 ${record.best}/${record.total}`
-                : locked
-                  ? '完成上一關解鎖'
-                  : `共 ${level.questions.length} 題`}
+                : `共 ${Math.min(LEVEL_SIZE, level.questions.length)} 題`}
             </span>
           </button>
         )
diff --git a/packages/core/src/data/chapters.ts b/packages/core/src/data/chapters.ts
index b10fce9..f5b1510 100644
--- a/packages/core/src/data/chapters.ts
+++ b/packages/core/src/data/chapters.ts
@@ -47,6 +47,36 @@ import fp16 from './questions/fp-16-sharing-resources.json'
 import fp17 from './questions/fp-17-coordinating-timelines.json'
 import fp18 from './questions/fp-18-reactive-onion.json'
 import fp19 from './questions/fp-19-road-ahead.json'
+import ri1 from './questions/ri-1-router.json'
+import ri2 from './questions/ri-2-i18n.json'
+import ri3 from './questions/ri-3-testing.json'
+import ri4 from './questions/ri-4-redux.json'
+import ri5 from './questions/ri-5-native.json'
+import ri6 from './questions/ri-6-ecosystem.json'
+import ri7 from './questions/ri-7-misc.json'
+import ri8 from './questions/ri-8-modern.json'
+import ri9 from './questions/ri-9-core-basics.json'
+import ri10 from './questions/ri-10-core-props-events.json'
+import ri11 from './questions/ri-11-core-vdom.json'
+import ri12 from './questions/ri-12-core-hoc-composition.json'
+import ri13 from './questions/ri-13-core-ecosystem-position.json'
+import ri14 from './questions/ri-14-core-rendering-patterns.json'
+import ri15 from './questions/ri-15-core-jsx-details.json'
+import ri16 from './questions/ri-16-core-styling-tools.json'
+import ri17 from './questions/ri-17-core-project-conventions.json'
+import ri18 from './questions/ri-18-misc-early.json'
+import ri19 from './questions/ri-19-misc-hooks-foundations.json'
+import ri20 from './questions/ri-20-misc-rendering-internals.json'
+import ri21 from './questions/ri-21-misc-reducer-context-deep.json'
+import ri22 from './questions/ri-22-misc-useeffect-deep.json'
+import ri23 from './questions/ri-23-misc-layouteffect-ref-imperative.json'
+import ri24 from './questions/ri-24-misc-memo-callback-custom-hooks.json'
+import ri25 from './questions/ri-25-misc-advanced-hooks.json'
+import ri26 from './questions/ri-26-misc-code-splitting-perf.json'
+import ri27 from './questions/ri-27-misc-error-boundaries.json'
+import ri28 from './questions/ri-28-misc-component-conventions.json'
+import ri29 from './questions/ri-29-misc-forms-composition.json'
+import ri30 from './questions/ri-30-misc-state-alternatives-internals.json'
 import type { Chapter, Level, Question, WrongEntry, WrongEntryMeta } from '../types'
 
 // 題目 JSON 的 type 欄位在匯入時只會被推斷成 string，用 as 收斂回字面量聯合型別
@@ -82,6 +112,16 @@ export const chapters: Chapter[] = [
       fp11, fp12, fp13, fp14, fp15, fp16, fp17, fp18, fp19,
     ].map(asLevel),
   },
+  {
+    id: 'react-interview',
+    title: 'React 面試題',
+    icon: 'lightbulb',
+    levels: [
+      ri9, ri10, ri11, ri12, ri13, ri14, ri15, ri16, ri17,
+      ri1, ri2, ri3, ri4, ri5, ri6, ri7, ri8,
+      ri18, ri19, ri20, ri21, ri22, ri23, ri24, ri25, ri26, ri27, ri28, ri29, ri30,
+    ].map(asLevel),
+  },
 ]
 
 // 抽象屏障：所有跟「題目 × 所屬章節」相關的查詢都透過這份攤平清單計算，
diff --git a/packages/core/src/data/questions/fp-1-welcome.json b/packages/core/src/data/questions/fp-1-welcome.json
index 468bcfb..9d973e2 100644
--- a/packages/core/src/data/questions/fp-1-welcome.json
+++ b/packages/core/src/data/questions/fp-1-welcome.json
@@ -58,6 +58,63 @@
       "answer": "a",
       "explanation": "「相同輸入永遠得到相同輸出」是純函式最基本的判準——不管什麼時候呼叫、呼叫幾次，只要參數相同，結果就該相同。B、C、D 描述的都是依賴外部狀態或時機的 Action 行為，不是純函式。",
       "verify": { "manual": "概念題：以具體呼叫情境取代抽象特性列舉，無可執行程式碼。" }
+    },
+    {
+      "id": "fp-1-q4",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "純函式讓測試不需要 mock 任何東西",
+      "docs": "",
+      "story": "",
+      "prompt": "幫 calcTax(price) 寫測試，跟幫另一個會發送推播通知的函式 notifyMember(userId) 寫測試比起來，最大的差異是什麼？",
+      "code": "function calcTax(price) { return price * 1.05; }\nfunction notifyMember(userId) {\n  sendPushNotification(userId, \"...\");\n  saveNotifyLog(userId);\n}",
+      "options": [
+        { "id": "a", "text": "兩者測試起來難度差不多，只要換一套合適的 mock 工具，notifyMember 也能像 calcTax 一樣直接斷言結果，副作用不會增加多少額外工作" },
+        { "id": "b", "text": "notifyMember 反而比較好測試，因為它牽涉的動作比較多，測試案例寫起來自然比較完整、比較看得出程式邏輯" },
+        { "id": "c", "text": "測試 calcTax 只需要呼叫它、斷言回傳值即可；測試 notifyMember 得先 mock 掉推播服務、假造資料庫紀錄，才能在不真的推播、不真的寫資料庫的前提下驗證邏輯——這正是純函式帶來的測試便利性" },
+        { "id": "d", "text": "只有 calcTax 能被單元測試，notifyMember 依賴外部服務，技術上完全沒辦法寫出任何測試" }
+      ],
+      "answer": "c",
+      "explanation": "純函式的測試只需要「給輸入、斷言輸出」；牽涉副作用的函式（如 notifyMember），測試前得先隔離、模擬它依賴的外部世界，這份額外的準備工作量正是副作用帶來的代價，如選項 c 所述。",
+      "verify": { "manual": "概念題：以測試撰寫難度的具體對比取代抽象敘述，無可執行程式碼。" }
+    },
+    {
+      "id": "fp-1-q5",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "相同輸入不同輸出，代表問題通常不在這個函式本身",
+      "docs": "",
+      "story": "",
+      "prompt": "使用者回報「同樣按下結帳按鈕，有時候算出來的金額不一樣」。如果 calcTotal(cart) 嚴格遵守「相同輸入永遠同樣輸出」這個純函式規則，這個 bug 有沒有可能出在 calcTotal 內部？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "很有可能，純函式一樣會受到執行當下的系統時間、網路延遲、使用者時區等外部環境影響，就算輸入的 cart 完全相同也可能算出不同的金額" },
+        { "id": "b", "text": "不太可能：如果 calcTotal 真的是純函式，同樣的 cart 輸入必然算出同樣結果，「金額不一樣」代表兩次傳入的 cart 內容本身就不同；問題應該往 cart 是怎麼組出來的方向查，而不是懷疑 calcTotal 本身" },
+        { "id": "c", "text": "無法判斷，因為金額算得一不一致跟這個函式到底是不是純函式完全沒有關係，純不純只影響程式碼好不好維護、好不好測試" },
+        { "id": "d", "text": "一定是 calcTotal 內部偷用了亂數產生器或讀取了目前系統時間，這是唯一可能造成金額浮動的原因，不用再往其他地方查" }
+      ],
+      "answer": "b",
+      "explanation": "純函式的「相同輸入同樣輸出」保證，反過來也是一個很好用的除錯線索（如選項 b）：確認一個函式真的是純函式之後，看到「同樣操作、不同結果」就能直接排除它，把注意力放回輸入資料本身是怎麼變出來的。",
+      "verify": { "manual": "概念題：以除錯情境取代抽象特性說明，無可執行程式碼。" }
+    },
+    {
+      "id": "fp-1-q6",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "FP 降低心智負擔：只看輸入輸出，不用追蹤全部呼叫路徑",
+      "docs": "",
+      "story": "",
+      "prompt": "除錯一個純函式 calcDiscount(price, rate)，跟除錯一個到處讀寫全域變數的函式，何者需要在腦中同時記住的東西比較少？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "讀寫全域變數的函式比較好除錯，因為隨時能看到目前的全域狀態，不像純函式那樣得另外準備輸入值才能觀察行為" },
+        { "id": "b", "text": "兩者需要在腦中記住的東西一樣多，跟這個函式純不純完全無關，差別只在於個人除錯習慣好不好" },
+        { "id": "c", "text": "純函式反而更難除錯，因為看不到任何中間狀態，得靠額外的 log 才能知道內部發生了什麼事" },
+        { "id": "d", "text": "純函式：結果只取決於傳進來的參數，除錯時只需要盯著這幾個輸入值和函式邏輯，不必在腦中追蹤「全域變數在其他地方分別被誰改過、現在值到底是多少」——這正是 FP 想降低的心智負擔" }
+      ],
+      "answer": "d",
+      "explanation": "全域狀態的問題在於「任何地方都可能是兇手」，除錯時得在腦中同時追蹤一大堆分散的修改點；純函式把所有相關資訊都收斂到參數列表裡，除錯時只需要盯著眼前這一小段，如選項 d 所述，這是 FP 對「人類工作記憶有限」這個現實的務實回應。",
+      "verify": { "manual": "概念題：以除錯所需心智負擔的具體對比取代抽象敘述，無可執行程式碼。" }
     }
   ]
 }
diff --git a/packages/core/src/data/questions/fp-19-road-ahead.json b/packages/core/src/data/questions/fp-19-road-ahead.json
index b0619a9..4768024 100644
--- a/packages/core/src/data/questions/fp-19-road-ahead.json
+++ b/packages/core/src/data/questions/fp-19-road-ahead.json
@@ -58,6 +58,63 @@
       "answer": "a",
       "explanation": "這三個情境分別對應三個具體的重構技巧：從 Action 萃取 Calculation、用顯性參數合併重複函式、用並行原語處理不確定的執行順序——這是把學到的技巧收斂回真實專案的練習；CSS 打包、資料庫選型、變數改名這類工程雜務，跟這裡談的副作用／時序控制技巧無關。",
       "verify": { "manual": "概念題：情境分析，無可執行程式碼。" }
+    },
+    {
+      "id": "fp-19-q4",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "從「修改既有程式碼」到「設計全新系統」的轉變",
+      "docs": "",
+      "story": "",
+      "prompt": "書的前半段（萃取 Calculation、分層設計）主要是在「改善既有的、已經寫壞的程式碼」；後半段談的 reactive architecture、onion architecture 這類主題，跟前半段是什麼關係？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "後半段的內容跟前半段完全無關，其實是出版社為了增加頁數，硬把兩本探討不同主題的書拼湊成一冊，讀者其實可以只挑其中一半閱讀，不影響理解" },
+        { "id": "b", "text": "從「重構現有程式碼」轉向「設計全新系統架構」：前半段處理「已經寫壞的程式碼怎麼改善」，後半段的 reactive／onion architecture 處理「從零設計系統時 Actions、Calculations、Data 怎麼安排」——同一套概念用在不同情境" },
+        { "id": "c", "text": "後半段只是把前半段談過的內容換一套名詞重新講一遍，本質上是同樣的東西包裝成看起來比較新的樣子，沒有任何真正新增的概念" },
+        { "id": "d", "text": "前半段講的是可以直接落地套用的具體技巧，後半段講的架構思維說穿了只是空談理論，實務上完全沒辦法應用在真實的商業專案裡" }
+      ],
+      "answer": "b",
+      "explanation": "書的編排本身就有一條「先學會怎麼補救、再學會怎麼預防」的脈絡：前半段的重構技巧針對已經存在的混亂，後半段的架構思維（如選項 b）則是把同一套 Actions/Calculations/Data 的分類原則，提前用在系統設計階段，讓混亂從一開始就少發生。",
+      "verify": { "manual": "概念題：以書籍前後段落內容關係取代單純章節條列，無可執行程式碼。" }
+    },
+    {
+      "id": "fp-19-q5",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "過度抽象的風險：不是每段程式碼都值得硬套技巧",
+      "docs": "",
+      "story": "",
+      "prompt": "一個只會被呼叫一次、邏輯簡單到一眼就能看懂的小函式，有人堅持照書裡的技巧硬是把它拆成三層（萃取 Calculation、再用高階函式合併、再包一層防禦性拷貝）。這樣做恰當嗎？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "恰當，書裡教的每一種技巧本來就該無條件套用在所有程式碼上，不管有沒有實際痛點，套用得越多，程式碼品質自然越高越好" },
+        { "id": "b", "text": "恰當，因為拆成越多層、程式碼的行數自然增加，行數越多就代表被重構得越徹底，品質也就跟著越高" },
+        { "id": "c", "text": "不恰當，但唯一的原因是這樣拆三層會拖慢執行速度、讓效能變差，跟程式碼好不好讀完全無關" },
+        { "id": "d", "text": "不恰當：這些技巧只該用在真的因為副作用混雜、時序不確定而難以理解或測試的程式碼上；對簡單清楚、沒有痛點的程式碼硬套三層，只會增加不必要的間接層次，違背技巧原本要解決的問題" }
+      ],
+      "answer": "d",
+      "explanation": "所有重構技巧都該對應一個真實存在的痛點，套用技巧本身不是目的。對沒有痛點的程式碼強行套用，只會增加讀者需要在腦中追蹤的間接層次，如選項 d 所述，這跟這些技巧「讓程式碼更容易推理」的初衷背道而馳。",
+      "verify": { "manual": "概念題：以過度抽象的具體情境取代抽象原則說明，無可執行程式碼。" }
+    },
+    {
+      "id": "fp-19-q6",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "全書技巧的共同主軸：把影響範圍限縮到人腦能推理的大小",
+      "docs": "",
+      "story": "",
+      "prompt": "回顧全書談過的技巧——區分 Actions/Calculations/Data、萃取計算、分層設計、defensive copying、時間線圖、reactive architecture——這些技巧最終共同想達成的效果，最貼切的說法是什麼？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "這些技巧的共同目標只是讓程式碼的檔案數量變多、看起來比較有規模，跟好不好理解沒有直接關係" },
+        { "id": "b", "text": "這些技巧的目的只是為了符合函數式程式設計語言本身的語法規範，跟程式碼好不好理解完全無關" },
+        { "id": "c", "text": "把程式碼的影響範圍、什麼時候會被誰改動，限縮到人腦可以一次掌握、可以推理清楚的範圍內——不管是限縮副作用擴散、巢狀資料共享風險、還是時間線的不確定性，核心都是讓開發者不用追蹤整個系統，就能對一小段程式碼有信心" },
+        { "id": "d", "text": "這些技巧彼此完全獨立，沒有任何共同的核心精神，純粹是作者把不同章節的零散技巧硬湊在一起而已" }
+      ],
+      "answer": "c",
+      "explanation": "全書每一項技巧表面上處理的問題不同（副作用、抽象層級、資料共享、執行順序），但共同的深層目標一致，如選項 c 所述：把「需要同時放在腦中才能理解這段程式碼」的範圍縮小，讓程式碼在局部就能被完整推理，不用理解整個系統才能安心修改一小塊。",
+      "verify": { "manual": "概念題：全書技巧收斂的總結性推理，無可執行程式碼。" }
     }
   ]
 }
diff --git a/packages/core/src/data/questions/fp-2-overview.json b/packages/core/src/data/questions/fp-2-overview.json
index 6f471df..f653da8 100644
--- a/packages/core/src/data/questions/fp-2-overview.json
+++ b/packages/core/src/data/questions/fp-2-overview.json
@@ -58,6 +58,63 @@
       "answer": "a",
       "explanation": "「順序不定造成的錯誤」正是時間線圖存在的意義——型別檢查、縮排格式都抓不到「兩條時間線交錯讀寫同一份資料」這種問題，只有把執行順序畫出來才能看清楚。",
       "verify": { "manual": "概念題：以具體雙擊 bug 情境取代對工具定義的直接背誦，無可執行程式碼。" }
+    },
+    {
+      "id": "fp-2-q4",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "程式碼重複但邏輯幾乎一樣：適合用高階函式消除重複",
+      "docs": "",
+      "story": "",
+      "prompt": "專案裡有 sumPrices(items)、maxPrice(items)、countExpensive(items) 三個函式，程式碼幾乎一模一樣，只有迴圈裡「怎麼處理每個元素」不同。這種重複，書裡建議用什麼技巧解決？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "把三個函式的程式碼各自複製貼上、獨立維護，不做任何抽象整併，避免共用邏輯出錯時互相牽連" },
+        { "id": "b", "text": "改用時間線圖分析，因為這三個函式的重複問題出在執行順序不一致，不是走訪邏輯本身重複" },
+        { "id": "c", "text": "改用 defensive copying，因為這三個函式重複的根本原因是資料在傳遞過程中被意外修改" },
+        { "id": "d", "text": "把「怎麼處理每個元素」變成一個參數（傳入一個函式），用高階函式（如 reduce、map、filter）抽出共同的走訪邏輯，各自只保留真正不同的那一小段" }
+      ],
+      "answer": "d",
+      "explanation": "三個函式的共同點是「走訪陣列」，差異點是「拿每個元素做什麼」；高階函式（如選項 d）把差異點抽成參數（一個函式），共同點留在通用的走訪邏輯裡，這是消除這類重複最直接的手法。",
+      "verify": { "manual": "概念題：以具體重複函式情境取代對章節工具清單的直接背誦，無可執行程式碼。" }
+    },
+    {
+      "id": "fp-2-q5",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "多個非同步請求需要彼此協調：適合用時間線圖與並行原語",
+      "docs": "",
+      "story": "",
+      "prompt": "頁面需要同時打三個 API（使用者資料、訂單紀錄、優惠券），只有三個都回來之後才能顯示畫面，中途某一個先回來也不能提早顯示不完整的畫面。這種「協調多條時間線」的需求，屬於書裡哪一類技巧涵蓋的問題？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "屬於萃取 Calculation 要解決的問題，因為三支 API 呼叫本質上都是把外部資料轉換成畫面需要的格式" },
+        { "id": "b", "text": "屬於時間線圖與並行原語（如「等多個非同步操作一起完成」這類原語）要解決的問題——這是「多條時間線需要協調」的情境，跟單純的「一步接一步」計算完全不同類型" },
+        { "id": "c", "text": "屬於分層設計要解決的問題，因為這裡同時牽涉到三個不同的 API，屬於抽象層級混雜的情況" },
+        { "id": "d", "text": "這不屬於書裡任何技巧涵蓋的範圍，多個非同步請求的協調只能土法煉鋼手動處理，沒有系統化解法" }
+      ],
+      "answer": "b",
+      "explanation": "「多條時間線該怎麼互相等待、協調」是時間線圖與並行原語這組技巧（如選項 b）的核心關懷，跟萃取 Calculation（處理副作用混雜）、分層設計（處理抽象層級混雜）解決的是完全不同類型的問題。",
+      "verify": { "manual": "概念題：以具體多重 API 協調情境取代對章節分類的直接背誦，無可執行程式碼。" }
+    },
+    {
+      "id": "fp-2-q6",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "巢狀資料結構操作雜亂：適合用巢狀資料的更新手法",
+      "docs": "",
+      "story": "",
+      "prompt": "一段程式碼要「把每個訂單裡、每件商品的價格都調漲 10%」，訂單資料是巢狀結構（訂單陣列 → 每個訂單裡有商品陣列）。直接寫巢狀 for 迴圈手動修改，程式碼變得很難讀。書裡哪個主題會提供處理這類巢狀資料更新的手法？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "跟 React 狀態管理有關的主題，這個資料轉換問題單純是前端框架處理畫面更新的細節，跟資料結構本身無關" },
+        { "id": "b", "text": "只有時間線圖能處理巢狀資料的更新問題，因為時間線圖本來就是設計來處理所有資料操作的通用工具" },
+        { "id": "c", "text": "巢狀資料（nested data）操作的主題：提供像 update 這類「不整個攤平重寫，安全更新巢狀結構某一層資料」的函式模式，取代手寫巢狀迴圈直接修改" },
+        { "id": "d", "text": "書裡沒有討論這類巢狀資料的操作技巧，遇到這種情境只能自己手寫巢狀迴圈，沒有既有手法可以參考" }
+      ],
+      "answer": "c",
+      "explanation": "巢狀資料更新是一個獨立於「副作用」「執行順序」之外的問題類別——重點在「怎麼安全地只改動巢狀結構裡的某一小塊、又不破壞其餘部分的不可變性」，如選項 c 所述，書裡有專門一個主題處理這類手法。",
+      "verify": { "manual": "概念題：以具體巢狀資料調整情境取代對章節分類的直接背誦，無可執行程式碼。" }
     }
   ]
 }
diff --git a/packages/core/src/data/questions/fp-3-actions-calculations-data.json b/packages/core/src/data/questions/fp-3-actions-calculations-data.json
index d3565f2..1ee63e3 100644
--- a/packages/core/src/data/questions/fp-3-actions-calculations-data.json
+++ b/packages/core/src/data/questions/fp-3-actions-calculations-data.json
@@ -96,6 +96,25 @@
       "answer": "a",
       "explanation": "這個順序反映的是「推理與測試難度」：Data 不用執行就能檢視、Calculation 只需要給輸入斷言輸出、Action 則要準備假的外部環境還要驗證副作用真的發生了。能停在光譜左邊解決問題，就不要往右升級。",
       "verify": { "manual": "概念題：以三種寫法的測試難度對比取代抽象偏好說明，無可執行程式碼。" }
+    },
+    {
+      "id": "fp-3-q6",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "判斷 Action 的關鍵問句：呼叫時機/次數會不會影響結果",
+      "docs": "",
+      "story": "",
+      "prompt": "面對一段陌生的程式碼，想快速判斷它是 Action 還是 Calculation，該問自己哪個關鍵問題？",
+      "code": "function getCurrentUser() { return currentLoggedInUser; }\nfunction double(x) { return x * 2; }",
+      "options": [
+        { "id": "a", "text": "問「這個函式的程式碼行數有沒有超過 10 行」，超過 10 行就歸類成 Action，沒超過就歸類成 Calculation，跟行數多寡直接掛鉤" },
+        { "id": "b", "text": "問「呼叫一次跟呼叫兩次、現在呼叫跟等一下呼叫，結果會不會不一樣？」——getCurrentUser() 可能因登入狀態改變而回傳不同結果，是 Action；double(x) 不管何時呼叫幾次，同樣的 x 永遠得到同樣結果，是 Calculation" },
+        { "id": "c", "text": "問「這個函式有沒有回傳值」，有回傳值一律歸類成 Calculation，沒有回傳值一律歸類成 Action，跟函式內部實際做了什麼無關" },
+        { "id": "d", "text": "問「這個函式的名稱是不是動詞開頭」，只要命名是動詞開頭，就直接判定它是 Action，不需要再看函式內部邏輯" }
+      ],
+      "answer": "b",
+      "explanation": "「呼叫時機或次數會不會影響結果」（如選項 b）是辨識 Action 最直接的判斷句：只要答案是「會」，就代表這個函式依賴或影響了某個會隨時間變化的外部狀態，是 Action；答案是「不會」，才有資格被歸類成 Calculation。程式碼行數、有沒有回傳值、命名風格都不是可靠的判斷依據。",
+      "verify": { "manual": "概念題：辨識口訣搭配具體程式碼範例，無可執行程式碼。" }
     }
   ]
 }
diff --git a/packages/core/src/data/questions/fp-5-improve-actions.json b/packages/core/src/data/questions/fp-5-improve-actions.json
index d411f2b..75e9d8a 100644
--- a/packages/core/src/data/questions/fp-5-improve-actions.json
+++ b/packages/core/src/data/questions/fp-5-improve-actions.json
@@ -96,6 +96,25 @@
       "answer": "a",
       "explanation": "這正是分層設計的核心精神：底層的 cart 操作應該穩定、少變動；商業規則建立在底層之上，可以隨業務需求快速調整，不會牽動底下的基礎操作。",
       "verify": { "manual": "概念題：情境分析，無可執行程式碼。" }
+    },
+    {
+      "id": "fp-5-q6",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "判斷一個 Action 能不能被完全轉成 Calculation：問它牽涉的 I/O 是必要的還是順便的",
+      "docs": "",
+      "story": "",
+      "prompt": "add_item_to_cart 這個函式做了兩件事：①計算新的購物車內容 ②把新內容存進資料庫。哪一部分有機會被轉成純 Calculation，哪一部分永遠沒辦法？",
+      "code": "function add_item_to_cart(name, price) {\n  shopping_cart = add_item(shopping_cart, name, price); // ① 計算\n  saveToDb(shopping_cart); // ② 寫入資料庫\n}",
+      "options": [
+        { "id": "a", "text": "兩者都能完全轉成 Calculation，只要重構手法夠高明，連寫入資料庫這個動作本身也能變成單純的運算，不需要真的碰任何外部系統，也不會留下任何副作用" },
+        { "id": "b", "text": "①沒辦法轉成 Calculation，②反而可以，因為資料庫查詢跟寫入操作本質上都只是一種能夠預先算好結果、不會影響外部世界的運算過程而已" },
+        { "id": "c", "text": "兩者都永遠是 Action，因為這兩個步驟緊密綁在同一個函式呼叫序列裡，彼此互相依賴，沒有任何一部分可以被單獨拆解出來重構成純函式" },
+        { "id": "d", "text": "①（算新購物車內容）能轉成 Calculation：只是根據輸入算出新資料，不需要碰資料庫；②（寫入資料庫）永遠沒辦法變成 Calculation，因為「真的存進去」本身就是對外部世界產生效果，是 Action 的定義性特徵——重構目標是把 ① 從 ② 分離，而非讓 ② 消失" }
+      ],
+      "answer": "d",
+      "explanation": "重構 Action 的目標從來不是消滅所有副作用，而是把「可以獨立算出來的部分」跟「真正無法迴避的外部效果」分開，如選項 d 所述。這裡計算新購物車內容可以完全獨立驗證，但寫入資料庫這個動作本身，不管包裝得多漂亮，終究是一個 Action。",
+      "verify": { "manual": "概念題：以具體函式拆解取代抽象改善原則，無可執行程式碼。" }
     }
   ]
 }
diff --git a/packages/core/src/data/questions/fp-7-defensive-copying.json b/packages/core/src/data/questions/fp-7-defensive-copying.json
index ba15879..f172de5 100644
--- a/packages/core/src/data/questions/fp-7-defensive-copying.json
+++ b/packages/core/src/data/questions/fp-7-defensive-copying.json
@@ -96,6 +96,25 @@
       "answer": "a",
       "explanation": "深拷貝的代價會隨資料規模線性甚至更快成長，所以是「不得已才用」的工具：只在真正需要隔離不受信任程式碼的邊界上使用，其餘地方交給便宜很多的 copy-on-write。",
       "verify": { "manual": "概念題：對照書中拷貝成本的討論，無可執行程式碼。" }
+    },
+    {
+      "id": "fp-7-q6",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "defensive copying 保護的是誰：你自己的那一份，不是全世界",
+      "docs": "",
+      "story": "",
+      "prompt": "用 defensive copying 包裝了一個不受信任的第三方函式庫呼叫之後，這個第三方函式庫本身還是可以任意亂改「它自己拿到的那份拷貝」內部的資料。這樣還算是 defensive copying 成功發揮作用嗎？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "不算成功，defensive copying 完全失敗了，因為不受信任的程式碼依然能任意修改它拿到的那份資料，代表深拷貝這個保護機制根本沒有發揮任何實際作用" },
+        { "id": "b", "text": "無法判斷，這件事跟 defensive copying 的定義完全無關，成不成功要看第三方函式庫本身的程式碼品質好不好、寫得嚴不嚴謹" },
+        { "id": "c", "text": "算成功：defensive copying 保護的不是「阻止不受信任的程式碼做任何事」，而是「確保這種行為不會擴散到呼叫端自己手上的原始資料」；第三方函式庫怎麼蹂躪自己那份拷貝是它的事，只要呼叫端資料沒被污染，目的就達成了" },
+        { "id": "d", "text": "不算成功，只有第三方函式庫連它自己拿到的那份拷貝都完全不能修改、不能有任何動作，才能算是徹底防禦成功" }
+      ],
+      "answer": "c",
+      "explanation": "defensive copying 劃的是一條「隔離線」，不是「禁止線」：它保證的是隔離線這一側（呼叫端）的資料乾淨，不去管、也管不著隔離線另一側（不受信任的程式碼）內部想怎麼胡搞它自己那份拷貝，如選項 c 所述。理解這個邊界，才不會誤以為深拷貝之後就能約束第三方程式碼的行為。",
+      "verify": { "manual": "概念題：釐清防禦邊界的具體情境，無可執行程式碼。" }
     }
   ]
 }
diff --git a/packages/core/src/data/questions/ri-1-router.json b/packages/core/src/data/questions/ri-1-router.json
new file mode 100644
index 0000000..fafc2ca
--- /dev/null
+++ b/packages/core/src/data/questions/ri-1-router.json
@@ -0,0 +1,271 @@
+{
+  "id": "ri-1",
+  "title": "React Router：前端路由基礎",
+  "questions": [
+    {
+      "id": "ri-1-q1",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "四種 Router 元件怎麼挑",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊把一個 React SPA 部署到一台陽春的靜態檔案伺服器，沒有設定「找不到路徑就一律回傳 index.html」這種改寫規則。使用者在 /about 頁面按重新整理時，伺服器會直接回傳 404（因為它真的去找一個叫 about 的檔案，當然找不到）。在不能改伺服器設定的前提下，App 最外層該用哪一個 Router 元件包起來？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "HashRouter —— 網址其實是 /#/about 這種雜湊片段，# 後面的部分瀏覽器根本不會送給伺服器，伺服器永遠只看到對根目錄的請求，重新整理不會 404；代價是網址多了一個 # 符號" },
+        { "id": "b", "text": "BrowserRouter —— 用 HTML5 history API，網址乾淨沒有 #，但重新整理 /about 時瀏覽器會真的對伺服器發出 /about 請求，沒有改寫規則就會 404，跟「不能改伺服器設定」這個前提直接衝突" },
+        { "id": "c", "text": "MemoryRouter —— 路由狀態只存在記憶體裡，不會反映在網址列，使用者看不到網址、也存不了書籤，不適合一般對外的網頁" },
+        { "id": "d", "text": "StaticRouter —— 是給伺服器端渲染（SSR）用的一次性渲染結果，瀏覽器端後續的互動式導航不會用它" }
+      ],
+      "answer": "a",
+      "explanation": "四種 Router 差在「路由狀態存在哪裡、伺服器看不看得到」：BrowserRouter 用真實網址、需要伺服器配合改寫規則；HashRouter 把路由資訊藏進 # 後面，伺服器完全不會收到、天生免疫「重新整理 404」這個問題；MemoryRouter 只活在記憶體，適合測試或 React Native 這種沒有網址列的環境；StaticRouter 只服務 SSR 那一次性的渲染。這題的限制條件（不能改伺服器、但要能重新整理）剛好點名 HashRouter 的存在意義。",
+      "verify": {
+        "checks": [],
+        "manual": "情境屬部署設定與伺服器行為，需要真實伺服器與瀏覽器環境才能觀察；且依賴 react-router-dom（本專案未安裝），無法用 node 直接執行驗證。"
+      }
+    },
+    {
+      "id": "ri-1-q2",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "useNavigate 導頁後不留歷史記錄",
+      "docs": "",
+      "story": "",
+      "prompt": "按下「登出」按鈕後，要把使用者導到 /login，並且不希望使用者按瀏覽器的上一頁又跳回登出前的頁面。下面這段寫法，按上一頁之後會發生什麼事？",
+      "code": "function LogoutButton() {\n  const navigate = useNavigate();\n\n  function handleLogout() {\n    logout();\n    navigate(\"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/login\", { replace: true });\n  }\n\n  return <button onClick={handleLogout}>登出</button>;\n}",
+      "options": [
+        { "id": "a", "text": "不會跳回登出前的頁面：{ replace: true } 讓這次導頁『取代』目前這筆歷史記錄，而不是新增一筆，登出前那一頁的紀錄已經被蓋掉了" },
+        { "id": "b", "text": "會跳回登出前的頁面，因為 navigate 預設一律會新增一筆歷史記錄，replace 選項不影響瀏覽器上一頁的行為" },
+        { "id": "c", "text": "瀏覽器的上一頁按鈕會整個失效、不能按" },
+        { "id": "d", "text": "會跳到瀏覽器設定的首頁，跟這個 App 的路由完全無關" }
+      ],
+      "answer": "a",
+      "explanation": "useNavigate() 回傳的函式是 React Router v6 之後取代 v5 withRouter/this.props.history.push 的寫法。第二個參數 { replace: true } 對應 history 的 replace()：把目前這一筆歷史記錄換成新位置，而不是 push() 那樣疊加一筆新的。登出、送出表單後的導頁常用 replace，避免使用者按上一頁又跑回一個已經沒意義的舊狀態。",
+      "verify": {
+        "checks": [],
+        "manual": "牽涉瀏覽器 history 堆疊與使用者實際點擊上一頁的操作；且 useNavigate 依賴 react-router-dom（本專案未安裝），無法用 node 直接執行驗證。"
+      }
+    },
+    {
+      "id": "ri-1-q3",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "useParams 讀出來的動態路由參數",
+      "docs": "",
+      "story": "",
+      "prompt": "路由設定成 <Route path=\"/users/:userId\" element={<UserProfile />} />，目前網址是 /users/42。UserProfile 元件裡執行 console.log(useParams())，會印出什麼？",
+      "code": "// 路由設定\n<Route path=\"/users/:userId\" element={<UserProfile />} />\n\n// 目前網址：/users/42\nfunction UserProfile() {\n  const params = useParams();\n  console.log(params);\n}",
+      "options": [
+        { "id": "a", "text": "{ userId: \"42\" } —— useParams() 依路由裡每個 : 開頭的區段名稱當 key，抓出網址對應位置的實際內容當 value；即使網址上看起來是數字，抓到的一律是字串 \"42\"，不是數字 42" },
+        { "id": "b", "text": "{ userId: 42 } —— React Router 會自動把看起來像數字的參數轉型" },
+        { "id": "c", "text": "\"42\" —— 直接回傳字串本身，不會包成物件" },
+        { "id": "d", "text": "undefined —— useParams 這個 hook 只能在 class component 裡使用" }
+      ],
+      "answer": "a",
+      "explanation": "useParams() 回傳的是一個「路由參數名稱 → 網址對應片段字串」的物件，key 就是路徑裡 :userId 拿掉冒號後的名字，value 永遠是字串——網址本來就是文字，React Router 不會替你猜測要不要轉型。如果程式邏輯需要數字，得自己 Number(params.userId) 轉換。這也是 hook 的一種，只能在函式元件（或自訂 hook）裡呼叫，不能進 class component。",
+      "verify": {
+        "checks": [],
+        "manual": "useParams 需要 react-router-dom 的路由 context 才能運作，本專案未安裝該套件，無法用 node 直接執行驗證，需人工審核。"
+      }
+    },
+    {
+      "id": "ri-1-q4",
+      "type": "fill-in",
+      "difficulty": 2,
+      "topic": "查詢字串背後其實是原生 URLSearchParams",
+      "docs": "https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams/get",
+      "story": "",
+      "prompt": "React Router 的 useSearchParams 底層就是瀏覽器原生的 URLSearchParams。不依賴任何路由套件，只用原生 API 讀出查詢字串裡的 keyword，該呼叫哪個方法？把空格填起來",
+      "code": "const search = \"?keyword=react&page=2\";\nconst params = new URLSearchParams(search);\nconsole.log(params.____(\"keyword\"));",
+      "options": [
+        { "id": "a", "text": "get" },
+        { "id": "b", "text": "getItem" },
+        { "id": "c", "text": "read" },
+        { "id": "d", "text": "value" }
+      ],
+      "answer": "a",
+      "explanation": "URLSearchParams 是瀏覽器（跟 Node.js）都內建的原生 API，get(name) 回傳指定查詢參數的字串值，沒有對應的參數會回傳 null。getItem 是 localStorage/sessionStorage 的方法名稱，容易跟這裡搞混；read、value 都不是這個介面存在的方法。React Router 的 useSearchParams() hook，回傳的第一個值本質上就是一個 URLSearchParams 實例，用法完全共通。",
+      "verify": {
+        "checks": [
+          { "code": "const search = \"?keyword=react&page=2\";\nconst params = new URLSearchParams(search);\nconsole.log(params.get(\"keyword\"));", "expected": "react" }
+        ]
+      }
+    },
+    {
+      "id": "ri-1-q5",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "v5 到 v6：catch-all 404 路由的寫法變了",
+      "docs": "",
+      "story": "",
+      "prompt": "v5 熟悉的寫法是「在 Switch 裡省略 path 屬性的 Route，會永遠比對成功」，拿來當 404 頁面的 fallback。改用 v6 之後，如果只是照抄這個「省略 path」的習慣，還能達到一樣的 catch-all 效果嗎？",
+      "code": "// v5 寫法（Switch 底下，省略 path 的 Route 永遠比對成功）\n<Switch>\n  <Route exact path=\"/\" component={Home} />\n  <Route component={NotFound} />\n</Switch>\n\n// v6 寫法（直接照抄「省略 path」這個習慣）\n<Routes>\n  <Route path=\"/\" element={<Home />} />\n  <Route element={<NotFound />} />\n</Routes>",
+      "options": [
+        { "id": "a", "text": "不一樣：v6 拿掉了「省略 path 就永遠比對成功」這條規則，一個沒有 path 也沒有 index 的 Route，在 v6 裡不會被當成 catch-all；要重新達到 404 效果，得明確寫成 <Route path=\"*\" element={<NotFound />} />" },
+        { "id": "b", "text": "一樣，v6 完全相容 v5 的路由比對規則，只是把元件名稱從 Switch 改成 Routes" },
+        { "id": "c", "text": "一樣，只是 v6 要求元件要改用 element 屬性傳，比對規則本身沒變" },
+        { "id": "d", "text": "不一樣，因為 v6 整個移除了「用路由做 404 頁面」這個概念" }
+      ],
+      "answer": "a",
+      "explanation": "v5 到 v6 是一次不相容的改版：v6 引進了更精確的路徑比對演算法，也連帶取消了「沒寫 path 就無條件命中」這個隱性規則（沒有 path/index 的 Route 現在多半用在巢狀佈局裡配合 Outlet，不再是萬用 fallback）。要在 v6 做出跟 v5 一樣的『其餘路徑都導向 NotFound』效果，需要顯式寫 path=\"*\"，用萬用字元語法取代舊版「省略等於命中」的隱性行為。",
+      "verify": {
+        "checks": [],
+        "manual": "v5 的 Switch/Route 比對規則與 v6 的差異需要對照兩個套件版本的實際執行行為，且兩者皆依賴 react-router（本專案未安裝任一版本），無法用 node 直接執行驗證。"
+      }
+    },
+    {
+      "id": "ri-1-q6",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "登入後自動導向：Navigate 取代舊版 Redirect",
+      "docs": "",
+      "story": "",
+      "prompt": "使用者已經登入時，Login 頁面應該直接跳轉到 /dashboard，不要顯示登入表單。在 React Router v6 的函式元件裡，已登入的分支該 return 哪一段？",
+      "code": "function Login() {\n  const isLoggedIn = useIsLoggedIn();\n\n  if (isLoggedIn) {\n    // 該 return 哪一段？\n  }\n\n  return <LoginForm />;\n}",
+      "options": [
+        { "id": "a", "text": "改用 v6 的 <Navigate> 元件並加上 replace，取代掉 v5 的 <Redirect>", "code": "return <Navigate to=\"/dashboard\" replace />;" },
+        { "id": "b", "text": "沿用 v5 的 <Redirect> 元件", "code": "return <Redirect to=\"/dashboard\" />;" },
+        { "id": "c", "text": "直接呼叫 class component 風格的 history.push", "code": "history.push(\"/dashboard\");\nreturn null;" },
+        { "id": "d", "text": "整頁導頁，捨棄 React 應用程式現有的狀態", "code": "window.location.href = \"/dashboard\";\nreturn null;" }
+      ],
+      "answer": "a",
+      "explanation": "v6 把 v5 的 <Redirect> 元件整個移除，改用 <Navigate to=\"...\" />：直接 return 它，React Router 就會在渲染時觸發導頁，加上 replace 可以避免使用者按上一頁又跳回已經登入過的 Login 頁。选项 c 是 class component 時代透過 this.props.history 導頁的寫法，函式元件拿不到那個 props；選項 d 能導頁，但等於整頁重新整理、丟掉 React 應用程式目前的記憶體狀態，不是 React Router 想解決的用法。",
+      "verify": {
+        "checks": [],
+        "manual": "Navigate/Redirect 都依賴 react-router-dom 的路由 context 與瀏覽器環境，本專案未安裝該套件，無法用 node 直接執行驗證。"
+      }
+    },
+    {
+      "id": "ri-1-q7",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "React Router 解決的問題：讓網址跟畫面內容同步",
+      "docs": "",
+      "story": "",
+      "prompt": "一個 React 應用程式從頭到尾只有一個畫面，沒有任何『網址列變了、畫面內容也該跟著換』的需求。有人建議還是先引入 React Router「以防萬一」，這個建議合理嗎？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "不一定合理：React Router 存在的核心價值，是讓『網址（URL）』跟『畫面上顯示的內容』保持同步——多個畫面、頁面能被加入書籤與分享連結、瀏覽器上一頁／下一頁要能正確切換畫面，才是它真正解決的問題；如果應用程式只有一個畫面、沒有這些需求，引入一整套路由函式庫只是增加不必要的依賴與複雜度，等真的需要多畫面切換時再導入也不遲" },
+        { "id": "b", "text": "合理，任何 React 專案都應該無條件引入 React Router，不管有沒有多個畫面" },
+        { "id": "c", "text": "不合理，React Router 只能用在有後端伺服器的專案，純前端 SPA 不能使用" },
+        { "id": "d", "text": "合理，因為 React Router 是 React 官方套件，跟 react/react-dom 一樣是必要依賴" }
+      ],
+      "answer": "a",
+      "explanation": "任何函式庫的引入都該對應一個真實需求，React Router 也不例外：它要解決的是『網址跟畫面內容同步』這個問題。只有一個畫面的應用程式（例如一個小工具、一個單頁表單）沒有這個需求，硬加進來只是多一層抽象跟一個外部依賴，之後真的長出第二個畫面時再導入完全來得及，不需要為了『以防萬一』預先背負複雜度。",
+      "verify": {
+        "checks": [],
+        "manual": "屬架構決策的情境推理題，取決於專案實際需求，無可執行程式碼。"
+      }
+    },
+    {
+      "id": "ri-1-q8",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "history 函式庫 vs React Router：底層記錄 vs 畫面對應",
+      "docs": "",
+      "story": "",
+      "prompt": "React Router 內部其實是包了一層 history 這個函式庫。如果只是想在 React Native（沒有瀏覽器 window.history）裡管理『畫面堆疊』，直接學 history 這個底層函式庫、自己刻導航邏輯，還是直接用 React Router（或其對應版本），何者更合適？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "直接用 React Router 更合適：history 函式庫本身只負責管理『一串位置紀錄』這個底層資料結構，並依環境提供 browser／hash／memory 三種實作（memory 版本正是給沒有瀏覽器 window.history 的環境用的，例如 React Native、Node.js 測試）；React Router 在這之上，額外處理了『目前的位置該對應渲染哪個畫面元件』這一整層邏輯，這才是應用程式開發真正需要的，直接手刻在 history 之上重新做一遍等於重造輪子" },
+        { "id": "b", "text": "直接用 history 更合適，React Router 沒辦法在沒有瀏覽器的環境使用" },
+        { "id": "c", "text": "兩者功能完全一樣，選哪個都沒差" },
+        { "id": "d", "text": "history 函式庫已經被棄用，任何情境都該直接使用 React Router 的內部 API" }
+      ],
+      "answer": "a",
+      "explanation": "history 只回答「使用者去過哪些位置、現在在哪」這個底層問題；「這個位置該渲染哪個畫面元件」這一層對應邏輯（也就是應用程式開發者真正每天在寫的東西）是 React Router 加上去的價值。這也是為什麼 React Router 能透過 memory history 支援 React Native——沒有瀏覽器不影響「位置紀錄」跟「畫面對應」這兩件事本身的運作方式。",
+      "verify": {
+        "checks": [],
+        "manual": "history／react-router 均未安裝於本專案，底層行為需要真實套件執行才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-1-q9",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "push()：像陣列一樣不斷疊加歷史紀錄",
+      "docs": "",
+      "story": "",
+      "prompt": "使用者依序造訪了 A → B（用 push）→ C（用 push）。這時候瀏覽器的歷史紀錄堆疊長什麼樣子，按幾次上一頁能回到 A？",
+      "code": "navigate(\"/b\"); // push，堆疊：[A, B]\nnavigate(\"/c\"); // push，堆疊：[A, B, C]",
+      "options": [
+        { "id": "a", "text": "堆疊是 [A, B, C]，目前在 C；按一次上一頁回到 B，再按一次回到 A——push 每次都是『在陣列尾端新增一筆』，不會覆蓋掉任何既有紀錄，所以造訪過的每個頁面都能透過上一頁逐步回溯" },
+        { "id": "b", "text": "堆疊是 [C]，因為 push 每次都會清空之前的紀錄，按一次上一頁就會離開這個網站" },
+        { "id": "c", "text": "堆疊是 [A, C]，B 被中間跳過，按一次上一頁直接回到 A" },
+        { "id": "d", "text": "push 不會影響瀏覽器歷史紀錄，只有 replace 才會" }
+      ],
+      "answer": "a",
+      "explanation": "把 history 想像成一個只能往尾端新增、不能隨意刪改的陣列，是理解 push／replace 最直接的心智模型：push() 永遠是「在陣列尾端加一筆」，之前每一筆都完整保留；replace() 才是「把陣列最後一筆換成新的」，不會增加陣列長度。這裡全程都是 push，所以堆疊裡三個頁面都在，可以逐步用上一頁回溯到最早的 A。",
+      "verify": {
+        "checks": [],
+        "manual": "瀏覽器 history 堆疊的實際行為需要真實瀏覽器環境操作觀察，且依賴 react-router-dom（本專案未安裝），無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-1-q10",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "v6 的 Routes 內建互斥比對，不再需要額外包 Switch",
+      "docs": "",
+      "story": "",
+      "prompt": "v5 若把多個 <Route> 未經任何單一元素包裝、直接當成 <Router>（如 <BrowserRouter>）的子元素排開，因為 <Router> 規定只能接受一個子元素，官方會印出「Router may have only one child element」這類警告。這跟另一個獨立的問題——網址同時符合多個 Route 的 path 時，若沒有用 <Switch> 包住，這些符合的 Route 會全部一起渲染出來——是兩碼子事：只要用任一個元素（不限 <Switch>）包起來就能讓「only one child」警告消失，但只有 <Switch> 才會讓比對變成互斥、只渲染第一個符合的。改用 v6 的 <Routes> 之後，還需要自己額外處理這兩個問題嗎？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "不需要：v6 的 <Routes> 本身就只接受 <Route> 作為子元素、天生保證互斥比對，同時符合多個 path 時也只會渲染最匹配的那一個；『子元素數量』與『只渲染第一個符合的』這兩件事都內建在 Routes 裡，不再需要像 v5 那樣額外包一層 <Switch> 才能解決" },
+        { "id": "b", "text": "仍然需要，v6 只是把 Switch 改名成 Routes，行為完全一樣，一樣要手動確保只有一個包裝層" },
+        { "id": "c", "text": "不需要，因為 v6 已經完全移除『只渲染一個 Route』這個概念，允許同時渲染所有符合的 Route" },
+        { "id": "d", "text": "需要，但要改用 <Fragment> 包住所有 Route 才能達到互斥效果" }
+      ],
+      "answer": "a",
+      "explanation": "v5 的「Router may have only one child element」警告，根源只是 <Router> 規定子元素只能有一個——把多個 <Route> 未經包裝直接排開就會觸發，用任何單一元素包起來（哪怕只是一個 <div>）都能讓警告消失，這跟是不是用 <Switch> 沒有必然關係。但單純用 <div> 包起來並不會讓比對變成互斥：網址同時符合多個 <Route> 的 path 時，這些 Route 依然會全部一起渲染，要避免這個問題必須明確用 <Switch> 包住，因為「只挑第一個符合的渲染」是 Switch 自己的比對邏輯，不是子元素數量規則附帶的效果。v6 把這兩件事直接內建進 Routes：Routes 本身就只接受 Route 作為子元素、也保證只渲染第一個符合的，因此拿掉了「忘記包 Switch」這整類錯誤，官方文件也不再提供獨立的 Switch 元件。",
+      "verify": {
+        "checks": [],
+        "manual": "react-router-dom 未安裝於本專案，Routes 的比對邏輯需要真實套件執行才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-1-q11",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "用 navigate 的 state 選項傳遞資料，不出現在網址列",
+      "docs": "",
+      "story": "",
+      "prompt": "送出表單後想跳到 /result 頁面，同時把表單送出後拿到的 response.data 一併帶過去，不想放進網址的 query string 裡（避免資料暴露在網址列、或資料太大不適合塞進 URL）。v6 的 useNavigate 該怎麼寫？",
+      "code": "const navigate = useNavigate();\n\nfunction handleSubmit(response) {\n  navigate(\"/result\", {\n    state: { detail: response.data },\n  });\n}\n\n// 在 /result 頁面元件裡\nfunction ResultPage() {\n  const location = useLocation();\n  console.log(location.state); // ?\n}",
+      "options": [
+        { "id": "a", "text": "{ detail: response.data }：navigate() 的第二個參數可以帶一個 state 物件，這份資料會存在瀏覽器的 history entry 裡，不會出現在網址列上（不像 query string）；目的頁面透過 useLocation().state 就能讀回這份資料，適合傳遞『不想被使用者看到網址、或不方便序列化進字串』的內容" },
+        { "id": "b", "text": "undefined：state 只能在 v5 的 class component 裡透過 this.props.history 存取，v6 已經移除這個功能" },
+        { "id": "c", "text": "response.data 會被自動轉成 query string 附加在網址後面" },
+        { "id": "d", "text": "程式會拋出例外，navigate() 的第二個參數只能是字串" }
+      ],
+      "answer": "a",
+      "explanation": "這是 v5 「history.push({ pathname, state })」這種寫法在 v6 的對應版本：navigate 的第二個參數物件裡的 state 欄位，會原封不動存進這筆瀏覽器歷史紀錄，不出現在網址上，目的頁面用 useLocation().state 讀回。要注意這份資料存在『這筆 history entry』裡、不在網址裡，所以不會出現在分享出去的連結上，直接輸入網址造訪、開新分頁，或任何『重新產生一筆新 history entry』的情境，該筆新 entry 都不會帶有這份 state，讀到的會是 undefined；同一筆 entry 單純整頁重新整理時，state 是否還在則要看瀏覽器實作（多數現代瀏覽器會保留），不是「重新整理就一定會清掉」這種絕對規則。不適合放「必須可被分享連結、書籤或直接貼網址存取」的關鍵資料。",
+      "verify": {
+        "checks": [],
+        "manual": "react-router-dom 未安裝於本專案，navigate 的 state 傳遞需要真實路由 context 才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-1-q12",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "元件樹之外觸發導頁：自訂 history 實例",
+      "docs": "",
+      "story": "",
+      "prompt": "一個放在 utils/api.js 的攔截器（不是 React 元件，是一般 JS 函式），偵測到 API 回傳 401 未授權時，想導頁到 /login。但 useNavigate() 是 Hook，只能在函式元件或自訂 Hook 內呼叫，這種『元件樹之外』的情境該怎麼觸發導頁？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "自己建立並匯出一個共用的 history 實例（例如用 history 套件的 createBrowserHistory()），讓最上層改用能接受自訂 history 的 Router，app 裡任何地方（包括 utils/api.js 這種非元件檔案）都直接 import 這個共用 history、呼叫 history.push('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/login') 觸發導頁，不受 Hook『只能在元件內呼叫』的限制" },
+        { "id": "b", "text": "在 utils/api.js 裡直接呼叫 useNavigate()，Hook 沒有這個限制，任何檔案都能用" },
+        { "id": "c", "text": "沒有辦法，React Router 不支援在元件樹之外觸發任何導頁行為" },
+        { "id": "d", "text": "用 window.location.reload() 就能達到跟 useNavigate 完全一樣的效果" }
+      ],
+      "answer": "a",
+      "explanation": "Hook 的『只能在元件內呼叫』限制，本質上是因為它依賴 React 內部的呼叫順序追蹤，跟一般 JS 函式的執行環境不相容。解法是把「誰負責記錄目前位置」這件事，從『只能透過 Hook 存取的 React 內部狀態』，換成『一個一般 JS 變數就能 import 的共用實例』——由這個共用 history 實例驅動 Router，App 裡任何檔案（不管是不是元件）都能直接操作它，等於把導頁能力從 React 樹狀結構裡解放出來。",
+      "verify": {
+        "checks": [],
+        "manual": "history／react-router 均未安裝於本專案，自訂 history 實例的路由行為需要真實套件執行才能觀察，無法用 node 直接驗證。"
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-10-core-props-events.json b/packages/core/src/data/questions/ri-10-core-props-events.json
new file mode 100644
index 0000000..f64a309
--- /dev/null
+++ b/packages/core/src/data/questions/ri-10-core-props-events.json
@@ -0,0 +1,170 @@
+{
+  "id": "ri-10",
+  "title": "Core React：事件處理與受控元件",
+  "questions": [
+    {
+      "id": "ri-10-q1",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "React 事件處理器接收的是 SyntheticEvent，不是原生事件",
+      "docs": "https://react.dev/learn/responding-to-events",
+      "story": "",
+      "prompt": "在原生 HTML 裡，事件處理器的 this 通常指向觸發事件的 DOM 節點；React 的事件命名也用駝峰式（onClick 而不是 onclick）。下面這段程式碼，e 這個參數實際上是什麼？",
+      "code": "function Button() {\n  function handleClick(e) {\n    console.log(e.type);\n  }\n  return <button onClick={handleClick}>點我</button>;\n}",
+      "options": [
+        { "id": "a", "text": "e 是 React 包裝過的 SyntheticEvent（合成事件）物件，不是瀏覽器原生的 Event；它把不同瀏覽器的事件差異抹平，提供一致的跨瀏覽器介面，屬性與方法（如 e.type、e.preventDefault()）用法上跟原生事件非常相似，但底層是 React 自己管理的物件" },
+        { "id": "b", "text": "e 就是瀏覽器原生的 Event 物件，React 對事件完全沒有做任何包裝" },
+        { "id": "c", "text": "e 永遠是 undefined，React 的事件處理器不會傳入任何參數" },
+        { "id": "d", "text": "e 是一個字串，內容就是事件名稱本身" }
+      ],
+      "answer": "a",
+      "explanation": "React 的事件系統會把原生瀏覽器事件包裝成 SyntheticEvent，抹平跨瀏覽器的行為差異、統一介面，這也是為什麼 React 的事件命名（onClick）跟原生 HTML 屬性（onclick）看起來相似又不完全相同——底層機制其實不一樣，只是 API 設計得盡量貼近開發者對原生事件的直覺。",
+      "verify": { "checks": [], "manual": "SyntheticEvent 需要真實瀏覽器事件觸發才能觀察，無法用 node 直接驗證，屬事實性說明題。" }
+    },
+    {
+      "id": "ri-10-q2",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "inline 條件表達式：用 && 或三元運算子取代 if/else 區塊",
+      "docs": "",
+      "story": "",
+      "prompt": "想在 JSX 裡「有未讀訊息才顯示紅點」，不想為了這一個小判斷另外抽出一個 if/else 區塊。下列哪種寫法最符合 JSX 慣例？",
+      "code": "function Badge({ unreadCount }) {\n  return (\n    <div>\n      收件匣\n      {unreadCount > 0 && <span className=\"dot\" />}\n    </div>\n  );\n}",
+      "options": [
+        { "id": "a", "text": "用 && 運算子：JSX 的大括號裡可以放任意運算式，unreadCount > 0 && <span /> 這種寫法利用了 JS 的短路求值——條件為 false 時，&& 直接回傳 false（React 不會渲染 false／null／undefined，等於什麼都不顯示）；條件為 true 時才會回傳並渲染右邊的 JSX，是 JSX 裡表達『有條件才顯示』最常見的慣例寫法" },
+        { "id": "b", "text": "JSX 內部完全不能放任何條件邏輯，必須把整個元件拆成兩個各自完整的 return 語句" },
+        { "id": "c", "text": "用 && 運算子時，如果 unreadCount 剛好是 0，畫面上會顯示字面上的數字 0" },
+        { "id": "d", "text": "inline 條件判斷只能用在 class component，函式元件不支援" }
+      ],
+      "answer": "a",
+      "explanation": "JSX 大括號本質上就是嵌入一個 JavaScript 表達式，&&、三元運算子、立即執行函式都能用。要注意選項 c 提到的陷阱是真實存在的（如果條件寫成 unreadCount &&，當 unreadCount 是數字 0，&& 會回傳 0 而不是 false，React 真的會把字面上的 0 渲染出來）——這裡的寫法是 unreadCount > 0，比較結果一定是布林值，才能安全避開這個陷阱。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Badge({ unreadCount }) {\n  return (\n    <div>\n      收件匣\n      {unreadCount > 0 && <span className=\"dot\" />}\n    </div>\n  );\n}\nconsole.log(renderToStaticMarkup(<Badge unreadCount={0} />));\nconsole.log(renderToStaticMarkup(<Badge unreadCount={3} />));", "expected": "<div>收件匣</div>\n<div>收件匣<span class=\"dot\"></span></div>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-10-q3",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "陣列渲染缺少 key 時，React 印出的 console 警告",
+      "docs": "https://react.dev/learn/rendering-lists",
+      "story": "",
+      "prompt": "渲染一份清單時忘記加上 key。這段程式碼執行起來會怎麼樣？",
+      "code": "function List({ items }) {\n  return (\n    <ul>\n      {items.map((item) => <li>{item}</li>)}\n    </ul>\n  );\n}",
+      "options": [
+        { "id": "a", "text": "畫面依然會正常渲染出清單內容，不會拋出例外；但 React 會在 console 印出「Warning: Each child in a list should have a unique 'key' prop」這類警告——key 是用來幫助 React 在清單增刪、重新排序時，正確追蹤『哪個元素對應哪筆資料』，缺少 key 不會讓程式壞掉，但清單有動態增刪時容易出現渲染錯位、state 對應錯誤等難以察覺的 bug" },
+        { "id": "b", "text": "程式會直接拋出例外，無法完成渲染" },
+        { "id": "c", "text": "React 會自動幫每個項目補上一個隨機的 key，開發者不需要擔心任何問題" },
+        { "id": "d", "text": "少了 key 只會影響 CSS 樣式，不影響任何 JavaScript 層面的行為" }
+      ],
+      "answer": "a",
+      "explanation": "key 不是一個必要到「沒有就會壞掉」的屬性，這也是它常被忽略的原因；但清單一旦牽涉到增刪、重新排序，React 靠 key 判斷「這個元素是不是同一個」，缺少它時 React 只能依賴陣列索引做猜測比對，容易出現 state 錯位（詳見既有 react-9 章節談的 key 與 state 對應關係）。這類問題往往要等清單真的動態變化才會現形，靜態清單看起來完全正常。",
+      "verify": { "checks": [], "manual": "console 警告訊息需要真實瀏覽器開發模式才會顯示，無法用 node -e 直接捕捉這類 React 內部警告輸出。" }
+    },
+    {
+      "id": "ri-10-q4",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "受控元件：畫面上的值完全由 state 決定，不是使用者打字直接反映",
+      "docs": "https://react.dev/reference/react-dom/components/input",
+      "story": "",
+      "prompt": "這個輸入框的 value 被綁定到 state，onChange 卻故意把輸入轉成大寫再存回去。使用者實際打小寫 abc，畫面上的輸入框最終顯示什麼？",
+      "code": "function UppercaseInput() {\n  const [value, setValue] = useState(\"\");\n  return (\n    <input\n      value={value}\n      onChange={(e) => setValue(e.target.value.toUpperCase())}\n    />\n  );\n}",
+      "options": [
+        { "id": "a", "text": "顯示 ABC：這是「受控元件」的定義性特徵——輸入框畫面上顯示的內容，完全由 value 這個 prop（背後綁的是 state）決定，不是瀏覽器原生輸入行為直接反映在畫面上；每次使用者打字觸發 onChange，React 攔截原始輸入、轉成大寫存進 state，下一次渲染時 input 的 value 就是這個轉換後的大寫值，使用者會親眼看到自己打的字『被自動轉成大寫』" },
+        { "id": "b", "text": "顯示 abc，因為瀏覽器原生的輸入行為不受 React state 控制" },
+        { "id": "c", "text": "輸入框會完全無法輸入任何文字，因為 value 被綁定成 state 之後就變成唯讀" },
+        { "id": "d", "text": "程式會拋出例外，value 屬性不能跟 onChange 一起使用" }
+      ],
+      "answer": "a",
+      "explanation": "「受控元件」意味著表單元素的顯示內容完全交給 React state 決定：使用者的輸入不是直接反映到畫面上，而是先觸發 onChange 事件、由開發者決定 state 該變成什麼、React 重新渲染後 input 的 value 才跟著更新。這個機制讓「即時轉大寫」「限制只能輸入數字」這類即時攔截與轉換輸入的功能變得直接可行。",
+      "verify": { "checks": [], "manual": "受控元件的輸入互動需要真實瀏覽器與使用者鍵盤事件才能觀察，無法用 node 直接驗證。" }
+    },
+    {
+      "id": "ri-10-q5",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "非受控元件：用 ref 讀取，不必每個按鍵都觸發重繪",
+      "docs": "",
+      "story": "",
+      "prompt": "一個只有送出時才需要讀取一次值、過程中完全不需要即時驗證或轉換輸入內容的搜尋框，用「非受控元件」（defaultValue + ref）取代「受控元件」（value + onChange + state），有什麼實際好處？",
+      "code": "function SearchBox() {\n  const inputRef = useRef(null);\n  function handleSubmit() {\n    console.log(inputRef.current.value); // 送出當下才讀一次\n  }\n  return (\n    <div>\n      <input ref={inputRef} defaultValue=\"\" />\n      <button onClick={handleSubmit}>搜尋</button>\n    </div>\n  );\n}",
+      "options": [
+        { "id": "a", "text": "使用者每次按鍵都不會觸發這個元件的 setState、也就不會觸發重繪；因為這個場景完全不需要即時知道、驗證或轉換輸入內容，讓瀏覽器原生自己管理輸入框的值、只在真正需要的那一刻（送出）用 ref 讀一次，省去『每個按鍵都要走一次 React 狀態更新與重繪』的開銷" },
+        { "id": "b", "text": "非受控元件的效能永遠比受控元件差，因為多用了一個 ref" },
+        { "id": "c", "text": "非受控元件無法搭配 defaultValue 設定初始值，只能是空字串" },
+        { "id": "d", "text": "使用非受控元件之後，這個輸入框就無法再被使用者手動輸入文字" }
+      ],
+      "answer": "a",
+      "explanation": "受控元件的即時性（每個按鍵都能攔截、驗證、轉換）是有代價的：每次按鍵都要走一次 state 更新與重繪。當這種即時性沒有實際需求時（只在提交那一刻讀一次值），非受控元件讓瀏覽器自己管理輸入框的內部狀態，React 端完全不用參與每一次按鍵，是更輕量的選擇——這也是 React 官方文件裡明確建議的取捨判斷。",
+      "verify": { "checks": [], "manual": "受控 vs 非受控元件的重繪次數差異需要真實瀏覽器互動才能觀察，無法用 node 直接驗證。" }
+    },
+    {
+      "id": "ri-10-q6",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "cloneElement：複製一個既有 element，同時覆寫部分 props",
+      "docs": "https://react.dev/reference/react/cloneElement",
+      "story": "",
+      "prompt": "createElement 是從零建立一個新 element；cloneElement 則是拿一個既有的 element 複製、同時覆寫部分 props。下面這段程式碼，最終渲染出的 className 會是什麼？",
+      "code": "const original = <p className=\"old\">Hello</p>;\nconst cloned = React.cloneElement(original, { className: \"new\" });\n\nconsole.log(renderToStaticMarkup(cloned));",
+      "options": [
+        { "id": "a", "text": "<p class=\"new\">Hello</p>：cloneElement(element, newProps) 會用 newProps 裡的欄位覆蓋原本 element 的同名 props，沒有在 newProps 裡提到的 props（例如這裡的 children「Hello」）會照原樣保留；這常用在 Higher-Order Component 裡『不動子元件原本的內容，只想額外覆寫或補上某幾個 props』的情境" },
+        { "id": "b", "text": "<p class=\"old\">Hello</p>，cloneElement 不會真的覆寫任何既有的 props" },
+        { "id": "c", "text": "程式會拋出例外，cloneElement 不能修改已經建立好的 element 的 props" },
+        { "id": "d", "text": "<p class=\"new\"></p>，cloneElement 會清空原本 element 的所有子內容" }
+      ],
+      "answer": "a",
+      "explanation": "createElement 是從零開始描述一個全新的 element；cloneElement 則是「複製＋局部覆寫」，其餘沒被覆寫的 props（包括 children）維持原樣。這在某些需要「攔截並增強子元件、卻不想重新宣告全部 props」的 HOC 或工具函式場景中很實用，但也因為隱含了對子元件 props 結構的假設，用多了容易讓程式碼難以追蹤資料從哪裡來，官方文件也提醒盡量減少對它的依賴。",
+      "verify": {
+        "checks": [
+          { "jsx": "import React from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nconst original = <p className=\"old\">Hello</p>;\nconst cloned = React.cloneElement(original, { className: \"new\" });\nconsole.log(renderToStaticMarkup(cloned));", "expected": "<p class=\"new\">Hello</p>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-10-q7",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "Lifting State Up：兩個手足元件要共享同一份 state，往上移到共同父層",
+      "docs": "",
+      "story": "",
+      "prompt": "TemperatureInput（攝氏）與另一個 TemperatureInput（華氏）需要「其中一個改了，另一個要跟著同步換算顯示」，但兩者是平行的手足元件，沒有直接的父子關係可以傳 props。該怎麼設計？",
+      "code": "// 兩個手足元件各自管理自己的 state，彼此看不到對方 → 無法同步\n// 解法：把溫度這份 state 往上移到共同的父層\nfunction Calculator() {\n  const [celsius, setCelsius] = useState(0);\n  return (\n    <>\n      <TemperatureInput scale=\"c\" value={celsius} onChange={setCelsius} />\n      <TemperatureInput scale=\"f\" value={celsius * 9/5 + 32} onChange={(f) => setCelsius((f - 32) * 5/9)} />\n    </>\n  );\n}",
+      "options": [
+        { "id": "a", "text": "把這份需要共享的 state 往上移到兩者共同的父層（這裡是 Calculator），子層不再各自持有自己的一份 state，而是透過 props 接收目前的值、透過 props 傳入的回呼函式通知父層『我變了』；父層是唯一的真實來源（single source of truth），兩個手足元件的畫面都從同一個地方換算出來，自然保持同步" },
+        { "id": "b", "text": "讓兩個手足元件直接互相 import 對方、直接呼叫對方元件內部的 setState" },
+        { "id": "c", "text": "把其中一個元件的 state 直接複製一份貼到另一個元件裡，兩份各自獨立更新" },
+        { "id": "d", "text": "這種情境沒有辦法解決，React 不支援手足元件之間的資料同步" }
+      ],
+      "answer": "a",
+      "explanation": "「Lifting State Up」是 React 官方文件裡處理『多個元件需要反映同一份、正在變化的資料』的標準模式：與其在多個地方各自維護一份容易不同步的 state，不如把這份 state 移到它們共同的最近父層，子層透過 props 讀取現況、透過父層傳入的回呼函式請求變更。這也是 Context、Redux 這類「集中管理共享狀態」方案背後的同一個核心原則，只是應用的範圍更大。",
+      "verify": { "checks": [], "manual": "屬狀態設計模式的推理題，牽涉多元件協調的完整互動情境，無法用單一 node 執行片段驗證。" }
+    },
+    {
+      "id": "ri-10-q8",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "state 跟 props 都變動時，畫面該以哪個為準",
+      "docs": "",
+      "story": "",
+      "prompt": "一個顯示使用者名稱的元件，同時吃 props.initialName（父層傳入的初始值）跟自己的 state（使用者可以在畫面上編輯暱稱、暫存在 state 裡，尚未送出儲存）。使用者編輯過暱稱後，父層重新渲染、又傳入一次一模一樣的 initialName，畫面該顯示使用者編輯過的內容，還是父層傳入的原始值？",
+      "code": "function NicknameEditor({ initialName }) {\n  const [name, setName] = useState(initialName); // 只在第一次渲染生效\n  return <input value={name} onChange={(e) => setName(e.target.value)} />;\n}",
+      "options": [
+        { "id": "a", "text": "應該顯示使用者編輯過的內容：useState(initialName) 只有在元件第一次渲染時會拿 initialName 當初始值，之後即使父層重新傳入同樣（或不同）的 initialName，也不會覆蓋掉使用者後續在畫面上編輯的 state；state 一旦建立，就是這個元件自己的、獨立於 props 之後變化的記憶，這正是「使用者的編輯內容不該被父層的重新渲染打斷」這個常見需求背後的機制" },
+        { "id": "b", "text": "應該顯示父層傳入的原始值，因為 props 的優先權永遠高於 state" },
+        { "id": "c", "text": "兩者會自動合併成一個新字串顯示" },
+        { "id": "d", "text": "程式會拋出例外，同一個元件不能同時使用 props 與 state" }
+      ],
+      "answer": "a",
+      "explanation": "useState(initialValue) 的 initialValue 參數只在元件的第一次渲染生效，這跟 useRef 的初始值行為一致（見既有 react-11 章節）。這個特性剛好符合這裡的需求：使用者一旦開始編輯，這份「使用者輸入」的 state 就該自己獨立存在，不因為父層重新渲染、重新傳入同樣的初始值而被打斷或覆蓋——這也是分辨『初始值』與『目前值』兩種不同概念的具體案例。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { useState } from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nfunction NicknameEditor({ initialName }) {\n  const [name] = useState(initialName);\n  return <input value={name} readOnly />;\n}\nconsole.log(renderToStaticMarkup(<NicknameEditor initialName=\"小明\" />));", "expected": "<input readOnly=\"\" value=\"小明\"/>" }
+        ]
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-11-core-vdom.json b/packages/core/src/data/questions/ri-11-core-vdom.json
new file mode 100644
index 0000000..16f69c5
--- /dev/null
+++ b/packages/core/src/data/questions/ri-11-core-vdom.json
@@ -0,0 +1,162 @@
+{
+  "id": "ri-11",
+  "title": "Core React：Virtual DOM 與渲染機制",
+  "questions": [
+    {
+      "id": "ri-11-q1",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "Virtual DOM：先在記憶體裡算好差異，再一次套用到真實 DOM",
+      "docs": "",
+      "story": "",
+      "prompt": "一份清單裡只有第 3 項的文字變了，其餘 99 項完全沒變。React 為什麼不是直接把整個清單的真實 DOM 全部砍掉重建，而是只更新第 3 項？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "React 在記憶體裡維護一份輕量的 Virtual DOM（用普通 JS 物件描述畫面），每次 state 改變時，會先在記憶體裡算出新舊兩份 Virtual DOM 的差異（diff），再把差異部分對應到真實 DOM 上做最小幅度的更新；直接操作真實 DOM（重排、重繪）比操作記憶體中的普通物件昂貴得多，只更新真正變化的部分能大幅減少不必要的瀏覽器工作量" },
+        { "id": "b", "text": "React 每次都會把整個畫面的真實 DOM 完全砍掉重建，Virtual DOM 只是行銷術語，沒有實質作用" },
+        { "id": "c", "text": "Virtual DOM 是瀏覽器原生提供的 API，React 只是呼叫瀏覽器內建的差異比對功能" },
+        { "id": "d", "text": "Virtual DOM 只在 React Native 環境使用，網頁版 React 不會用到這個機制" }
+      ],
+      "answer": "a",
+      "explanation": "「操作記憶體中的物件」遠比「操作真實 DOM」便宜，這是 Virtual DOM 存在的根本理由。React 靠比較新舊兩棵 Virtual DOM 樹（reconciliation），精準算出「哪些節點真的需要變」，再只把這些必要的變更套用到真實 DOM，避免了『整個畫面重新產生』這種昂貴又沒必要的操作。",
+      "verify": { "checks": [], "manual": "屬渲染機制的概念說明題，無可執行程式碼佐證內部差異比對演算法。" }
+    },
+    {
+      "id": "ri-11-q2",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "Virtual DOM 的運作三步驟：渲染、比較、提交",
+      "docs": "",
+      "story": "",
+      "prompt": "state 改變後，React 從『使用者看到畫面變化』回推，大致經過哪幾個階段？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "①渲染階段：呼叫元件函式，算出一棵新的 Virtual DOM 樹；②比較階段（diffing）：把這棵新樹跟上一次渲染留下的舊樹逐層比對，找出真正變化的部分；③提交階段（commit）：只把比對出來的差異套用到真實 DOM 上，並執行對應的副作用（如 useEffect）。這三個階段合稱 reconciliation（協調）" },
+        { "id": "b", "text": "React 只有一個階段：state 一改就立刻同步、逐一直接操作真實 DOM，中間沒有任何比較步驟" },
+        { "id": "c", "text": "React 會把整個瀏覽器分頁重新整理一次，才能反映 state 的變化" },
+        { "id": "d", "text": "這三個階段的順序是隨機的，每次執行都可能不一樣" }
+      ],
+      "answer": "a",
+      "explanation": "把「渲染」（算出新樹）、「比較」（跟舊樹 diff）、「提交」（真正動手改 DOM）拆成三個階段，是理解 React 內部運作、也是理解 useEffect（提交後才執行）跟 useLayoutEffect（提交後、瀏覽器繪製前）為什麼會有時序差異的基礎。三個階段的順序是固定的，不是隨機的。",
+      "verify": { "checks": [], "manual": "屬 React 內部渲染流程的說明題，需要原始碼層級理解，無法用單一可執行片段驗證。" }
+    },
+    {
+      "id": "ri-11-q3",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "Shadow DOM 解決樣式封裝問題，Virtual DOM 解決渲染效能問題——兩者目標不同",
+      "docs": "",
+      "story": "",
+      "prompt": "有人把 Shadow DOM（瀏覽器原生的 Web Components 標準之一）跟 Virtual DOM（React 的渲染機制）搞混，覺得兩者是同一種技術的不同稱呼。這樣理解正確嗎？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "不正確：Shadow DOM 是瀏覽器原生標準，目的是讓自訂元素擁有『封裝的』DOM 子樹與樣式（外部 CSS 選擇器打不進去，內部樣式也不會外洩），解決的是樣式與 DOM 結構的封裝隔離問題；Virtual DOM 是 React（與其他框架）自己在應用層實作的機制，目的是用記憶體中的物件比對減少真實 DOM 操作，解決的是渲染效能問題——兩者的目標、實作層級完全不同，只是名字都有『DOM』與『某種抽象層』的意味" },
+        { "id": "b", "text": "正確，Shadow DOM 與 Virtual DOM 是同一項瀏覽器標準技術的兩種不同稱呼" },
+        { "id": "c", "text": "不正確，因為 Shadow DOM 是 React 專屬技術，其他框架不能使用" },
+        { "id": "d", "text": "不正確，因為 Virtual DOM 是瀏覽器原生提供的標準 API" }
+      ],
+      "answer": "a",
+      "explanation": "這是一組經典的名詞混淆：Shadow DOM 是瀏覽器規範，解決樣式／DOM 封裝隔離（例如 <video> 內建的播放控制列，內部結構外部 CSS 動不了，就是靠 Shadow DOM）；Virtual DOM 是應用層框架的渲染最佳化手法，跟瀏覽器標準無關，是 React 等框架自己實作、自己維護的一份記憶體資料結構。",
+      "verify": { "checks": [], "manual": "屬兩個不同技術名詞的釐清題，無可執行程式碼。" }
+    },
+    {
+      "id": "ri-11-q4",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "React Fiber：讓渲染工作可以被拆分、暫停、依優先權排程",
+      "docs": "",
+      "story": "",
+      "prompt": "React 16 引入的 Fiber 架構，想解決舊版 reconciler（React 15 及更早）的什麼限制？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "舊版 reconciler 一旦開始比對整棵樹，就必須同步、一次性地跑完，中途無法暫停，遇到很深或很大的元件樹時，可能長時間佔用主執行緒，讓使用者的輸入、動畫這些更緊急的事情被卡住；Fiber 把渲染工作拆成一個個可以被中斷、之後再恢復的小單位（fiber 節點），讓 React 有能力依優先權排程——緊急的更新可以插隊，不那麼緊急的可以先暫停" },
+        { "id": "b", "text": "Fiber 純粹是把程式碼從 JavaScript 重寫成另一種程式語言，跟渲染排程無關" },
+        { "id": "c", "text": "Fiber 的唯一目的是縮小打包後的檔案體積" },
+        { "id": "d", "text": "Fiber 讓 React 不再需要 Virtual DOM，改成直接操作真實 DOM" }
+      ],
+      "answer": "a",
+      "explanation": "Fiber 是 React 16 重寫的核心演算法，把原本『一口氣同步跑完』的協調過程，改造成可以被拆分成小單位、可中斷、可依優先權排程恢復的架構。這是後來 Concurrent Rendering、useTransition、Suspense 這些「讓緊急更新插隊、不緊急更新可以暫緩」的功能得以實現的地基，不是單純的效能微調或語言重寫。",
+      "verify": { "checks": [], "manual": "React Fiber 屬內部演算法架構，需要原始碼層級理解，無法用可執行程式碼片段驗證。" }
+    },
+    {
+      "id": "ri-11-q5",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "reconciliation 依 type 判斷是否重用既有節點或整個重建",
+      "docs": "https://react.dev/learn/preserving-and-resetting-state",
+      "story": "",
+      "prompt": "同一個位置，前後兩次渲染分別放了 <UserCard /> 跟 <div>，元素型別完全不同。React 的 reconciliation 演算法會嘗試「保留舊節點、只更新差異部分」，還是「直接整個銷毀重建」？",
+      "code": "// 第一次渲染\n<UserCard name=\"Alice\" />\n\n// 第二次渲染（同一個位置，型別換了）\n<div>Alice</div>",
+      "options": [
+        { "id": "a", "text": "直接整個銷毀重建：reconciliation 演算法的一條核心捷徑規則是『比較同一位置前後兩次渲染的元素型別（type），型別不同就直接判定整棵子樹都不能重用』，不會嘗試比對兩者內部的細節差異；UserCard 元件（連同它內部可能持有的 state）會被完全卸載，換上的 div 是全新建立的節點" },
+        { "id": "b", "text": "React 會嘗試把 UserCard 內部的欄位一一比對，找出可以沿用到 div 上的部分" },
+        { "id": "c", "text": "React 會拋出例外，同一個位置前後兩次渲染的元素型別必須完全一致" },
+        { "id": "d", "text": "型別不同時 React 會自動選擇效能較好的那一種，忽略程式碼實際寫的內容" }
+      ],
+      "answer": "a",
+      "explanation": "這是一條刻意的效能捷徑：與其耗費算力去比對兩個完全不同型別的元素有沒有任何可以沿用的部分，React 直接假設『型別不同＝完全不相關』，整棵子樹砍掉重建。這也解釋了既有 react-9 章節談到的「同位置換了不同型別就會重建、state 全部消失」這個現象背後的真正機制。",
+      "verify": { "checks": [], "manual": "reconciliation 的節點重用判斷需要多輪真實渲染才能觀察，無法用單次 node 執行驗證。" }
+    },
+    {
+      "id": "ri-11-q6",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "React.lazy 搭配 named export：目前只支援 default export",
+      "docs": "",
+      "story": "",
+      "prompt": "想用 React.lazy 動態載入一個用 named export（不是 default export）匯出的元件，下面這樣寫可以正常運作嗎？",
+      "code": "// MyComponent.js\nexport function MyComponent() { return <p>Hi</p>; }\n\n// 想動態載入\nconst LazyMyComponent = React.lazy(() => import(\"./MyComponent\"));",
+      "options": [
+        { "id": "a", "text": "不行：React.lazy() 要求傳入的函式回傳的 Promise，其 resolve 值必須是一個帶有 default 欄位的模組物件（{ default: Component }）；直接對一個只有 named export 的模組呼叫 import()，resolve 出來的物件裡沒有 default 欄位，React.lazy 找不到要渲染的元件。常見解法是在 import() 的 Promise 鏈裡手動轉接，例如 .then(module => ({ default: module.MyComponent }))" },
+        { "id": "b", "text": "可以，React.lazy 會自動掃描模組裡所有的 named export，任選一個當作要渲染的元件" },
+        { "id": "c", "text": "可以，但只有在 TypeScript 專案裡才支援 named export 搭配 lazy" },
+        { "id": "d", "text": "不行，React.lazy 這個 API 已經完全被棄用，必須改用其他方式做程式碼分割" }
+      ],
+      "answer": "a",
+      "explanation": "這是 React.lazy 一個具體、常被問到的限制：它認的是 { default: Component } 這個固定形狀，不會自動去猜測、掃描模組裡有哪些 named export。想動態載入 named export 的元件，得自己在 import() 之後用 .then() 手動組出一個帶 default 欄位的物件，橋接兩種匯出方式的落差。",
+      "verify": { "checks": [], "manual": "React.lazy 搭配動態 import() 需要真實模組載入環境（瀏覽器或建置工具的 code splitting）才能觀察，無法用 node -e 直接驗證。" }
+    },
+    {
+      "id": "ri-11-q7",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "className vs class：JSX 是 JavaScript 表達式，class 是保留字",
+      "docs": "https://react.dev/learn/writing-markup-with-jsx",
+      "story": "",
+      "prompt": "在 JSX 裡想幫一個 div 加上 CSS class，寫成 <div class=\"card\">，會發生什麼事？",
+      "code": "function Card() {\n  return <div class=\"card\">Hi</div>;\n}",
+      "options": [
+        { "id": "a", "text": "這段程式碼在轉譯或執行期通常仍然可以動（React 只是印出警告，不會直接中斷），但這是不建議的寫法：JSX 最終會被轉譯成 JavaScript 的 React.createElement 呼叫，而 class 是 JavaScript 語言本身的保留字（用來宣告類別），為了避免衝突，JSX 統一改用 className 這個屬性名稱對應到 HTML 的 class；渲染到最終 HTML 時，className 才會被轉換回瀏覽器認得的 class" },
+        { "id": "b", "text": "程式一定會在建置階段直接拋出語法錯誤，完全無法通過編譯" },
+        { "id": "c", "text": "class 屬性會被正常渲染成 HTML，且是官方建議的標準寫法，className 才是已淘汰的舊寫法" },
+        { "id": "d", "text": "class 屬性在 JSX 裡會被自動忽略，畫面上完全不會套用任何樣式" }
+      ],
+      "answer": "a",
+      "explanation": "class 在 JavaScript 裡是保留字（ES6 class 語法），JSX 本質上是 JavaScript 表達式，如果直接允許 class 當屬性名稱，會跟語言本身的關鍵字衝突，所以官方選擇用 className 這個不會衝突的名稱，對應到最終渲染出的 HTML class 屬性。實務上直接寫 class 屬性通常還是能被 React 接受並印出警告，但這不是官方建議、也不保證未來版本行為一致。",
+      "verify": { "checks": [], "manual": "class 屬性在不同 React 版本下的容錯行為可能不同，且會印出開發模式警告，不適合做嚴格的自動化字串比對，需人工審核。" }
+    },
+    {
+      "id": "ri-11-q8",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "fragments 讓元件不必為了「回傳多個節點」多包一層無意義的 div",
+      "docs": "",
+      "story": "",
+      "prompt": "一個元件想回傳兩個平行的 <td> 元素（用在表格列裡），但 React 元件的 return 只能有一個根節點，直接 return 兩個 <td> 會報錯。多包一層 <div> 又會破壞表格必須是 tr 直接包 td 的 HTML 語意結構。該怎麼解決？",
+      "code": "function Columns() {\n  return (\n    <>\n      <td>Hello</td>\n      <td>World</td>\n    </>\n  );\n}",
+      "options": [
+        { "id": "a", "text": "用 Fragment（簡寫 <>...</>，或完整寫法 <React.Fragment>）當作根節點：Fragment 讓多個子節點可以被『邏輯上分組』成單一個 return 值，滿足 React 元件『只能回傳一個根節點』的語法要求，但完全不會在最終渲染出的 HTML 裡多產生任何真實節點，因此不會破壞表格 tr/td 這種對巢狀結構有嚴格要求的語意" },
+        { "id": "b", "text": "多包一層 div，即使因此破壞了表格的 HTML 語意結構也沒關係" },
+        { "id": "c", "text": "把兩個 td 分別放進兩個獨立的陣列裡各自 return" },
+        { "id": "d", "text": "React 元件本來就可以直接 return 多個根節點，不需要任何額外處理" }
+      ],
+      "answer": "a",
+      "explanation": "Fragment 存在的理由，正是解決「元件必須回傳單一根節點」跟「有些 HTML 結構（表格、清單）對巢狀關係有嚴格語意要求，不能隨便多包一層容器」這兩個限制的衝突。它是純邏輯分組工具，完全不出現在最終渲染結果裡，是簡寫語法 <>...</> 沒辦法帶 key 屬性時，才需要退回完整寫法 <React.Fragment key={...}>（前面 ri-7 章節已示範過的情境）。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Columns() {\n  return (\n    <>\n      <td>Hello</td>\n      <td>World</td>\n    </>\n  );\n}\nfunction Row() {\n  return <tr><Columns /></tr>;\n}\nconsole.log(renderToStaticMarkup(<table><tbody><Row /></tbody></table>));", "expected": "<table><tbody><tr><td>Hello</td><td>World</td></tr></tbody></table>" }
+        ]
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-12-core-hoc-composition.json b/packages/core/src/data/questions/ri-12-core-hoc-composition.json
new file mode 100644
index 0000000..8325564
--- /dev/null
+++ b/packages/core/src/data/questions/ri-12-core-hoc-composition.json
@@ -0,0 +1,159 @@
+{
+  "id": "ri-12",
+  "title": "Core React：HOC、children 與元件組合",
+  "questions": [
+    {
+      "id": "ri-12-q1",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "Higher-Order Component：一個接收元件、回傳增強版元件的函式",
+      "docs": "https://react.dev/reference/react/Component#alternatives",
+      "story": "",
+      "prompt": "withLoading 是一個 HOC，替任何元件加上「isLoading 為 true 時顯示 Loading 文字」的能力。下面這樣使用，isLoading=true 時會渲染出什麼？",
+      "code": "function withLoading(WrappedComponent) {\n  return function WithLoading({ isLoading, ...rest }) {\n    if (isLoading) return <p>Loading...</p>;\n    return <WrappedComponent {...rest} />;\n  };\n}\n\nfunction UserList({ users }) {\n  return <ul>{users.map((u) => <li key={u}>{u}</li>)}</ul>;\n}\n\nconst UserListWithLoading = withLoading(UserList);\n\nconsole.log(renderToStaticMarkup(<UserListWithLoading isLoading={true} users={[]} />));",
+      "options": [
+        { "id": "a", "text": "<p>Loading...</p>：withLoading(WrappedComponent) 是一個『接收一個元件、回傳一個新的、功能增強過的元件』的函式，這就是 Higher-Order Component 的定義；回傳的新元件 WithLoading 攔截了 isLoading 這個 prop，自己決定要顯示 Loading 文字還是把其餘 props 原封不動轉交給被包裝的 UserList，這裡 isLoading 是 true，所以顯示 Loading 文字，UserList 完全不會被渲染" },
+        { "id": "b", "text": "<ul></ul>：HOC 只是把兩個元件的 JSX 直接拼接在一起顯示" },
+        { "id": "c", "text": "程式會拋出例外，withLoading 這種寫法不是合法的 React 元件" },
+        { "id": "d", "text": "<p>Loading...</p><ul></ul>：isLoading 為 true 時，兩個元件都會同時渲染出來" }
+      ],
+      "answer": "a",
+      "explanation": "HOC 本質上就是一個普通的高階函式，只是它的輸入輸出都是 React 元件：拿一個元件進來，回傳一個新元件，新元件內部決定要不要渲染、怎麼渲染原本那個元件。這裡的 withLoading 攔截了 isLoading，自己判斷分支，只有不在 loading 狀態時才會把控制權（連同其餘 props）交還給被包裝的 UserList。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction withLoading(WrappedComponent) {\n  return function WithLoading({ isLoading, ...rest }) {\n    if (isLoading) return <p>Loading...</p>;\n    return <WrappedComponent {...rest} />;\n  };\n}\nfunction UserList({ users }) {\n  return <ul>{users.map((u) => <li key={u}>{u}</li>)}</ul>;\n}\nconst UserListWithLoading = withLoading(UserList);\nconsole.log(renderToStaticMarkup(<UserListWithLoading isLoading={true} users={[]} />));", "expected": "<p>Loading...</p>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-12-q2",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "children prop：夾在標籤中間的內容，會被當成一個特殊的 prop 傳入",
+      "docs": "https://react.dev/learn/passing-props-to-a-component#passing-jsx-as-children",
+      "story": "",
+      "prompt": "Card 元件沒有明確宣告任何 children 相關的邏輯，只是把 props.children 原樣輸出。下面這樣使用，渲染出的內容會是什麼？",
+      "code": "function Card({ children }) {\n  return <div className=\"card\">{children}</div>;\n}\n\nconsole.log(renderToStaticMarkup(\n  <Card>\n    <h2>標題</h2>\n    <p>內容</p>\n  </Card>\n));",
+      "options": [
+        { "id": "a", "text": "<div class=\"card\"><h2>標題</h2><p>內容</p></div>：寫在一對標籤中間（不是用屬性寫法 name=value）的任何 JSX 內容，都會被自動收集成一個叫 children 的特殊 prop 傳給這個元件；Card 元件把 children 直接輸出在 div 裡，所以夾在 <Card>...</Card> 中間的 h2 跟 p，就原封不動出現在 div 內部" },
+        { "id": "b", "text": "<div class=\"card\"></div>：children 這種寫法在 JSX 裡不會被自動收集成任何 prop，必須額外用 props.children 語法手動宣告才會生效" },
+        { "id": "c", "text": "程式會拋出例外，元件標籤中間不能直接寫其他 JSX 內容" },
+        { "id": "d", "text": "<h2>標題</h2><p>內容</p>：children 內容會被渲染，但外層的 div card 容器會被自動省略" }
+      ],
+      "answer": "a",
+      "explanation": "children 是 React 的一個慣例：JSX 標籤之間（不是屬性）夾的內容，會自動被收集、當成一個名為 children 的 prop 傳給該元件，開發者不需要額外設定就能透過 props.children 取用。這也是「容器型」元件（Card、Modal、Layout 這類負責包裝、不知道具體會塞什麼內容的元件）能夠通用的基礎機制。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Card({ children }) {\n  return <div className=\"card\">{children}</div>;\n}\nconsole.log(renderToStaticMarkup(\n  <Card>\n    <h2>標題</h2>\n    <p>內容</p>\n  </Card>\n));", "expected": "<div class=\"card\"><h2>標題</h2><p>內容</p></div>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-12-q3",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "JSX 裡寫註解要包在大括號裡的 { /* ... */ }",
+      "docs": "",
+      "story": "",
+      "prompt": "想在 JSX 結構裡加一行註解說明某段標籤的用途，直接沿用 JavaScript 一般的 // 單行註解語法，會發生什麼事？",
+      "code": "function Panel() {\n  return (\n    <div>\n      // 這是標題區塊\n      <h1>標題</h1>\n    </div>\n  );\n}",
+      "options": [
+        { "id": "a", "text": "// 這是標題區塊 這幾個字會被當成一段純文字內容渲染到畫面上，不會被當成程式碼註解——JSX 標籤之間的內容預設就是要顯示的文字／子元素，並沒有『識別 // 開頭是註解』這種語法規則；想在 JSX 結構裡寫真正的註解，必須用大括號包住 JS 的區塊註解，寫成 {/* 這是標題區塊 */}" },
+        { "id": "b", "text": "// 開頭的內容會被正確辨識成註解，完全不會出現在畫面上，這是 JSX 標準支援的寫法" },
+        { "id": "c", "text": "這段程式碼會直接拋出語法錯誤，導致整個元件無法渲染" },
+        { "id": "d", "text": "只有在 TypeScript 專案裡，JSX 才支援 // 這種單行註解寫法" }
+      ],
+      "answer": "a",
+      "explanation": "JSX 標籤之間的內容，語意上等同於「要顯示的東西」，跟 JSX 大括號外層包著的才是「JavaScript 程式碼」剛好相反。// 這種行內註解語法只在 JavaScript 程式碼的上下文裡才有意義，直接寫在標籤之間會被當成純文字子節點；要在這個位置寫註解，得先用大括號 { } 切回 JavaScript 表達式的語境，再用區塊註解 /* ... */（JS 沒有大括號內合法的行內 // 註解用法，因為大括號內是表達式位置）。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Panel() {\n  return (\n    <div>\n      {/* 這是標題區塊 */}\n      <h1>標題</h1>\n    </div>\n  );\n}\nconsole.log(renderToStaticMarkup(<Panel />));", "expected": "<div><h1>標題</h1></div>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-12-q4",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "fragments 比容器 div 更好的原因：不多產生無意義的巢狀結構",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊發現某個列表元件因為每一項都用一個多餘的 div 包住，導致最終渲染出的 DOM 樹多了好幾層跟樣式、語意都無關的巢狀結構，也讓原本設計給『直接子元素』生效的 CSS 選擇器失效。改用 Fragment 取代這層 div，能解決什麼問題？",
+      "code": "// 用 div 包住：多一層跟語意無關的節點，也可能打斷 CSS 直接子元素選擇器（如 .list > *）\nfunction Item({ label }) {\n  return (\n    <div>\n      <dt>{label}</dt>\n      <dd>說明文字</dd>\n    </div>\n  );\n}\n\n// 改用 Fragment：不產生任何額外節點\nfunction Item({ label }) {\n  return (\n    <>\n      <dt>{label}</dt>\n      <dd>說明文字</dd>\n    </>\n  );\n}",
+      "options": [
+        { "id": "a", "text": "改用 Fragment 之後，最終的 DOM 樹裡不會多出這一層 div，dt/dd 會直接變成外層容器（例如 dl）真正的子元素，不僅符合表格、定義清單這類對巢狀關係有嚴格語意要求的 HTML 結構，也讓依賴『直接子元素』的 CSS 選擇器能正確命中；容器 div 額外佔用了一層 DOM 節點，卻沒有帶來任何語意或樣式上的價值，純粹是因為 React 需要一個單一根節點而『被迫』加上的" },
+        { "id": "b", "text": "沒有任何差異，div 跟 Fragment 在最終渲染出的 DOM 結構上完全一樣" },
+        { "id": "c", "text": "Fragment 只是把 div 的標籤名稱換掉，同樣會在 DOM 裡佔一層節點" },
+        { "id": "d", "text": "使用 Fragment 之後，dt 與 dd 就不能再套用任何 CSS 樣式" }
+      ],
+      "answer": "a",
+      "explanation": "「因為語法要求要有一個根節點，就隨手加一個 div」是很常見的無意識習慣，但這層 div 沒有任何語意價值，卻會實際出現在 DOM 樹裡，可能打斷 CSS 選擇器、破壞語意化 HTML 結構（像 dl 底下直接子元素應該是 dt/dd，不是 div）、也讓瀏覽器多一層節點要處理。Fragment 完全不佔用 DOM 節點，是解決「只是為了滿足語法要求而多包一層」這個問題的標準做法。",
+      "verify": { "checks": [], "manual": "屬 DOM 結構與 CSS 選擇器交互影響的推理題，需要真實瀏覽器渲染樹才能完整驗證選擇器命中情況。" }
+    },
+    {
+      "id": "ri-12-q5",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "Portal：把子元素渲染到 DOM 樹的另一個位置，但邏輯上仍是同一棵 React 樹",
+      "docs": "https://react.dev/reference/react-dom/createPortal",
+      "story": "",
+      "prompt": "一個 Modal 元件用 createPortal 把內容渲染到 document.body 下的一個獨立節點，而不是渲染在呼叫它的元件所在的 DOM 位置。這樣做主要是為了解決什麼問題？",
+      "code": "function Modal({ children }) {\n  return ReactDOM.createPortal(\n    <div className=\"modal\">{children}</div>,\n    document.getElementById(\"modal-root\")\n  );\n}",
+      "options": [
+        { "id": "a", "text": "解決『父層容器有 overflow: hidden 或 z-index 層疊限制，導致彈出視窗、提示框這類需要蓋在所有內容之上的 UI，被父層樣式意外裁切或壓在下面』的問題；createPortal 讓渲染出的 DOM 節點實際位置脫離了呼叫它的元件所在的巢狀結構（改掛在 document.body 底下），但在 React 的元件樹（事件冒泡、context 傳遞）裡，它仍然被當成原本位置的子元素看待，兩者是分開處理的" },
+        { "id": "b", "text": "createPortal 純粹是效能優化技巧，跟 CSS 層疊或裁切問題完全無關" },
+        { "id": "c", "text": "使用 createPortal 之後，這個元件就會完全脫離 React 的事件系統，點擊事件不會冒泡到父層" },
+        { "id": "d", "text": "createPortal 只能用於 React Native，網頁版 React 不支援這個 API" }
+      ],
+      "answer": "a",
+      "explanation": "Portal 解決的是「DOM 樹位置」跟「React 元件樹位置」可以不一致這個需求：像 Modal、Tooltip 這種需要視覺上蓋在所有內容之上的 UI，如果乖乖渲染在父層容器內部，很容易被父層的 overflow: hidden 或較低的 z-index 層疊環境限制住；createPortal 讓它們的真實 DOM 節點掛到別處（通常是 body 底下一個獨立節點），但事件冒泡、Context 取值這些 React 層面的行為，依然遵循它在元件樹裡『邏輯上』的位置，不受 DOM 實際位置影響。",
+      "verify": { "checks": [], "manual": "createPortal 需要真實瀏覽器 DOM 節點（document.getElementById）才能運作，無法用 node -e 或 renderToStaticMarkup 驗證。" }
+    },
+    {
+      "id": "ri-12-q6",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "stateless（函式）元件與 stateful（有 state 的）元件的差別純粹在於有沒有內部狀態",
+      "docs": "https://react.dev/learn/state-a-components-memory",
+      "story": "",
+      "prompt": "Greeting 只吃 props、沒有任何內部 state；Counter 用 useState 管理自己的點擊次數。這兩者都是「函式元件」，差異在哪？",
+      "code": "function Greeting({ name }) {\n  return <p>Hello, {name}</p>; // 沒有 state，畫面完全由 props 決定\n}\n\nfunction Counter() {\n  const [count, setCount] = useState(0); // 有自己的內部記憶\n  return <button onClick={() => setCount(count + 1)}>{count}</button>;\n}",
+      "options": [
+        { "id": "a", "text": "Greeting 是「無狀態（stateless）」元件：給定同樣的 props，永遠渲染出同樣的結果，沒有任何只屬於它自己、跨渲染保留的資料；Counter 是「有狀態（stateful）」元件：它用 useState 維護一份只屬於自己、跨渲染持續存在的資料（count），即使 props 完全沒變，它自己內部的狀態變化也能觸發重繪。兩者都是函式元件，區別純粹在於『有沒有使用 state』，不是語法上的不同種類" },
+        { "id": "b", "text": "只有 class component 才能是 stateful，函式元件永遠是 stateless" },
+        { "id": "c", "text": "stateless 元件不能接收任何 props，只有 stateful 元件才能" },
+        { "id": "d", "text": "這是兩種完全不同的、語法不相容的元件類型，不能用同一種方式定義" }
+      ],
+      "answer": "a",
+      "explanation": "stateless／stateful 描述的是「這個元件有沒有自己的內部記憶」，不是元件的語法類別；Hooks 出現之後，函式元件一樣可以透過 useState 變成 stateful，這組名詞的區分因此更貼近『有沒有用到 state』這個行為特徵，而不是『是函式還是 class』這種語法形式上的分類。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { useState } from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nfunction Greeting({ name }) {\n  return <p>Hello, {name}</p>;\n}\nfunction Counter() {\n  const [count] = useState(0);\n  return <button>{count}</button>;\n}\nconsole.log(renderToStaticMarkup(<Greeting name=\"Amy\" />));\nconsole.log(renderToStaticMarkup(<Counter />));", "expected": "<p>Hello, Amy</p>\n<button>0</button>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-12-q7",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "React 19 之後，函式元件上的 PropTypes 已完全失效（no-op），不會有任何開發模式警告",
+      "docs": "",
+      "story": "",
+      "prompt": "Age 是一個函式元件，額外掛了 Age.propTypes 宣告 value 必須是 number，呼叫端卻傳了一個字串 \"25\"。在目前的 React（19 版之後）裡，畫面最終會顯示什麼？",
+      "code": "function Age({ value }) {\n  return <p>年齡：{value}</p>;\n}\nAge.propTypes = {\n  value: PropTypes.number.isRequired,\n};\n\n// 呼叫端傳了字串，不是數字\n<Age value=\"25\" />",
+      "options": [
+        { "id": "a", "text": "畫面依然會正常顯示「年齡：25」，而且不會有任何型別警告：React 19 開始，指定在『函式元件』上的 propTypes 已經完全不會被檢查（no-op），不管開發模式還是正式環境都一樣，就算型別真的不符，也不會在 console 印出任何警告——這跟更早期 React（型別不符只在開發模式印警告、不阻斷渲染）的既有印象不同了；如果需要替函式元件的 props 做型別檢查，官方建議改用 TypeScript，或是自行在函式內寫執行期驗證邏輯" },
+        { "id": "b", "text": "程式會直接拋出例外，渲染完全中斷，畫面上什麼都不會顯示" },
+        { "id": "c", "text": "PropTypes 會自動把字串 \"25\" 轉型成數字 25 之後才渲染" },
+        { "id": "d", "text": "畫面會顯示「年齡：undefined」，因為型別不符的 prop 會被自動清空" }
+      ],
+      "answer": "a",
+      "explanation": "從 React 19 開始，React 已經移除對『函式元件』propTypes／defaultProps 的支援：即使宣告了 Age.propTypes，這段宣告只是一個沒有作用的靜態屬性，React 不會在任何模式下讀取或驗證它，也不會印出警告，畫面渲染完全不受影響、值本身也完全沒被動過。這跟舊版 React（型別不符只在開發模式印警告、不阻斷渲染）的行為不同——如果要在函式元件上做型別檢查，官方建議改用 TypeScript，或是自己在函式內寫執行期驗證。（注意：class component 的 propTypes 檢查機制不在此次變更範圍內，這裡討論的『no-op』只針對函式元件。）",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Age({ value }) {\n  return <p>年齡：{value}</p>;\n}\nconsole.log(renderToStaticMarkup(<Age value=\"25\" />));", "expected": "<p>年齡：25</p>" }
+        ]
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-13-core-ecosystem-position.json b/packages/core/src/data/questions/ri-13-core-ecosystem-position.json
new file mode 100644
index 0000000..02ab60c
--- /dev/null
+++ b/packages/core/src/data/questions/ri-13-core-ecosystem-position.json
@@ -0,0 +1,189 @@
+{
+  "id": "ri-13",
+  "title": "Core React：生態定位與周邊 API",
+  "questions": [
+    {
+      "id": "ri-13-q1",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "React 的優勢：元件化、可預測的資料流、龐大生態",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊要跟利害關係人說明「為什麼選 React」，下列哪個理由最貼近 React 實際帶來的優勢，而不是空泛的行銷詞？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "元件化讓 UI 可以拆成獨立、可重複使用、可各自測試的單元；配合單向資料流（props 往下傳、事件往上回報），大型應用的資料流向比雙向綁定更容易追蹤除錯；再加上生態系成熟（現成的路由、狀態管理、UI 元件庫選擇多），能加快開發速度、也容易找到有經驗的工程師" },
+        { "id": "b", "text": "React 保證任何專案的效能都優於所有其他框架，沒有例外" },
+        { "id": "c", "text": "React 是唯一能用 JavaScript 撰寫前端介面的技術，其他框架都必須用別的語言" },
+        { "id": "d", "text": "使用 React 之後，專案就完全不需要撰寫任何 CSS" }
+      ],
+      "answer": "a",
+      "explanation": "評估技術選型該講具體、可驗證的優勢，而不是無條件的行銷式宣稱。元件化、可預測的資料流、生態系規模，都是 React 實際、可以舉出具體案例佐證的優勢；效能、語言排他性、CSS 免除這類過度誇大的說法都禁不起檢驗。",
+      "verify": { "checks": [], "manual": "屬技術溝通與優勢陳述的推理題，無可執行程式碼。" }
+    },
+    {
+      "id": "ri-13-q2",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "React 的限制：只是 View 層，其餘（路由、狀態管理、資料抓取）要自己選型組合",
+      "docs": "",
+      "story": "",
+      "prompt": "新人剛學完 React 官方文件裡的元件、hooks，發現要做一個「有多個頁面、要打 API、要記住登入狀態」的完整應用，React 本身完全沒有提供路由、資料抓取、全域狀態這些功能，得自己額外選擇、組合其他套件。這反映了 React 定位上的什麼限制？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "React 核心刻意只專注在『View 層』（把 state 轉換成畫面）這一件事，不像 Angular 這類『全家桶』框架內建路由、狀態管理、HTTP 客戶端；這個限制的另一面是彈性——開發者能自由選擇路由（React Router）、狀態管理（Redux／Context）、資料抓取方案，但代價是一個完整應用需要自己組合、評估多個第三方套件，學習與決策成本比『開箱即用』的全家桶框架更高" },
+        { "id": "b", "text": "React 完全無法用來開發多頁面應用，只能做單一畫面的小工具" },
+        { "id": "c", "text": "這只是暫時的技術限制，React 官方即將把路由與狀態管理整合進核心套件" },
+        { "id": "d", "text": "這代表 React 的設計有缺陷，不應該被用在任何正式產品上" }
+      ],
+      "answer": "a",
+      "explanation": "React 官方明確把自己定位成一個「用來建構 UI 的函式庫」，而不是一個包山包海的框架，這是刻意的設計取捨：換取彈性（各個環節都可以替換成最適合團隊的方案），代價是入門的學習曲線與初期的選型工作量比 Angular 這類內建一切的框架更高，這是限制、不是缺陷，也沒有跡象顯示官方要把這些功能整合進核心。",
+      "verify": { "checks": [], "manual": "屬框架定位取捨的推理題，無可執行程式碼。" }
+    },
+    {
+      "id": "ri-13-q3",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "靜態型別檢查的選擇：TypeScript 目前是主流建議",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊的 React 專案目前完全沒有靜態型別檢查，props 傳錯型別要等執行期出錯才會發現。除了 PropTypes 這種執行期檢查，官方推薦的靜態型別檢查方案是什麼？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "TypeScript：它讓型別檢查發生在編譯期（寫程式碼、build 的當下），能在程式碼真正執行之前就攔截型別不符的錯誤，而不是等使用者的操作路徑剛好觸發問題才被發現；create-react-app、Vite、Next.js 這類主流的建置工具都內建 TypeScript 範本，目前是 React 生態系裡最廣泛採用的靜態型別方案" },
+        { "id": "b", "text": "只能用 PropTypes，React 目前沒有其他任何靜態型別檢查工具可以選擇" },
+        { "id": "c", "text": "必須改用 Angular 才能取得靜態型別檢查的能力" },
+        { "id": "d", "text": "React 從技術上無法搭配任何型別檢查工具使用" }
+      ],
+      "answer": "a",
+      "explanation": "PropTypes（執行期）與 TypeScript（編譯期）的差異前面已經細談過（見 ri-6、ri-12 章節），這裡要強調的是：靜態型別檢查在 React 生態系裡是完全可行、而且是目前主流建議的做法，並非只能靠執行期檢查、也不需要換框架才能取得型別安全。",
+      "verify": { "checks": [], "manual": "屬工具鏈選型的事實性題目，無需執行驗證。" }
+    },
+    {
+      "id": "ri-13-q4",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "react-dom：把 React 元件對應到瀏覽器 DOM 的橋接套件",
+      "docs": "",
+      "story": "",
+      "prompt": "為什麼 React 把「元件、Hooks、Context」這些核心概念放在 react 這個套件，卻把 createRoot、渲染到瀏覽器畫面這件事，另外拆到一個叫 react-dom 的獨立套件？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "react 套件本身是平台無關的核心（描述元件、狀態、生命週期這些概念，不假設渲染目標是什麼）；react-dom 是專門把這些概念對應到『瀏覽器 DOM』這個特定渲染目標的橋接層。這樣拆分讓同一套核心概念（元件、Hooks）可以被不同的 renderer 共用——react-dom 對應瀏覽器，react-native 對應 iOS/Android 原生元件，react-test-renderer 對應純 JS 物件——react 套件本身完全不需要因為渲染目標不同而改動" },
+        { "id": "b", "text": "純粹是歷史包袱，兩者理論上應該合併成同一個套件，只是還沒有人去做這件事" },
+        { "id": "c", "text": "react-dom 是給後端 Node.js 使用，react 套件只給瀏覽器前端使用" },
+        { "id": "d", "text": "這種拆分只是為了讓套件檔名看起來比較短，沒有任何架構上的意義" }
+      ],
+      "answer": "a",
+      "explanation": "這個套件拆分直接對應到前面 ri-5 章節談過的「reconciler 與 renderer 分離」架構：react 是渲染目標無關的核心，react-dom／react-native／react-test-renderer 是各自對應不同渲染目標的橋接層。這正是同一套 Hooks、元件寫法能同時支援網頁、行動裝置、測試環境的根本原因，不是隨意的套件拆分。",
+      "verify": { "checks": [], "manual": "屬套件架構設計理念的說明題，無可執行程式碼。" }
+    },
+    {
+      "id": "ri-13-q5",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "ReactDOMServer：把元件渲染成 HTML 字串，用於伺服器端渲染",
+      "docs": "https://react.dev/reference/react-dom/server",
+      "story": "",
+      "prompt": "renderToStaticMarkup 跟 renderToString 都能把 React 元件渲染成 HTML 字串，兩者最主要的差異是什麼？",
+      "code": "function Greeting() {\n  return <p data-testid=\"greeting\">Hi</p>;\n}\n\nconsole.log(renderToStaticMarkup(<Greeting />));\nconsole.log(renderToString(<Greeting />));",
+      "options": [
+        { "id": "a", "text": "兩者真正的差異不是輸出的字串長怎樣，而是這份輸出之後『能不能被用戶端 React 接手 hydrate』：renderToString 產生的 HTML 是設計給後續 hydrate 用的（讓用戶端接上事件監聽器、變成可互動的應用）；renderToStaticMarkup 產生的則是不打算被 hydrate 的純靜態輸出，用它的結果去 hydrate 是不被支援的行為。對這個沒有任何互動邏輯的簡單 Greeting 元件來說，兩者目前輸出的字串其實完全相同（如下方驗證所示）——差異在於用途與後續能不能安全 hydrate，不是『renderToString 一定會多印出看得到的標記屬性』" },
+        { "id": "b", "text": "兩者輸出完全一樣，沒有任何差異，只是函式名稱不同" },
+        { "id": "c", "text": "renderToStaticMarkup 只能渲染沒有任何 props 的元件" },
+        { "id": "d", "text": "renderToString 只能在瀏覽器端執行，renderToStaticMarkup 只能在 Node.js 執行" }
+      ],
+      "answer": "a",
+      "explanation": "兩者的核心差異在於「輸出的 HTML 之後支不支援在用戶端被 hydrate（接手成互動式 React 應用）」：renderToString 產生的輸出是為了支援後續 hydrate 而設計；renderToStaticMarkup 產生的是不打算被 hydrate 的純靜態輸出。對這個沒有任何互動邏輯的簡單 Greeting 元件來說，兩個函式目前輸出的字串確實完全相同（如驗證程式所示），但這不代表兩者『一定』會產生不同的標記字串——差異的本質在於用途與後續能不能安全 hydrate，而不是『renderToString 一律會多附加看得到的標記屬性』這種簡化說法。這也是本次新增的 React Router／Modern React 章節裡大量驗證題選用 renderToStaticMarkup 的原因：只需要靜態渲染結果，不需要 hydrate。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup, renderToString } from 'react-dom/server'\nfunction Greeting() {\n  return <p>Hi</p>;\n}\nconsole.log(renderToStaticMarkup(<Greeting />) === renderToString(<Greeting />));", "expected": "true" }
+        ]
+      }
+    },
+    {
+      "id": "ri-13-q6",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "dangerouslySetInnerHTML：명字本身就是警告，繞過 JSX 的自動逃逸機制",
+      "docs": "https://react.dev/reference/react-dom/components/common#dangerously-setting-the-inner-html",
+      "story": "",
+      "prompt": "想把一段從後端拿到、已經確定安全的 HTML 字串（例如富文本編輯器產生的內容）直接插入畫面，一般的 {content} 寫法會把它當純文字逃逸顯示（尖括號會變成文字符號，不會被解析成標籤）。該怎麼讓瀏覽器把這段字串真正解析成 HTML？",
+      "code": "function Article({ htmlContent }) {\n  return <div dangerouslySetInnerHTML={{ __html: htmlContent }} />;\n}",
+      "options": [
+        { "id": "a", "text": "使用 dangerouslySetInnerHTML={{ __html: 字串 }} 這個特殊屬性，它會繞過 JSX 對文字內容的自動逃逸機制，直接把字串當成 HTML 交給瀏覽器解析；屬性名稱刻意取得很長、帶有『danger』字樣，就是為了在程式碼審查時提醒開發者『這裡插入的內容如果來自不受信任的使用者輸入，會有 XSS 風險』，只有在確定內容安全（例如經過後端消毒過的內容）時才該使用" },
+        { "id": "b", "text": "直接把 htmlContent 放進 {htmlContent} 大括號裡，JSX 會自動判斷字串裡有沒有 HTML 標籤並決定要不要解析" },
+        { "id": "c", "text": "dangerouslySetInnerHTML 只是一個容易誤導人的屬性名稱，實際效果跟一般文字渲染完全一樣，不會真的解析 HTML" },
+        { "id": "d", "text": "必須把字串轉成 Base64 編碼之後才能用這個屬性顯示" }
+      ],
+      "answer": "a",
+      "explanation": "這正好跟前面 ri-7 章節談過的「JSX 自動逃逸文字內容」互為對照：一般情況下 React 為了防 XSS，會把放進大括號的內容一律當純文字逃逸；dangerouslySetInnerHTML 是唯一明確繞過這層保護的入口，屬性命名故意做得又長又顯眼，逼開發者正視『這裡跳過了安全機制，內容來源必須自己確保可信』這個責任。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Article({ htmlContent }) {\n  return <div dangerouslySetInnerHTML={{ __html: htmlContent }} />;\n}\nconsole.log(renderToStaticMarkup(<Article htmlContent=\"<b>粗體</b>\" />));", "expected": "<div><b>粗體</b></div>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-13-q7",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "行內樣式用 JS 物件表示，屬性名稱是駝峰式",
+      "docs": "https://react.dev/reference/react-dom/components/common#the-style-prop",
+      "story": "",
+      "prompt": "React 的 style 屬性不接受 CSS 字串，而是接受一個 JavaScript 物件。下面這段程式碼渲染出的 style 屬性字串會是什麼？",
+      "code": "function Box() {\n  return <div style={{ backgroundColor: \"tomato\", fontSize: 14 }}>Hi</div>;\n}\n\nconsole.log(renderToStaticMarkup(<Box />));",
+      "options": [
+        { "id": "a", "text": "<div style=\"background-color:tomato;font-size:14px\">Hi</div>：style 屬性接收的是一個物件，key 用駝峰式命名（backgroundColor），React 會自動轉換成 CSS 慣用的連字號寫法（background-color）；數字型別的值，React 也會自動幫大多數屬性（如 fontSize）補上 px 單位（少數屬性如 opacity、lineHeight 例外，維持純數字不加單位）" },
+        { "id": "b", "text": "<div style=\"backgroundColor:tomato;fontSize:14\">Hi</div>，React 完全不轉換屬性名稱與數字單位，原封不動輸出" },
+        { "id": "c", "text": "程式會拋出例外，style 屬性只能接受字串，不能傳物件" },
+        { "id": "d", "text": "<div style=\"background-color:tomato;font-size:14\">Hi</div>，字串跟數字都不加任何單位轉換" }
+      ],
+      "answer": "a",
+      "explanation": "React 的 style 屬性刻意設計成接收 JS 物件而不是 CSS 字串，一部分原因是物件寫法能直接複用 JS 的變數、運算、條件邏輯；駝峰式的 key 名稱也是為了避免連字號在 JS 物件屬性名稱裡需要额外用字串包住的不便。轉成最終 CSS 字串時，React 會處理好連字號轉換與大多數數字屬性的 px 單位補齊，省去手動字串拼接的麻煩。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Box() {\n  return <div style={{ backgroundColor: \"tomato\", fontSize: 14 }}>Hi</div>;\n}\nconsole.log(renderToStaticMarkup(<Box />));", "expected": "<div style=\"background-color:tomato;font-size:14px\">Hi</div>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-13-q8",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "React 事件跟原生事件的差異：合成事件、事件委派、駝峰式命名",
+      "docs": "",
+      "story": "",
+      "prompt": "已經知道 React 事件處理器收到的是 SyntheticEvent（見前面 ri-10 章節）。除此之外，React 的事件系統跟原生 DOM 事件相比，還有哪個實作層面的差異值得留意？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "React 內部並不是在每個 DOM 節點上各自綁定一份原生事件監聽器，而是採用『事件委派』：大多數事件實際上是在應用程式的根節點統一監聽，再由 React 自己判斷事件實際發生在哪個元件、依序模擬冒泡流程呼叫對應的處理器；這讓 React 能更有效率地管理大量元件的事件監聽，也是它能在事件處理器裡穩定拿到跨瀏覽器一致行為的實作基礎之一" },
+        { "id": "b", "text": "React 的事件系統與原生 DOM 事件在實作上完全相同，只是改用駝峰式命名，沒有任何底層差異" },
+        { "id": "c", "text": "React 的事件處理器只能監聽滑鼠事件，不支援鍵盤或觸控事件" },
+        { "id": "d", "text": "使用 React 事件系統之後，原生的 addEventListener 就完全無法在同一個應用程式裡使用" }
+      ],
+      "answer": "a",
+      "explanation": "事件委派（event delegation）是 React 事件系統的一個重要實作細節：與其在成千上百個 DOM 節點上各自掛一份監聽器（消耗記憶體、綁定/解綁都有成本），不如在根節點集中監聽、由 React 自己判斷該分派給哪個元件的處理器。這跟命名風格（駝峰式）是不同層次的差異，也不影響原生 addEventListener 仍然可以在同一頁面上並存使用。",
+      "verify": { "checks": [], "manual": "事件委派屬 React 內部實作細節，需要原始碼層級理解，無法用單一可執行片段驗證。" }
+    },
+    {
+      "id": "ri-13-q9",
+      "type": "predict-output",
+      "difficulty": 3,
+      "topic": "用陣列索引當 key，清單中間插入項目時會讓錯誤的元素對應到錯誤的 state",
+      "docs": "https://react.dev/learn/rendering-lists#why-does-react-need-keys",
+      "story": "",
+      "prompt": "清單一開始是 [A, B, C]，key 用陣列索引（0、1、2）。使用者在最前面插入一筆 X，變成 [X, A, B, C]。如果每一項的輸入框都用 useState 維護自己輸入的暫存文字，重新渲染後，原本輸入在 A 那一項裡的文字，會留在哪一項？",
+      "code": "// key 用陣列索引\nitems.map((item, index) => <ListItemInput key={index} label={item} />)\n\n// 插入前：index 0→A, 1→B, 2→C\n// 插入後：index 0→X, 1→A, 2→B, 3→C",
+      "options": [
+        { "id": "a", "text": "原本輸入在『第一項（index 0，當時對應 A）』裡的文字，插入後會錯誤地出現在新的『第一項（index 0，現在對應 X）』上：React 用 key 判斷『這是不是同一個元件實例、該不該保留它的 state』，用索引當 key 時，React 看到的只是『index 0 這個位置』，不知道實際資料已經從 A 換成 X，於是把原本屬於 index 0（A）的 state 直接沿用給現在也是 index 0、但其實是全新項目的 X，造成輸入內容跟顯示資料錯位" },
+        { "id": "b", "text": "React 會自動偵測到清單插入了新項目，正確地把 state 保留在原本的 A 項目上，跟 X 的插入位置無關" },
+        { "id": "c", "text": "所有項目的 state 都會被重置成初始值，沒有任何一項會保留輸入內容" },
+        { "id": "d", "text": "程式會拋出例外，陣列索引不能當作 key 使用" }
+      ],
+      "answer": "a",
+      "explanation": "這是「index 當 key」最經典、也最容易在真實專案裡造成使用者困惑的 bug：key 是 React 判斷『元素身份是否不變』的唯一依據，索引只反映『位置』，不反映『這筆資料是誰』。清單一旦有插入、刪除、重新排序這類會改變順序的操作，用索引當 key 就會讓 state 錯誤地跟著位置走、而不是跟著資料走。正確做法是用資料本身穩定、唯一的 id 當 key（例如每個 item 的資料庫主鍵），而不是它在陣列裡當下的索引。",
+      "verify": { "checks": [], "manual": "index-as-key 導致 state 錯位需要多輪真實互動（插入項目、比對 state 保留情況）才能觀察，無法用單次 node 執行驗證。" }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-14-core-rendering-patterns.json b/packages/core/src/data/questions/ri-14-core-rendering-patterns.json
new file mode 100644
index 0000000..67b76fb
--- /dev/null
+++ b/packages/core/src/data/questions/ri-14-core-rendering-patterns.json
@@ -0,0 +1,193 @@
+{
+  "id": "ri-14",
+  "title": "Core React：條件渲染與元件慣例",
+  "questions": [
+    {
+      "id": "ri-14-q1",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "條件渲染的幾種等價寫法：三元運算子、&&、提早 return",
+      "docs": "https://react.dev/learn/conditional-rendering",
+      "story": "",
+      "prompt": "isLoggedIn 為 false 時，這個元件用「提早 return」的寫法處理條件渲染。畫面會顯示什麼？",
+      "code": "function Greeting({ isLoggedIn }) {\n  if (!isLoggedIn) {\n    return <p>請先登入</p>;\n  }\n  return <p>歡迎回來</p>;\n}\n\nconsole.log(renderToStaticMarkup(<Greeting isLoggedIn={false} />));",
+      "options": [
+        { "id": "a", "text": "<p>請先登入</p>：在函式元件裡，提早 return 是處理『某個條件成立時，整個元件該顯示完全不同內容』最直接的寫法之一，跟三元運算子（isLoggedIn ? <A/> : <B/>）、&& 短路（只顯示或不顯示，沒有第二種內容）比起來，提早 return 特別適合『兩種情況的畫面結構差異很大、硬要用一個表達式塞在一起反而更難讀』的情境" },
+        { "id": "b", "text": "<p>歡迎回來</p>，提早 return 只會影響函式的執行流程，不影響最終畫面內容" },
+        { "id": "c", "text": "兩段文字都會顯示，因為函式元件裡的 return 不會真的中斷執行" },
+        { "id": "d", "text": "程式會拋出例外，函式元件裡不能有多個 return 語句" }
+      ],
+      "answer": "a",
+      "explanation": "三元運算子、&&、提早 return 都是條件渲染的合法手段，選哪一種通常看「兩種情況的畫面差異有多大」：差異小（有沒有一個小圖示）用 &&；兩種內容都要顯示、彼此互斥用三元；兩種情況的 JSX 結構差異很大、放在同一個表達式裡會很難讀，提早 return 通常最清楚。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Greeting({ isLoggedIn }) {\n  if (!isLoggedIn) {\n    return <p>請先登入</p>;\n  }\n  return <p>歡迎回來</p>;\n}\nconsole.log(renderToStaticMarkup(<Greeting isLoggedIn={false} />));", "expected": "<p>請先登入</p>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-14-q2",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "展開 props 到 DOM 元素上要小心，未知屬性會被原樣輸出到 HTML",
+      "docs": "https://react.dev/learn/passing-props-to-a-component",
+      "story": "",
+      "prompt": "Button 元件把收到的所有 props（用展開運算子）直接灑到底層的 <button> 上，圖方便不用一一列出每個要轉發的屬性。呼叫端不小心多傳了一個跟 HTML 屬性完全無關、只是內部邏輯用的 isPrimary，畫面會發生什麼事？",
+      "code": "function Button(props) {\n  return <button {...props}>{props.children}</button>;\n}\n\nconsole.log(renderToStaticMarkup(<Button isPrimary={true}>送出</Button>));",
+      "options": [
+        { "id": "a", "text": "isPrimary 不會出現在最終的 HTML 屬性裡（畫面上只有 <button>送出</button>）：目前的 React 會偵測出這不是一個合法的 HTML 屬性名稱，直接把它從輸出的 DOM 屬性裡濾掉，同時在 console 印出警告，提醒『如果是不小心從父層傳下來的，該在展開前先移除；如果真的想讓它出現在 DOM 上當自訂屬性，要改成全小寫的 isprimary』；不加選擇地展開全部 props，容易讓這種只給元件邏輯用的內部旗標，在不知情的狀況下產生一堆 console 警告雜訊" },
+        { "id": "b", "text": "isPrimary=\"true\" 會被原樣渲染到 HTML 上（<button isprimary=\"true\">），因為 React 對於不認得的屬性一律照樣輸出，不會做任何過濾" },
+        { "id": "c", "text": "程式會直接拋出例外，展開運算子不能用在 JSX 元素的屬性位置" },
+        { "id": "d", "text": "React 會自動把 isPrimary 轉換成合法的 aria-* 屬性再輸出" }
+      ],
+      "answer": "a",
+      "explanation": "React 對「看起來像自訂屬性但命名不符合慣例」的 prop 有偵測機制：不認得的駝峰式屬性名稱（如 isPrimary）會被濾掉、不會出現在最終 HTML 裡，同時在 console 印出警告告訴你原因與修正方式；只有全小寫、符合自訂屬性慣例的名稱（如 isprimary、或帶 data-/aria- 前綴）才會被正常輸出。這代表毫不篩選地展開全部 props 到底層 DOM 元素，雖然不會讓內部旗標洩漏到 HTML 上，但還是會在 console 產生警告雜訊，正確做法仍然是先明確解構出真正需要轉發給 DOM 的屬性。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Button(props) {\n  return <button {...props}>{props.children}</button>;\n}\nconsole.log(renderToStaticMarkup(<Button isPrimary={true}>送出</Button>));", "expected": "<button>送出</button>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-14-q3",
+      "type": "find-bug",
+      "difficulty": 1,
+      "topic": "memo 只做淺層比較，物件/函式型別的 props 每次都是新參考會讓 memo 失效",
+      "docs": "https://react.dev/reference/react/memo",
+      "story": "",
+      "prompt": "團隊幫一個效能敏感的元件包上 React.memo，卻發現它還是每次都跟著父層一起重繪，完全沒有省下任何重繪。父層每次重繪都用行內物件字面值傳入 style prop。這是為什麼？",
+      "code": "function Parent() {\n  const [tick, setTick] = useState(0);\n  return (\n    <div>\n      <button onClick={() => setTick((t) => t + 1)}>tick</button>\n      <ExpensiveChild style={{ color: \"red\" }} />\n    </div>\n  );\n}\nconst ExpensiveChild = React.memo(function ExpensiveChild({ style }) {\n  return <p style={style}>內容</p>;\n});",
+      "options": [
+        { "id": "a", "text": "React.memo 預設只做淺層比較（shallow compare）：逐一比較新舊 props 的每個欄位是否『參考相等』；每次父層重繪時，{ color: \"red\" } 這個行內物件字面值都會建立一個全新的物件參考（即使內容看起來一樣），淺層比較判定 style 這個 prop『變了』（新舊物件參考不同），memo 因此判斷『需要重繪』，完全沒省到任何重繪；要解決，得把這個物件抽到元件外部宣告成穩定的常數，或用 useMemo 包住，讓它在父層重繪之間保持同一個參考" },
+        { "id": "b", "text": "React.memo 對物件型別的 props 完全不做任何比較，一律視為沒變" },
+        { "id": "c", "text": "這是 React 的一個 bug，官方尚未提供任何解法" },
+        { "id": "d", "text": "只要用了 React.memo，物件型別的 props 就會自動被深層比較，這裡的情境不應該發生" }
+      ],
+      "answer": "a",
+      "explanation": "這是 memo 最常見的踩坑情境：memo 做的是「淺層」比較，物件、陣列、函式這類參考型別，只要每次渲染都重新建立（哪怕內容完全一樣），參考不相等就會被判定成「變了」。解法是讓這些參考型別的值在渲染之間保持穩定（提到元件外部宣告、或用 useMemo/useCallback 包住），memo 才能真正發揮跳過重繪的效果。",
+      "verify": { "checks": [], "manual": "memo 淺層比較造成重繪的行為需要多輪真實渲染才能觀察，無法用單次 node 執行驗證。" }
+    },
+    {
+      "id": "ri-14-q4",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "SSR：伺服器先產出 HTML，用戶端再 hydrate 接手成互動式應用",
+      "docs": "",
+      "story": "",
+      "prompt": "一個純用戶端渲染（CSR）的 React 應用，使用者打開網址後畫面會先是一片空白，等 JS 下載、執行完才看到內容。改成伺服器端渲染（SSR）之後，這個體驗會怎麼改變？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "使用者一打開網址，瀏覽器收到的就是伺服器已經把元件渲染好的完整 HTML（用 renderToString 之類的 API 產生），畫面能立刻顯示內容，不用等 JS 執行完；等 JS 真正下載並執行後，React 會透過 hydrate 把事件監聽器『接上』這份已經存在的 HTML，讓它變成完全互動式的應用——SSR 主要改善的是『使用者多快看到內容』（首次內容繪製），不是讓應用完全不需要 JavaScript" },
+        { "id": "b", "text": "SSR 之後應用完全不需要載入任何 JavaScript，所有互動都在伺服器端處理" },
+        { "id": "c", "text": "SSR 只會改變伺服器的效能，對使用者看到畫面的時間完全沒有任何影響" },
+        { "id": "d", "text": "SSR 會讓應用程式的邏輯完全搬到後端執行，前端完全不需要 React" }
+      ],
+      "answer": "a",
+      "explanation": "SSR 解決的核心痛點是「使用者多快看到有意義的內容」：伺服器預先算好 HTML 直接回應，省去等待 JS bundle 下載執行的空白畫面；但要讓畫面真正能互動（按鈕能點、輸入框能打字），還是需要用戶端下載、執行 JS，透過 hydrate 把事件邏輯接上已經存在的 HTML 結構——這也是為什麼 SSR 應用仍然需要載入 JavaScript，只是使用者不用『等 JS 才看得到內容』。",
+      "verify": { "checks": [], "manual": "SSR 與 hydrate 的實際使用者體驗需要真實伺服器與瀏覽器環境才能觀察，無法用 node 直接驗證。" }
+    },
+    {
+      "id": "ri-14-q5",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "生產模式建置：拿掉開發模式的額外檢查與警告，換取更小更快的產物",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊發現正式環境部署的是開發模式建置的 React 應用（檔案體積明顯較大、執行也比較慢），沒有切換成生產模式。啟用生產模式建置主要會帶來什麼改變？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "生產模式建置（例如用 Vite/webpack 的 production 設定，或框架的 build 指令）會拿掉開發模式專屬的額外檢查與警告訊息（例如重複 key 值警告、更詳細的錯誤訊息與元件堆疊追蹤、部分開發用的除錯輔助程式碼），並且做程式碼壓縮、tree-shaking，最終產物體積更小、執行效率更好；代價是拿掉這些開發時的輔助檢查，錯誤訊息會變得比較簡略，這也是為什麼開發階段建議一律用開發模式建置，只有真正要部署上線時才切成生產模式" },
+        { "id": "b", "text": "生產模式與開發模式的建置產物完全一樣，只有檔名不同" },
+        { "id": "c", "text": "生產模式會自動幫應用程式加上更多除錯訊息，方便正式環境排查問題" },
+        { "id": "d", "text": "只有付費版的 React 才能啟用生產模式建置" }
+      ],
+      "answer": "a",
+      "explanation": "React 內部有很多只在開發模式生效的檢查（例如重複 key 值警告、StrictMode 的額外重複呼叫、更詳細的錯誤訊息），這些檢查對開發階段抓 bug 很有幫助，但會拖慢執行效率、增加檔案體積，正式環境不需要它們。生產模式建置正是拿掉這些開發專屬負擔，換取更精簡、更快的正式產物，這是部署前的標準步驟，不是額外的付費功能。",
+      "verify": { "checks": [], "manual": "開發模式與生產模式建置產物的差異需要真實建置工具鏈才能比對，無法用 node 直接驗證。" }
+    },
+    {
+      "id": "ri-14-q6",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "Hooks 讓大部分 render props／HOC 的用途變得沒必要，但不是徹底取代",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊過去用 render props 模式（一個元件接收一個函式當 children，讓呼叫端決定怎麼渲染）跟資料訂閱邏輯共用。Hooks 出現之後，這種模式是不是完全被淘汰、不該再用？",
+      "code": "// render props 模式\n<DataSubscription>\n  {(data) => <p>{data}</p>}\n</DataSubscription>\n\n// Hooks 模式：直接把邏輯抽成自訂 Hook\nfunction useDataSubscription() {\n  const [data, setData] = useState(null);\n  // ...訂閱邏輯\n  return data;\n}\nfunction MyComponent() {\n  const data = useDataSubscription();\n  return <p>{data}</p>;\n}",
+      "options": [
+        { "id": "a", "text": "大部分『共用邏輯、不共用畫面』的情境，自訂 Hook 確實比 render props／HOC 更直接（不用多一層巢狀元件、程式碼可讀性通常更好），這也是 Hooks 推出後 render props／HOC 使用頻率大幅下降的原因；但 Hooks 並沒有完全取代這兩種模式能做的所有事——某些情境仍然需要真正影響到『元件樹的結構本身』（例如 Error Boundary 這種必須攔截子元件渲染錯誤的場景，Hooks 做不到），這時 HOC 或元件組合仍然有其位置" },
+        { "id": "b", "text": "完全淘汰，Hooks 出現之後 render props 與 HOC 在任何情境下都不應該再被使用" },
+        { "id": "c", "text": "Hooks 只是 render props 的另一種語法糖，兩者在底層實作上完全相同" },
+        { "id": "d", "text": "render props 與 HOC 從未被 Hooks 影響，兩者的使用頻率跟 Hooks 出現前完全一樣" }
+      ],
+      "answer": "a",
+      "explanation": "Hooks 主要解決的是「邏輯共用」不需要「多包一層元件」這個問題（過去 render props／HOC 常見的巢狀地獄），這讓大部分『純邏輯共用』的場景改用自訂 Hook 更直接；但涉及『元件樹結構本身』的需求（如 Error Boundary），Hooks 目前沒有對應能力，這也是前面 ri-9 章節提過「class component 仍有一個站得住腳的存在理由」的同一個原因。",
+      "verify": { "checks": [], "manual": "屬程式碼組織模式演進的推理題，無可執行程式碼。" }
+    },
+    {
+      "id": "ri-14-q7",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "switching component：依某個值動態決定要渲染哪一個元件",
+      "docs": "",
+      "story": "",
+      "prompt": "一個「依通知類型顯示不同圖示元件」的需求，與其寫一長串 if/else if 判斷，改用一個「型別到元件」的對照表（switching component 模式）。下面這樣寫，type=\"warning\" 時會渲染出什麼？",
+      "code": "const ICONS = {\n  info: () => <span>ℹ️</span>,\n  warning: () => <span>⚠️</span>,\n  error: () => <span>⛔</span>,\n};\n\nfunction NotificationIcon({ type }) {\n  const Icon = ICONS[type] ?? ICONS.info;\n  return <Icon />;\n}\n\nconsole.log(renderToStaticMarkup(<NotificationIcon type=\"warning\" />));",
+      "options": [
+        { "id": "a", "text": "<span>⚠️</span>：這是「switching component」模式——把『某個值對應到哪個元件』整理成一份物件對照表，用查表取代一長串的 if/else if／switch 判斷；找不到對應的 key 時（例如傳入一個沒定義過的 type），用 ?? 搭配一個預設元件（這裡是 info）當保底，程式碼在增加新的通知類型時，只需要往物件裡加一筆對照，不需要改動任何判斷邏輯本身" },
+        { "id": "b", "text": "會同時渲染三個圖示，因為物件裡定義了三個元件" },
+        { "id": "c", "text": "程式會拋出例外，型別對照表不能用來動態決定渲染哪個元件" },
+        { "id": "d", "text": "<span>ℹ️</span>，因為物件的 key 存取一律回傳第一個定義的元件" }
+      ],
+      "answer": "a",
+      "explanation": "switching component 本質上是「資料驅動選擇渲染內容」的具體案例：把『條件 → 對應行為』的關係從程式碼邏輯（if/else 分支）搬到資料結構（物件對照表）裡，新增一種情況只需要加一筆資料，不用改動任何既有的判斷邏輯，這是讓程式碼容易擴充、減少重複 if/else 判斷的常見手法。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nconst ICONS = {\n  info: () => <span>ℹ️</span>,\n  warning: () => <span>⚠️</span>,\n  error: () => <span>⛔</span>,\n};\nfunction NotificationIcon({ type }) {\n  const Icon = ICONS[type] ?? ICONS.info;\n  return <Icon />;\n}\nconsole.log(renderToStaticMarkup(<NotificationIcon type=\"warning\" />));", "expected": "<span>⚠️</span>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-14-q8",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "Pointer Events：統一滑鼠、觸控、手寫筆的事件模型",
+      "docs": "",
+      "story": "",
+      "prompt": "一個手繪畫板功能，希望同時支援滑鼠拖曳跟觸控螢幕手指拖曳，不想分別寫 onMouseDown/onMouseMove 跟 onTouchStart/onTouchMove 兩套邏輯。React 支援哪一組事件，讓多種輸入裝置可以共用同一套處理邏輯？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "Pointer Events（onPointerDown、onPointerMove、onPointerUp 等）：這是瀏覽器原生規範裡『統一』滑鼠、觸控、手寫筆等不同輸入裝置的事件模型，React 直接支援對應的合成事件版本，讓開發者只需要寫一套處理邏輯，不用再分別處理滑鼠事件與觸控事件兩套 API" },
+        { "id": "b", "text": "React 沒有提供任何統一的輸入裝置事件，必須自己手動偵測裝置類型並各自綁定" },
+        { "id": "c", "text": "Pointer Events 只支援滑鼠輸入，觸控螢幕完全無法觸發這組事件" },
+        { "id": "d", "text": "只有原生 JavaScript 才能使用 Pointer Events，React 的合成事件系統不支援" }
+      ],
+      "answer": "a",
+      "explanation": "Pointer Events 是瀏覽器規範層級對『輸入裝置多樣化』這個問題的解法：不管使用者是用滑鼠、手指觸控還是觸控筆，都能對應到同一組事件（pointerdown/pointermove/pointerup），省去分別處理 Mouse Events 跟 Touch Events 兩套 API 的重複工作，React 的合成事件系統完整支援這組事件的對應版本。",
+      "verify": { "checks": [], "manual": "Pointer Events 需要真實輸入裝置（滑鼠、觸控螢幕）互動才能觀察，無法用 node 直接驗證。" }
+    },
+    {
+      "id": "ri-14-q9",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "元件名稱必須大寫開頭，JSX 才會把它當成元件而不是 HTML 標籤",
+      "docs": "https://react.dev/learn/your-first-component#step-2-define-the-function",
+      "story": "",
+      "prompt": "元件命名不小心用了小寫開頭。JSX 引擎會怎麼解讀 <greeting />？",
+      "code": "function greeting() {\n  return <p>Hi</p>;\n}\n\n// 小寫開頭\nconsole.log(renderToStaticMarkup(<greeting />));",
+      "options": [
+        { "id": "a", "text": "React／JSX 會把小寫開頭的標籤（如 <greeting />）一律當成原生 HTML 標籤處理，而不是查找一個叫做 greeting 的元件；這裡瀏覽器並不認得一個叫 greeting 的 HTML 元素，會被當成一個未知的自訂標籤直接輸出，不會呼叫 greeting 這個函式，畫面上也就看不到 <p>Hi</p> 這段內容——這也是為什麼 React 官方強制要求元件名稱必須大寫開頭，讓 JSX 能明確分辨『這是元件』還是『這是原生標籤』" },
+        { "id": "b", "text": "JSX 會自動偵測到 greeting 是一個已宣告的函式，正確地把它當成元件呼叫，渲染出 <p>Hi</p>" },
+        { "id": "c", "text": "程式會在建置階段直接拋出語法錯誤，禁止使用小寫開頭的函式名稱" },
+        { "id": "d", "text": "小寫或大寫開頭對 JSX 而言完全沒有差異，只是程式碼風格上的建議" }
+      ],
+      "answer": "a",
+      "explanation": "JSX 用「首字母大小寫」當作區分『這是自訂元件』還是『這是原生 HTML 標籤』的依據——這是一條純粹依賴命名慣例的規則，沒有大小寫以外的判斷方式，也解釋了為什麼所有 React 元件命名規範都強制要求大寫開頭（PascalCase），一旦不小心用了小寫，JSX 引擎會直接當成一個瀏覽器不認得的 HTML 標籤處理，不會出錯提醒，但也不會呼叫你寫的元件函式。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction greeting() {\n  return <p>Hi</p>;\n}\nconsole.log(renderToStaticMarkup(<greeting />));", "expected": "<greeting></greeting>" }
+        ]
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-15-core-jsx-details.json b/packages/core/src/data/questions/ri-15-core-jsx-details.json
new file mode 100644
index 0000000..5bdfdbf
--- /dev/null
+++ b/packages/core/src/data/questions/ri-15-core-jsx-details.json
@@ -0,0 +1,159 @@
+{
+  "id": "ri-15",
+  "title": "Core React：JSX 語法細節",
+  "questions": [
+    {
+      "id": "ri-15-q1",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "React v16 起支援自訂 DOM 屬性直接透傳",
+      "docs": "https://react.dev/reference/react-dom/components/common",
+      "story": "",
+      "prompt": "想在 DOM 節點上加一個給自動化測試工具讀取用的自訂屬性 mycustomattribute（不是 data-* 或 aria-* 開頭），React 16 之後的版本會怎麼處理？",
+      "code": "function Widget() {\n  return <div mycustomattribute=\"123\">內容</div>;\n}\n\nconsole.log(renderToStaticMarkup(<Widget />));",
+      "options": [
+        { "id": "a", "text": "<div mycustomattribute=\"123\">內容</div>：React 16 起放寬了限制，任何寫成全小寫的自訂屬性都會被直接透傳到最終 DOM 上，不再要求一定要用 data-* 前綴；React 15 及更早的版本會把它濾掉，這是版本間一個實質的行為差異，不只是文件描述上的調整" },
+        { "id": "b", "text": "這個屬性會在任何 React 版本都被完全過濾掉，只有 data-* 開頭的屬性才能透傳" },
+        { "id": "c", "text": "程式會拋出例外，自訂屬性名稱只能是駝峰式，不能是全小寫" },
+        { "id": "d", "text": "React 會自動幫這個屬性加上 data- 前綴再輸出" }
+      ],
+      "answer": "a",
+      "explanation": "React 16 之前，未知的 DOM 屬性只有 data-*、aria-* 這兩種前綴會被保留，其餘一律濾掉；React 16 起放寬規則，只要屬性名稱是全小寫（符合 HTML 屬性慣例），就會被直接透傳到 DOM 上，不再限定前綴，這也是為什麼前一個小節裡 isPrimary（駝峰式）被濾掉、但改成全小寫 isprimary 就會被保留的原因。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Widget() {\n  return <div mycustomattribute=\"123\">內容</div>;\n}\nconsole.log(renderToStaticMarkup(<Widget />));", "expected": "<div mycustomattribute=\"123\">內容</div>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-15-q2",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "JSX 大括號裡可以放任意 JS 表達式，包含 map 這種迴圈方法",
+      "docs": "https://react.dev/learn/rendering-lists",
+      "story": "",
+      "prompt": "JSX 語法本身沒有內建 for 迴圈標籤，想在畫面上重複渲染一份清單，該怎麼在 JSX 裡「迴圈」？",
+      "code": "function List() {\n  const fruits = [\"蘋果\", \"香蕉\", \"橘子\"];\n  return (\n    <ul>\n      {fruits.map((fruit) => <li key={fruit}>{fruit}</li>)}\n    </ul>\n  );\n}",
+      "options": [
+        { "id": "a", "text": "在大括號裡使用陣列的 map() 方法：JSX 沒有專屬的迴圈語法，但大括號本來就能放任意 JavaScript 表達式，而 map() 剛好是『把陣列的每一項轉換成一個新值（這裡是轉換成一個 JSX 元素）』的表達式，回傳的元素陣列會被 React 依序渲染出來；不能直接在 JSX 裡寫 for 迴圈語句，因為 for 是陳述式（statement）不是表達式，不能放進大括號裡回傳值" },
+        { "id": "b", "text": "JSX 支援專屬的 <for> 標籤，直接寫 <for each={fruits}>...</for> 就能迴圈渲染" },
+        { "id": "c", "text": "必須先把整個陣列轉成字串，才能在 JSX 裡顯示出來" },
+        { "id": "d", "text": "React 不支援任何形式的陣列迴圈渲染，只能一個個手動寫死每一項" }
+      ],
+      "answer": "a",
+      "explanation": "這條規則背後的原因很單純：JSX 大括號裡只能放「表達式」（有回傳值的東西），for、if 這類「陳述式」語法不能直接放進去。map() 剛好是回傳新陣列的表達式，天生適合拿來做「陣列轉 JSX 元素陣列」這件事，這也是為什麼 React 生態裡用 map 做清單渲染是壓倒性的主流寫法，而不是額外設計一個 for 標籤。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction List() {\n  const fruits = [\"蘋果\", \"香蕉\", \"橘子\"];\n  return (\n    <ul>\n      {fruits.map((fruit) => <li key={fruit}>{fruit}</li>)}\n    </ul>\n  );\n}\nconsole.log(renderToStaticMarkup(<List />));", "expected": "<ul><li>蘋果</li><li>香蕉</li><li>橘子</li></ul>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-15-q3",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "屬性值想放變數，要用大括號而不是繼續套雙引號",
+      "docs": "https://react.dev/learn/writing-markup-with-jsx",
+      "story": "",
+      "prompt": "想把一個變數的值當作 img 的 src 屬性，下面兩種寫法哪一種正確？",
+      "code": "const avatarUrl = \"/avatar.png\";\n\n// 寫法一\n<img src=\"{avatarUrl}\" />\n\n// 寫法二\n<img src={avatarUrl} />",
+      "options": [
+        { "id": "a", "text": "寫法二才正確：屬性值想放一個 JavaScript 表達式（變數、函式呼叫、運算式），要用大括號 {}，不能包在雙引號裡；寫法一的 src=\"{avatarUrl}\" 會被當成字面上的字串 \"{avatarUrl}\"（連同大括號本身都是文字），瀏覽器會真的去請求一個叫做「{avatarUrl}」的檔案，而不是變數 avatarUrl 的實際值" },
+        { "id": "b", "text": "寫法一才正確，雙引號裡的大括號會被 JSX 自動識別成變數" },
+        { "id": "c", "text": "兩種寫法效果完全相同，都能正確取得 avatarUrl 變數的值" },
+        { "id": "d", "text": "兩種寫法都會拋出語法錯誤，屬性值不能是變數" }
+      ],
+      "answer": "a",
+      "explanation": "JSX 屬性值的語法規則很直接：雙引號包住的是字面字串常量；大括號包住的才是要被求值的 JavaScript 表達式。這組規則很容易在剛學 JSX 時搞混，把兩種語法疊在一起用（寫法一）是最常見的新手錯誤，結果會是把大括號本身也當成純文字的一部分，而不是觸發變數求值。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nconst avatarUrl = \"/avatar.png\";\nfunction App() {\n  return <img src={avatarUrl} />;\n}\nconsole.log(renderToStaticMarkup(<App />));", "expected": "<link rel=\"preload\" as=\"image\" href=\"/avatar.png\"/><img src=\"/avatar.png\"/>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-15-q4",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "PropTypes 的陣列元素型別驗證：arrayOf 搭配 shape",
+      "docs": "",
+      "story": "",
+      "prompt": "想驗證一個 prop 是「一份陣列，且陣列裡每個元素都是帶有 id（數字）與 name（字串）欄位的物件」，PropTypes 該怎麼宣告？",
+      "code": "UserList.propTypes = {\n  users: PropTypes.arrayOf(\n    PropTypes.shape({\n      id: PropTypes.number.isRequired,\n      name: PropTypes.string.isRequired,\n    })\n  ),\n};",
+      "options": [
+        { "id": "a", "text": "PropTypes.arrayOf(...) 驗證『這是一個陣列，且陣列裡每一項都符合括號裡指定的型別』；搭配 PropTypes.shape({...}) 進一步指定『每一項必須是物件，且物件內部這些欄位分別要符合對應的型別』，兩者組合起來就能驗證『帶有特定形狀的物件陣列』這種巢狀結構，比單純寫 PropTypes.array（只驗證是不是陣列，不管內部元素長什麼樣）精確得多" },
+        { "id": "b", "text": "PropTypes.arrayOf 只能驗證陣列長度，不能驗證陣列裡元素的型別" },
+        { "id": "c", "text": "PropTypes.shape 只能用在最外層的 props 物件，不能巢狀用在陣列元素裡" },
+        { "id": "d", "text": "這種寫法只在 TypeScript 專案裡才有效，純 JavaScript 專案的 PropTypes 不支援巢狀驗證" }
+      ],
+      "answer": "a",
+      "explanation": "arrayOf 與 shape 是 PropTypes 兩個可以組合巢狀使用的驗證子：arrayOf 描述『陣列＋元素型別』，shape 描述『物件＋各欄位型別』，兩者疊起來就能表達出「一份符合特定結構的物件清單」這種常見的資料形狀，比單純用 array 或 object 精確很多，這也是 PropTypes 執行期驗證能做到的合理深度。不過這組驗證會不會真的生效，取決於 UserList 是什麼類型的元件：React 19 之後，propTypes 對『函式元件』已經完全失效（no-op，不管開發或正式環境都不會檢查、也不會警告），只有 class component 仍保留這個檢查機制；如果 UserList 是目前最常見的函式元件寫法，建議改用 TypeScript 或其他執行期驗證方案來檢查這些欄位型別。",
+      "verify": { "checks": [], "manual": "PropTypes 未安裝於本專案，巢狀驗證邏輯需要真實套件執行才能觀察，無法用 node 直接驗證。" }
+    },
+    {
+      "id": "ri-15-q5",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "依條件動態組合 className 字串",
+      "docs": "",
+      "story": "",
+      "prompt": "一個按鈕在 isActive 為 true 時要多加一個 active 樣式類別。下面這樣寫，isActive=true 時最終的 className 會是什麼？",
+      "code": "function Tab({ isActive, label }) {\n  const className = \"tab\" + (isActive ? \" tab-active\" : \"\");\n  return <button className={className}>{label}</button>;\n}\n\nconsole.log(renderToStaticMarkup(<Tab isActive={true} label=\"首頁\" />));",
+      "options": [
+        { "id": "a", "text": "<button class=\"tab tab-active\">首頁</button>：用字串拼接（或模板字串）搭配三元運算子，依 isActive 的值決定要不要附加額外的 class 名稱，是條件式套用 CSS 類別最直接的手法；專案規模變大、條件變多時，通常會改用 classnames／clsx 這類小工具函式庫來組合多個條件類別，避免手動字串拼接容易漏掉空格或打錯字" },
+        { "id": "b", "text": "<button class=\"tab\">首頁</button>，三元運算子在 JSX 屬性值計算時不會生效" },
+        { "id": "c", "text": "<button class=\"tabtab-active\">首頁</button>，字串拼接會漏掉必要的空格" },
+        { "id": "d", "text": "程式會拋出例外，className 屬性不能用字串拼接的方式組合" }
+      ],
+      "answer": "a",
+      "explanation": "className 屬性本質上只是一個普通的字串，任何能算出字串的 JavaScript 表達式（拼接、模板字串、三元運算子）都能用來動態組合它。這裡刻意在 \" tab-active\" 前面留了空格，是因為多個 CSS class 名稱之間需要空格分隔——這種手動處理空格的細節，正是後來 classnames／clsx 這類工具函式庫想幫忙簡化掉的部分。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Tab({ isActive, label }) {\n  const className = \"tab\" + (isActive ? \" tab-active\" : \"\");\n  return <button className={className}>{label}</button>;\n}\nconsole.log(renderToStaticMarkup(<Tab isActive={true} label=\"首頁\" />));", "expected": "<button class=\"tab tab-active\">首頁</button>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-15-q6",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "React（核心概念）與 ReactDOM（渲染到瀏覽器）是兩個獨立套件",
+      "docs": "",
+      "story": "",
+      "prompt": "一個新專案的 package.json 裡，react 跟 react-dom 是各自獨立列出、各自發布版號的兩個依賴套件。這兩者的版本可以隨意混搭嗎？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "不行：react 套件包含元件、Hooks、Context 這些核心、平台無關的概念；react-dom 是專門負責『把這些概念渲染到瀏覽器 DOM』的橋接套件，兩者雖然是分開發布、各自有獨立版號的套件（前面 ri-13 章節已詳細解釋過這個架構分離的理由），但彼此的版本必須保持相容／對齊——官方慣例是兩者同步發布、大版號一致（例如 react 19.x 搭配 react-dom 19.x），版本落差太大（尤其是主版號不同，例如 react 19 的 Hooks 搭配 react-dom 18，或反過來）可能導致執行期錯誤或行為不一致；這也是為什麼 React Native 專案裡看不到 react-dom，而是改用 react-native 這個對應原生渲染目標的套件" },
+        { "id": "b", "text": "react 與 react-dom 其實是同一個套件，只是分別發布了兩份一模一樣的程式碼" },
+        { "id": "c", "text": "react-dom 是給後端 Node.js 伺服器用的套件，跟瀏覽器渲染完全無關" },
+        { "id": "d", "text": "只有其中一個套件是必要依賴，另一個可以隨意移除而不影響任何功能" }
+      ],
+      "answer": "a",
+      "explanation": "這題呼應前面 ri-13 章節談過的架構分離：react 是核心、react-dom／react-native／react-test-renderer 是各自對應不同渲染目標的橋接層。不過『分開發布』不等於『版本可以隨便搭配』：react 與 react-dom 雖然是各自獨立發布、各有版號的套件，但必須使用彼此相容的版本，官方慣例是兩者的大版號保持一致、同步發布，不是『大致相容就好』這種寬鬆關係。",
+      "verify": { "checks": [], "manual": "屬套件架構與版本管理慣例的說明題，無可執行程式碼。" }
+    },
+    {
+      "id": "ri-15-q7",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "label 元素要用 htmlFor 而不是 for（for 是 JS 保留字延伸出的慣例）",
+      "docs": "https://react.dev/reference/react-dom/components/common",
+      "story": "",
+      "prompt": "想讓 <label> 跟某個 <input> 建立關聯（點擊文字就能聚焦到輸入框），原生 HTML 用 for 屬性，React 裡該怎麼寫？",
+      "code": "function Field() {\n  return (\n    <div>\n      <label htmlFor=\"email\">電子郵件</label>\n      <input id=\"email\" />\n    </div>\n  );\n}\n\nconsole.log(renderToStaticMarkup(<Field />));",
+      "options": [
+        { "id": "a", "text": "用 htmlFor 而不是 for：這跟 className／class 的理由完全一樣——for 在 JavaScript 裡是保留字（for 迴圈），JSX 的屬性名稱最終要對應成 JavaScript 物件的 key，為了避免關鍵字衝突，React 選擇用 htmlFor 這個不會衝突的替代名稱，渲染到最終 HTML 時才轉換回瀏覽器認得的 for 屬性" },
+        { "id": "b", "text": "直接寫 for=\"email\" 就能正常運作，React 對這個屬性沒有特殊處理" },
+        { "id": "c", "text": "label 元素在 React 裡完全不支援與 input 建立關聯" },
+        { "id": "d", "text": "htmlFor 屬性只在 TypeScript 專案裡有效，一般 JavaScript 專案要用 for" }
+      ],
+      "answer": "a",
+      "explanation": "className／htmlFor 是同一類問題的兩個具體案例：HTML 原生屬性名稱剛好撞上 JavaScript 語言保留字（class、for），JSX 因此統一改用不會衝突的替代名稱，渲染到最終 HTML 時再轉換回瀏覽器認得的屬性名稱。這組轉換規則值得記住，因為它們是最容易在剛接觸 JSX 時，因為沿用原生 HTML 屬性名稱直覺而寫錯的地方。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Field() {\n  return (\n    <div>\n      <label htmlFor=\"email\">電子郵件</label>\n      <input id=\"email\" />\n    </div>\n  );\n}\nconsole.log(renderToStaticMarkup(<Field />));", "expected": "<div><label for=\"email\">電子郵件</label><input id=\"email\"/></div>" }
+        ]
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-16-core-styling-tools.json b/packages/core/src/data/questions/ri-16-core-styling-tools.json
new file mode 100644
index 0000000..25dcccd
--- /dev/null
+++ b/packages/core/src/data/questions/ri-16-core-styling-tools.json
@@ -0,0 +1,132 @@
+{
+  "id": "ri-16",
+  "title": "Core React：樣式與實用小工具",
+  "questions": [
+    {
+      "id": "ri-16-q1",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "合併多個行內樣式物件：用展開運算子疊加，後面的覆蓋前面的",
+      "docs": "https://react.dev/reference/react-dom/components/common#the-style-prop",
+      "story": "",
+      "prompt": "一個按鈕要疊加「基礎樣式」跟「依 isDanger 決定的樣式」兩組行內樣式物件。下面這樣合併，isDanger=true 時最終的 style 屬性會是什麼？",
+      "code": "const baseStyle = { padding: 8, borderRadius: 4 };\nconst dangerStyle = { backgroundColor: \"red\", borderRadius: 0 };\n\nfunction DangerButton({ isDanger }) {\n  const style = { ...baseStyle, ...(isDanger ? dangerStyle : {}) };\n  return <button style={style}>刪除</button>;\n}\n\nconsole.log(renderToStaticMarkup(<DangerButton isDanger={true} />));",
+      "options": [
+        { "id": "a", "text": "<button style=\"padding:8px;border-radius:0;background-color:red\">刪除</button>：用展開運算子把多個樣式物件依序疊加成一個新物件，後面展開的物件裡如果有跟前面同名的 key（這裡是 borderRadius），會覆蓋掉前面的值；沒有重複的 key（如 padding、backgroundColor）則各自保留，這是合併多組樣式最常見、也最直覺的手法" },
+        { "id": "b", "text": "borderRadius 會同時保留兩個值，最終渲染出 border-radius:4px;0px 這種不合法的 CSS" },
+        { "id": "c", "text": "程式會拋出例外，同一個物件裡不能對同一個 key 展開兩次不同的值" },
+        { "id": "d", "text": "後面展開的 dangerStyle 完全不會生效，物件合併永遠以第一次展開的值為準" }
+      ],
+      "answer": "a",
+      "explanation": "這是 JavaScript 物件展開運算子本身的行為，不是 React 特有的規則：{ ...a, ...b } 依序把 a、b 的屬性複製到新物件上，b 裡跟 a 重複的 key 會覆蓋掉 a 的值——「後面的贏」。這個規則讓「基礎樣式 + 條件覆蓋樣式」這種疊加模式寫起來很直覺，也是很多 UI 元件庫內部合併使用者傳入樣式與元件預設樣式的常見手法。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nconst baseStyle = { padding: 8, borderRadius: 4 };\nconst dangerStyle = { backgroundColor: \"red\", borderRadius: 0 };\nfunction DangerButton({ isDanger }) {\n  const style = { ...baseStyle, ...(isDanger ? dangerStyle : {}) };\n  return <button style={style}>刪除</button>;\n}\nconsole.log(renderToStaticMarkup(<DangerButton isDanger={true} />));", "expected": "<button style=\"padding:8px;border-radius:0;background-color:red\">刪除</button>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-16-q2",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "監聽瀏覽器視窗尺寸變化，要在 useEffect 裡訂閱／清理 resize 事件",
+      "docs": "",
+      "story": "",
+      "prompt": "想讓一個元件依「目前瀏覽器視窗寬度」決定要顯示手機版還是桌面版排版，寬度隨使用者拖曳視窗即時變化時，畫面也要跟著切換。該怎麼設計？",
+      "code": "function ResponsiveLayout() {\n  const [width, setWidth] = useState(window.innerWidth);\n\n  useEffect(() => {\n    function handleResize() {\n      setWidth(window.innerWidth);\n    }\n    window.addEventListener(\"resize\", handleResize);\n    return () => window.removeEventListener(\"resize\", handleResize);\n  }, []);\n\n  return width < 768 ? <MobileLayout /> : <DesktopLayout />;\n}",
+      "options": [
+        { "id": "a", "text": "在 useEffect 裡訂閱瀏覽器原生的 resize 事件，事件觸發時呼叫 setWidth 更新 state，state 變了自然觸發重繪、重新判斷該顯示哪種排版；useEffect 的清理函式（return 的那個函式）裡要記得呼叫 removeEventListener，在元件卸載時解除訂閱，否則元件即使已經從畫面上消失，這個事件監聽器仍然殘留在記憶體裡持續執行，造成記憶體洩漏" },
+        { "id": "b", "text": "React 會自動監聽視窗尺寸變化，不需要手動訂閱任何事件" },
+        { "id": "c", "text": "resize 事件只能在 class component 的 componentDidMount 裡訂閱，函式元件無法達到同樣效果" },
+        { "id": "d", "text": "不需要清理函式，React 會在元件卸載時自動移除所有透過 addEventListener 註冊的監聽器" }
+      ],
+      "answer": "a",
+      "explanation": "瀏覽器原生事件（resize、scroll 等）不是 React 事件系統的一部分，需要自己用 addEventListener 訂閱；useEffect 的清理函式正是為了讓這類「訂閱外部資源」的操作在元件卸載時能對應解除，React 不會自動幫你清理透過原生 API 註冊的監聽器，忘記寫清理函式是很常見、也很容易被忽略的記憶體洩漏來源。",
+      "verify": { "checks": [], "manual": "resize 事件與視窗尺寸變化需要真實瀏覽器環境才能觸發與觀察，無法用 node 直接驗證。" }
+    },
+    {
+      "id": "ri-16-q3",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "在 JSX 裡顯示格式化過的 JSON，用 JSON.stringify 搭配縮排參數",
+      "docs": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify",
+      "story": "",
+      "prompt": "除錯時想在畫面上顯示一個物件的完整內容、並且帶有縮排方便閱讀（而不是擠成一行）。下面這樣寫，畫面上 <pre> 裡會顯示什麼？",
+      "code": "function DebugPanel({ data }) {\n  return <pre>{JSON.stringify(data, null, 2)}</pre>;\n}\n\nconsole.log(JSON.stringify({ name: \"Amy\", age: 20 }, null, 2));",
+      "options": [
+        { "id": "a", "text": "JSON.stringify(value, replacer, space) 的第三個參數 space 傳入數字時，代表每一層縮排要用幾個空格；這裡傳 2，代表輸出的 JSON 字串每加深一層巢狀結構就多縮排兩格，並在每個欄位之間換行，比預設擠成一行的輸出更適合人眼閱讀——這是原生 JavaScript API 本來就有的功能，不需要額外套件；搭配 <pre> 標籤顯示，是因為 <pre> 會保留字串裡的換行與空格，一般文字標籤會把這些空白字元擠掉" },
+        { "id": "b", "text": "JSON.stringify 只能輸出擠在一行的字串，沒有任何格式化縮排的選項" },
+        { "id": "c", "text": "第三個參數 2 代表『只顯示物件的前兩個欄位』，其餘欄位會被省略" },
+        { "id": "d", "text": "這段程式碼會拋出例外，JSON.stringify 最多只能接受兩個參數" }
+      ],
+      "answer": "a",
+      "explanation": "JSON.stringify 的第三個參數（space）是原生 API 內建的縮排格式化選項，可以是數字（代表空格數）或字串（例如 \"\\t\" 代表用 tab 縮排）。這在除錯面板、印出 API 回應內容這類場景很常用；搭配 <pre> 標籤是因為一般的 HTML 標籤會把連續空白與換行收合成一個空格，只有 <pre> 會照原樣保留這些格式，兩者合起來才能真正顯示出『看起來有縮排』的 JSON。",
+      "verify": {
+        "checks": [
+          { "code": "console.log(JSON.stringify({ name: \"Amy\", age: 20 }, null, 2));", "expected": "{\n  \"name\": \"Amy\",\n  \"age\": 20\n}" }
+        ]
+      }
+    },
+    {
+      "id": "ri-16-q4",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "props 唯讀是刻意設計，不是限制，想改要透過父層",
+      "docs": "",
+      "story": "",
+      "prompt": "新人想在 Greeting 元件內部直接執行 props.name = \"新名字\" 來改變顯示內容，發現完全沒有作用（甚至嚴格模式下會報錯）。這是 React 的限制還是刻意設計？",
+      "code": "function Greeting(props) {\n  props.name = \"新名字\"; // 嘗試直接修改 prop\n  return <p>{props.name}</p>;\n}",
+      "options": [
+        { "id": "a", "text": "這是刻意設計：props 被設計成『唯讀』，接收 props 的元件不能直接修改它——這個限制讓資料流向保持單向、可預測（一份資料永遠能追溯到某個明確的來源往下傳），如果任何子元件都能隨意回頭改動父層傳下來的資料，追蹤『這個值到底被誰改的』會變得跟前面 ri-4 章節談過的 MVW 雙向綁定困境一樣難以除錯；真的需要改變顯示內容，該做的是讓父層透過重新渲染傳入新的 props 值，或者這份資料本來就該是這個元件自己的 state" },
+        { "id": "b", "text": "這是 React 目前版本的技術限制，未來版本預計會開放讓子元件直接修改 props" },
+        { "id": "c", "text": "props.name = ... 這種寫法其實有效，只是需要呼叫一個額外的 forceUpdate 才能反映到畫面上" },
+        { "id": "d", "text": "只有函式元件不能修改 props，class component 可以直接修改 this.props" }
+      ],
+      "answer": "a",
+      "explanation": "props 唯讀不是技術限制而是刻意的架構設計，目的是維持單向資料流的可預測性——這跟 state（元件自己能改的部分）恰好形成互補的一組規則（呼應 ri-9 章節談過的 state vs props 區分）。想讓畫面因為某個操作而改變，正確的路徑永遠是「觸發 state 更新」或「請父層重新傳入新的 props」，不存在讓子元件直接回頭修改 props 的合法方式，class component 也不例外。",
+      "verify": { "checks": [], "manual": "props 唯讀限制屬 React 架構設計原則，直接修改在嚴格模式下的行為需要真實開發環境觀察警告，此處著重原理說明。" }
+    },
+    {
+      "id": "ri-16-q5",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "頁面載入後自動聚焦輸入框：用 ref 搭配 useEffect",
+      "docs": "",
+      "story": "",
+      "prompt": "想讓搜尋頁一打開，輸入框就自動聚焦、游標閃爍等待使用者輸入，不用使用者自己點一下。該怎麼設計？",
+      "code": "function SearchPage() {\n  const inputRef = useRef(null);\n\n  useEffect(() => {\n    inputRef.current.focus();\n  }, []);\n\n  return <input ref={inputRef} placeholder=\"搜尋...\" />;\n}",
+      "options": [
+        { "id": "a", "text": "用 ref 抓到這個 input 的真實 DOM 節點，在 useEffect（依賴陣列給空陣列，代表只在元件掛載後執行一次）裡呼叫 inputRef.current.focus()；這正是既有 react-11 章節談過的『ref 抓 DOM 節點』三大正當用途之一（聚焦、捲動、量尺寸），而且必須放在 useEffect 裡而不是渲染過程中直接呼叫，因為渲染當下 DOM 節點可能還沒真正掛載完成，current 可能還是 null" },
+        { "id": "b", "text": "直接在元件函式的最上層呼叫 inputRef.current.focus()，不需要包在 useEffect 裡" },
+        { "id": "c", "text": "React 元件掛載時會自動聚焦第一個 input 元素，不需要任何額外程式碼" },
+        { "id": "d", "text": "只能用 autoFocus 這個 HTML 原生屬性達成，ref 搭配 useEffect 的寫法完全無效" }
+      ],
+      "answer": "a",
+      "explanation": "這題呼應既有 react-11 章節對「渲染途中 ref.current 還是 null」的討論：DOM 節點要等到 commit 階段真正掛載完成才存在，useEffect 保證在那之後才執行，是呼叫 .focus() 安全的時間點。值得補充的是，HTML 原生也有 autoFocus 屬性可以達到類似效果（選項 d 提到的），兩者並非互斥，但 ref+useEffect 的寫法在需要更複雜的聚焦邏輯（例如依條件決定要不要聚焦）時更有彈性。",
+      "verify": { "checks": [], "manual": "焦點狀態需要真實瀏覽器 DOM 與使用者可視互動才能觀察，無法用 node -e 或 renderToStaticMarkup 驗證（伺服器端渲染沒有真實焦點概念）。" }
+    },
+    {
+      "id": "ri-16-q6",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "在瀏覽器 console 查詢目前執行的 React 版本",
+      "docs": "https://react.dev/reference/react/version",
+      "story": "",
+      "prompt": "想確認目前執行環境載入的是哪一個版本的 React（排查『某個新 API 在這個版本能不能用』這類問題時很常見），該怎麼查？",
+      "code": "console.log(React.version);",
+      "options": [
+        { "id": "a", "text": "React 套件本身匯出一個 version 屬性（字串，例如 \"19.2.0\"），直接 console.log(React.version) 就能在瀏覽器開發者工具的 Console 面板裡看到目前實際載入的版本號；這在排查『某個 Hook 或 API 是不是這個版本還沒支援』這類問題時，是最直接的第一步" },
+        { "id": "b", "text": "React 套件沒有提供任何查詢版本號的方式，只能去看 package.json 或 node_modules 資料夾裡的檔案" },
+        { "id": "c", "text": "只能透過 React DevTools 擴充功能查詢版本，React 套件本身完全不暴露這項資訊" },
+        { "id": "d", "text": "React.version 只在開發模式建置下才存在，正式環境的生產模式建置會把這個屬性移除" }
+      ],
+      "answer": "a",
+      "explanation": "React.version 是套件本身暴露的一個簡單字串屬性，任何載入了 react 套件的執行環境（瀏覽器 console、Node.js 腳本）都能直接讀取，是排查版本相關問題最快速的方式，不需要額外安裝任何工具、也不受開發/生產模式影響。",
+      "verify": {
+        "checks": [
+          { "jsx": "import React from 'react'\nconsole.log(typeof React.version)", "expected": "string" }
+        ]
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-17-core-project-conventions.json b/packages/core/src/data/questions/ri-17-core-project-conventions.json
new file mode 100644
index 0000000..ebcd8dd
--- /dev/null
+++ b/packages/core/src/data/questions/ri-17-core-project-conventions.json
@@ -0,0 +1,189 @@
+{
+  "id": "ri-17",
+  "title": "Core React：專案慣例與工具鏈",
+  "questions": [
+    {
+      "id": "ri-17-q1",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "SPA 導頁不會觸發整頁重新整理，Google Analytics 需要手動補送 pageview",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊在 React Router 的 SPA 上裝了 Google Analytics，卻發現使用者切換頁面時，Analytics 後台完全沒有記錄到新的 pageview。已知 GA 傳統上是靠偵測『整頁重新整理』來記錄頁面瀏覽。問題出在哪？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "SPA 的路由切換（React Router 的 navigate／Link 點擊）不會觸發瀏覽器真正的整頁重新整理，只是在同一份頁面裡換掉畫面內容，GA 傳統的自動偵測機制因此完全不會觸發；解法是監聽路由變化的事件（例如 React Router 的 useLocation 搭配 useEffect），每次路徑變動時手動呼叫 GA 的 pageview 追蹤方法，主動告訴 GA『使用者換頁了』" },
+        { "id": "b", "text": "Google Analytics 從技術上完全無法搭配任何 SPA 框架使用，只能用在傳統多頁面網站" },
+        { "id": "c", "text": "問題出在 React Router 的版本太舊，升級到最新版就會自動修正這個問題" },
+        { "id": "d", "text": "GA 的追蹤碼安裝位置錯誤，應該裝在每個元件內部而不是最外層" }
+      ],
+      "answer": "a",
+      "explanation": "這是所有分析工具在 SPA 環境都會遇到的共同課題：傳統網頁分析工具假設『換頁＝整頁重新整理＝一次新的 HTTP 請求』，SPA 打破了這個假設。解法的通用模式都一樣——在路由函式庫提供的『路徑變化』事件裡，主動呼叫分析工具的追蹤方法，這是開發者要自己補上的一段整合邏輯，不是框架版本問題。",
+      "verify": { "checks": [], "manual": "Google Analytics 整合與 SPA 路由事件需要真實瀏覽器環境與外部服務才能觀察，無法用 node 直接驗證。" }
+    },
+    {
+      "id": "ri-17-q2",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "行內樣式的 vendor prefix 要自己以物件多個 key 的形式列出",
+      "docs": "",
+      "story": "",
+      "prompt": "想在行內樣式裡用 CSS transform，並確保在舊版瀏覽器上也生效（部分舊版瀏覽器需要 -webkit-transform 這類帶廠商前綴的寫法）。React 的 style 物件該怎麼寫？",
+      "code": "const style = {\n  WebkitTransform: \"rotate(45deg)\",\n  MozTransform: \"rotate(45deg)\",\n  transform: \"rotate(45deg)\",\n};",
+      "options": [
+        { "id": "a", "text": "React 本身不會自動幫行內樣式加上 vendor prefix，需要開發者自己在物件裡手動列出每個廠商前綴版本的 key（駝峰式，且廠商前綴的第一個字母要大寫，如 WebkitTransform、MozTransform），這些額外的 key 最終都會被轉換成對應的帶前綴 CSS 屬性；實務上更常見的做法是改用 autoprefixer 這類建置工具，在 CSS 檔案層級自動處理前綴，而不是在每一段行內樣式手動列舉" },
+        { "id": "b", "text": "React 會自動偵測使用者的瀏覽器，自動幫所有行內樣式加上必要的廠商前綴，不需要手動列出" },
+        { "id": "c", "text": "行內樣式完全不支援任何形式的 vendor prefix，必須全部改成外部 CSS 檔案才能加前綴" },
+        { "id": "d", "text": "vendor prefix 只能用小寫開頭寫法，如 webkitTransform，大寫開頭會被視為不合法屬性" }
+      ],
+      "answer": "a",
+      "explanation": "React 的 style 物件是純粹的資料傳遞，不含任何『自動幫你判斷瀏覽器該加哪個前綴』的邏輯，這件事完全依賴開發者自己處理，或交給建置工具（如 PostCSS 的 autoprefixer）在 CSS 層級自動化。行內樣式手動列舉多組前綴的寫法能動，但維護成本高，這也是實務上大型專案傾向把樣式移出行內、改用有 autoprefixer 支援的 CSS 方案的原因之一。",
+      "verify": { "checks": [], "manual": "vendor prefix 在不同瀏覽器上的實際生效情況需要真實瀏覽器環境測試才能驗證，無法用 node 直接驗證。" }
+    },
+    {
+      "id": "ri-17-q3",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "元件用 ES6 模組的 export/import 匯出匯入，預設匯出與具名匯出可以並存",
+      "docs": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export",
+      "story": "",
+      "prompt": "一個檔案裡同時用 export default 匯出主要元件，也用具名 export 匯出一個輔助函式。這兩種匯出方式在同一個檔案裡可以並存嗎？呼叫端該怎麼分別匯入？",
+      "code": "// Button.js\nexport function formatLabel(text) {\n  return text.toUpperCase();\n}\nexport default function Button({ label }) {\n  return `[${formatLabel(label)}]`;\n}\n\n// 呼叫端\nimport Button, { formatLabel } from \"./Button\";\nconsole.log(Button({ label: \"送出\" }));\nconsole.log(formatLabel(\"hi\"));",
+      "options": [
+        { "id": "a", "text": "可以並存：一個模組可以有『最多一個』default export，同時搭配任意數量的具名 export；匯入端用 import 預設變數名稱, { 具名成員 } from \"...\" 這種語法同時取用兩者——這在 React 元件檔案裡很常見，主要元件用 default 匯出，一些輔助函式、型別、常數用具名匯出" },
+        { "id": "b", "text": "不行，一個模組檔案裡只能選擇 export default 或具名 export 其中一種，不能同時使用" },
+        { "id": "c", "text": "可以並存，但匯入時必須分別寫成兩個獨立的 import 陳述式，不能寫在同一行" },
+        { "id": "d", "text": "可以並存，但具名匯出的函式在匯入端必須加上 default 前綴才能使用" }
+      ],
+      "answer": "a",
+      "explanation": "ES6 模組系統的匯出限制只有一條：一個模組最多一個 default export，但具名 export 可以有任意多個，兩者完全可以同時出現在同一個檔案、同一行 import 陳述式裡取用。這在元件庫、工具函式庫裡很常見的組織方式，讓使用者可以簡短地匯入主要元件（不用打完整名稱），同時視需要額外匯入輔助工具。",
+      "verify": {
+        "checks": [
+          { "code": "function formatLabel(text) {\n  return text.toUpperCase();\n}\nfunction Button({ label }) {\n  return `[${formatLabel(label)}]`;\n}\nconsole.log(Button({ label: \"go\" }));\nconsole.log(formatLabel(\"hi\"));", "expected": "[GO]\nHI" }
+        ]
+      }
+    },
+    {
+      "id": "ri-17-q4",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "元件命名的例外情境：動態決定元件時，變數名稱一樣要大寫開頭",
+      "docs": "",
+      "story": "",
+      "prompt": "已經知道元件名稱必須大寫開頭，JSX 才會把它當成元件而不是原生標籤（見前面 ri-14 章節）。如果元件是「動態決定」的（例如從一個物件裡取出來的），存放它的變數名稱該怎麼命名？",
+      "code": "const components = { info: InfoIcon, warning: WarningIcon };\n\nfunction Notice({ type }) {\n  const SelectedIcon = components[type]; // 變數名稱刻意大寫開頭\n  return <SelectedIcon />;\n}",
+      "options": [
+        { "id": "a", "text": "即使元件是動態取出來的（存在一個變數裡，不是直接寫死的元件名稱），這個變數的名稱本身仍然要大寫開頭（如 SelectedIcon），JSX 才會把 <SelectedIcon /> 當成『查找這個變數目前的值、當成元件呼叫』，而不是誤判成一個叫 selectedIcon 的原生 HTML 標籤——JSX 判斷『是元件還是原生標籤』的規則，只看標籤名稱的第一個字母大小寫，不管這個名稱背後是不是動態決定的" },
+        { "id": "b", "text": "動態決定的元件屬於例外情況，變數名稱不需要遵守大寫開頭的規則" },
+        { "id": "c", "text": "只有直接寫死在程式碼裡的元件名稱需要大寫開頭，透過變數存放的元件不受這條規則限制" },
+        { "id": "d", "text": "動態決定元件時必須改用字串型別的元件名稱，而不是變數參考" }
+      ],
+      "answer": "a",
+      "explanation": "這是「元件命名例外」裡常被問到的一個細節：規則本身沒有例外（永遠是看標籤名稱第一個字母的大小寫），例外的是「元件不一定要直接寫死名稱，也可以是一個變數，只要這個變數本身取名時遵守大寫開頭」。這也是前面 ri-14 章節「switching component」模式能正常運作的語法前提——對照表裡取出來的元件，賦值給一個大寫開頭的變數，JSX 才會正確辨識。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction InfoIcon() { return <span>i</span>; }\nfunction WarningIcon() { return <span>!</span>; }\nconst components = { info: InfoIcon, warning: WarningIcon };\nfunction Notice({ type }) {\n  const SelectedIcon = components[type];\n  return <SelectedIcon />;\n}\nconsole.log(renderToStaticMarkup(<Notice type=\"warning\" />));", "expected": "<span>!</span>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-17-q5",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "React 元件裡可以自由使用 async/await，只要不是元件函式本身宣告成 async",
+      "docs": "",
+      "story": "",
+      "prompt": "想在事件處理器裡用 async/await 處理非同步的表單送出邏輯。元件函式（渲染函式）本身能不能宣告成 async？",
+      "code": "function Form() {\n  // 事件處理器裡用 async/await：完全合法\n  async function handleSubmit() {\n    const res = await fetch(\"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/api/submit\");\n    console.log(await res.json());\n  }\n  return <button onClick={handleSubmit}>送出</button>;\n}\n\n// 元件函式本身宣告成 async：不合法的用法\n// async function BrokenComponent() {\n//   const data = await fetch(\"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/api/data\");\n//   return <p>{data}</p>;\n// }",
+      "options": [
+        { "id": "a", "text": "事件處理器、自訂 Hook 內部的邏輯函式都能自由使用 async/await，這只是普通的 JavaScript 語法，跟 React 沒有特殊衝突；但元件函式（渲染函式）本身不能宣告成 async——React 預期呼叫元件函式會『同步』立刻拿到一個 React element（或 null）當回傳值，一個 async 函式呼叫後拿到的永遠是一個 Promise 物件，不是 React 認得的 element，會導致渲染出錯或顯示不出預期內容" },
+        { "id": "b", "text": "元件函式本身也可以宣告成 async，React 會自動 await 它的回傳值再渲染" },
+        { "id": "c", "text": "React 元件完全不能使用 async/await，只能用 .then() 鏈式呼叫處理非同步邏輯" },
+        { "id": "d", "text": "async/await 只能在 class component 的生命週期方法裡使用，函式元件完全不支援" }
+      ],
+      "answer": "a",
+      "explanation": "這裡的關鍵是分清楚「元件函式本身」跟「元件內部定義、被事件觸發呼叫的其他函式」：後者只是普通函式，可以自由用 async/await；前者的呼叫方式（渲染時同步呼叫、期待立即拿到 element）跟 async 函式『永遠回傳 Promise』這個特性衝突，這也是為什麼 React 元件不能直接宣告成 async function 的根本原因（React Server Components 是特例，那是完全不同的執行模型）。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Form() {\n  async function handleSubmit() {\n    console.log(\"submitted\");\n  }\n  return <button onClick={handleSubmit}>送出</button>;\n}\nconsole.log(renderToStaticMarkup(<Form />));", "expected": "<button>送出</button>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-17-q6",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "常見的 React 專案資料夾結構：依功能還是依型別分類",
+      "docs": "",
+      "story": "",
+      "prompt": "新專案要決定資料夾結構，「依型別分類」（所有元件放 components/、所有 hooks 放 hooks/、所有工具函式放 utils/）跟「依功能分類」（每個功能一個資料夾，內含自己的元件、hooks、工具函式），該怎麼選？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "沒有絕對正確答案，取決於專案規模：小型專案或元件數量不多時，依型別分類容易一眼掌握『所有 hooks 在哪裡』；專案變大、功能模組增加時，依功能分類讓『改一個功能只需要在一個資料夾內找檔案』，減少『改一個功能要在五個型別資料夾裡各自找一個檔案』的跳轉成本——這跟前面 ri-4 章節談過 Redux 專案資料夾規劃的取捨是同一個道理，只是應用範圍從 Redux 相關檔案擴大到整個專案" },
+        { "id": "b", "text": "React 官方強制規定只能用依型別分類這一種資料夾結構，其他結構都不合法" },
+        { "id": "c", "text": "依功能分類的專案完全不能使用 TypeScript" },
+        { "id": "d", "text": "資料夾結構對專案的可維護性沒有任何實質影響，選哪種都一樣" }
+      ],
+      "answer": "a",
+      "explanation": "React 官方文件明確表示不會強制規定資料夾結構，這是留給團隊依專案規模自行決定的取捨。這個決策模式跟 ri-4 章節談過的 Redux 資料夾組織原則一致：小規模時「依型別」直覺、好找；規模變大時「依功能」讓修改一個功能的檔案跳轉成本更低，這是可以隨專案演進而調整的架構決策，不是一次性的硬性規定。",
+      "verify": { "checks": [], "manual": "屬專案架構規劃的推理題，無可執行程式碼。" }
+    },
+    {
+      "id": "ri-17-q7",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "React 生態裡常見的動畫函式庫：各自解決的場景不同",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊想幫元件的進場、離場加上動畫效果（例如清單項目刪除時淡出，而不是瞬間消失）。純手寫 CSS transition 在「元素從 DOM 移除的瞬間」會遇到什麼困難，動畫函式庫（如 React Transition Group、Framer Motion）想解決的正是這個問題？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "純 CSS transition 沒辦法在『元素真的要被移除』跟『離場動畫播放完畢』之間爭取到時間差——React 一旦決定移除某個節點，會立刻把它從 DOM 拿掉，CSS transition 的動畫還沒播完就被打斷；動畫函式庫的核心價值就是介入這個時機，讓 React『延後』真正移除 DOM 節點的時間點，等離場動畫確實播放完成後才真正卸載，同時也提供進場動畫的生命週期掛鉤" },
+        { "id": "b", "text": "純 CSS transition 完全沒辦法用在 React 專案裡，必須改用動畫函式庫才能使用任何 CSS 動畫" },
+        { "id": "c", "text": "動畫函式庫的唯一功能是取代 CSS，讓開發者不用再寫任何樣式" },
+        { "id": "d", "text": "React 内建了完整的動畫系統，不需要任何第三方動畫函式庫" }
+      ],
+      "answer": "a",
+      "explanation": "「進場動畫」相對容易（元素已經在 DOM 裡，用 CSS transition 配合一個觸發 class 切換即可）；「離場動畫」的困難點在於元素被移除的時機完全由 React 的渲染邏輯決定，純 CSS 沒有能力介入、延後這個時機。動畫函式庫的核心工作正是提供一層「延後卸載、等動畫播完再真正移除」的協調機制，這是它們相對純 CSS 動畫真正補上的能力缺口。",
+      "verify": { "checks": [], "manual": "動畫函式庫的離場動畫時機協調需要真實瀏覽器渲染與過場觀察才能驗證，無法用 node 直接驗證。" }
+    },
+    {
+      "id": "ri-17-q8",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "CSS Modules／樣式模組：讓類別名稱自動加上唯一雜湊，避免全域命名衝突",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊裡兩個不同元件都各自定義了一個叫 .title 的 CSS class，樣式互相覆蓋、打架。改用 CSS Modules（檔名 Button.module.css）之後，這個衝突怎麼被解決？",
+      "code": "/* Button.module.css */\n.title { color: blue; }\n\n// Button.jsx\nimport styles from \"./Button.module.css\";\nfunction Button() {\n  return <span className={styles.title}>按鈕標題</span>;\n}",
+      "options": [
+        { "id": "a", "text": "CSS Modules 在建置階段會把每個檔案裡的 class 名稱，自動轉換成帶有這個檔案專屬雜湊值的唯一名稱（例如 .title 變成 .Button_title__a1b2c），import 進來的 styles 物件裡的 styles.title 對應到的就是這個轉換後的唯一名稱；不同檔案各自定義的 .title 因為雜湊值不同，最終產生的實際 class 名稱不會撞名，天生解決了全域 CSS 命名空間衝突的問題，不需要開發者自己手動想辦法命名避免衝突（如 BEM 命名法那樣）" },
+        { "id": "b", "text": "CSS Modules 只是把多個 .css 檔案合併成一個檔案，不會對 class 名稱做任何轉換" },
+        { "id": "c", "text": "CSS Modules 要求所有元件共用同一份全域樣式表，跟一般 CSS 檔案完全沒有差異" },
+        { "id": "d", "text": "使用 CSS Modules 之後，就不能再使用 className 屬性，必須改用 style 屬性" }
+      ],
+      "answer": "a",
+      "explanation": "CSS Modules 解決的正是「全域 CSS 命名空間只有一個，大型專案裡類別名稱很容易撞名」這個老問題，做法是建置階段自動幫每個檔案的類別名稱加上唯一識別後綴，讓『樣式作用域局限在這個檔案』的效果，不需要開發者自己手動用命名慣例（如 BEM）去人工避免撞名，這也是它被稱為「模組」的原因——樣式像 JS 模組一樣有各自獨立的作用域。",
+      "verify": { "checks": [], "manual": "CSS Modules 的類別名稱雜湊轉換需要真實建置工具鏈（webpack/Vite 等）處理，無法用 node 直接驗證。" }
+    },
+    {
+      "id": "ri-17-q9",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "React 專屬 linter：eslint-plugin-react 與 eslint-plugin-react-hooks",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊的 ESLint 設定裡加了 eslint-plugin-react-hooks 這個外掛，它主要幫忙抓出哪一類容易犯錯、但一般 JavaScript linter 規則抓不到的問題？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "eslint-plugin-react-hooks 專門檢查 Hooks 使用規則有沒有被違反——例如 Hook 是不是被放進了條件式或迴圈裡呼叫（違反 Hooks 呼叫順序必須每次渲染都一致的規則）、useEffect／useCallback 的依賴陣列是不是漏列了實際用到的變數；這些是 Hooks 這套機制特有的陷阱，一般不了解 React 內部運作的通用 JavaScript linter 規則完全沒有能力偵測，需要專屬外掛才抓得出來" },
+        { "id": "b", "text": "eslint-plugin-react-hooks 只負責檢查程式碼縮排與分號等格式問題，跟 Hooks 邏輯無關" },
+        { "id": "c", "text": "eslint-plugin-react-hooks 會自動幫開發者把 class component 全部轉寫成函式元件" },
+        { "id": "d", "text": "eslint-plugin-react-hooks 只在 TypeScript 專案裡才能安裝使用，純 JavaScript 專案不支援" }
+      ],
+      "answer": "a",
+      "explanation": "Hooks 呼叫順序、依賴陣列這兩類錯誤，是 Hooks 機制特有、而且很容易在重構時不小心引入、肉眼審查也未必能立刻發現的陷阱（例如漏列 useEffect 依賴會造成 closure 捕捉到過期的值）。eslint-plugin-react-hooks 這個官方維護的外掛，正是把這些「React 特有的正確性規則」自動化成可以在寫程式碼當下就被 linter 抓出來的檢查項目，是幾乎所有 React 專案的標準配置之一。",
+      "verify": { "checks": [], "manual": "ESLint 規則檢查需要真實 lint 工具鏈執行才能觀察實際抓出的錯誤，無法用 node 直接驗證。" }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-18-misc-early.json b/packages/core/src/data/questions/ri-18-misc-early.json
new file mode 100644
index 0000000..eca884e
--- /dev/null
+++ b/packages/core/src/data/questions/ri-18-misc-early.json
@@ -0,0 +1,185 @@
+{
+  "id": "ri-18",
+  "title": "React 進階探索：Redux 周邊與元件細節",
+  "questions": [
+    {
+      "id": "ri-18-q1",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "Reselect 的核心功能就是記憶化 selector（呼應前面 ri-6 章節）",
+      "docs": "",
+      "story": "",
+      "prompt": "Reselect 函式庫的說明文件把自己定義成「用於計算 Redux 衍生資料的函式庫」。它的核心功能具體是什麼？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "記憶化（memoized）selector：只有輸入真的改變時才重新計算衍生資料，並且能把多個 selector 組合成新的 selector，讓『從 state 算出畫面需要的資料』這件事可以被拆解成小塊、各自快取、彼此組合，避免每次重繪都重複執行昂貴的篩選/排序運算" },
+        { "id": "b", "text": "自動幫應用程式產生完整的 Redux store 設定，不需要手寫任何 reducer" },
+        { "id": "c", "text": "取代 react-redux，讓元件不再需要 useSelector 或 connect()" },
+        { "id": "d", "text": "把 Redux 的 state 自動同步到瀏覽器的 localStorage" }
+      ],
+      "answer": "a",
+      "explanation": "Reselect 專注在「衍生資料的記憶化與組合」這一件事，不涉及 store 設定、不取代 react-redux 的連接機制、也不處理持久化——這些都是其他專責的套件（Redux Toolkit、redux-persist）在做的事，各自職責分明。",
+      "verify": { "checks": [], "manual": "reselect 未安裝於本專案，記憶化行為需要真實套件執行才能觀察，無法用 node 直接驗證。" }
+    },
+    {
+      "id": "ri-18-q2",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "Redux 不綁定 React，可以搭配任何 UI 層甚至純 JS 使用",
+      "docs": "",
+      "story": "",
+      "prompt": "一個純 Node.js 後端服務（沒有任何 UI 畫面）想借用 Redux 的『可預測狀態容器＋action/reducer』模式管理內部狀態機。這樣做技術上可行嗎？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "可行：Redux 核心套件（createStore、reducer、action）跟 React 完全沒有依賴關係，是一個通用的 JavaScript 狀態容器；react-redux 才是專門橋接 Redux 與 React 元件的套件，兩者是分開的。任何 JavaScript 環境（純後端服務、Vue、Angular 專案）都能單獨使用 Redux 核心，不需要一併安裝 react-redux 或依賴任何 React 概念" },
+        { "id": "b", "text": "不可行，Redux 從技術上綁定了 react-dom，任何非 React 專案都無法安裝使用" },
+        { "id": "c", "text": "可行，但只能在瀏覽器環境使用，Node.js 環境完全不支援" },
+        { "id": "d", "text": "不可行，Redux 的 createStore API 只在有 window 物件的環境才能執行" }
+      ],
+      "answer": "a",
+      "explanation": "Redux 核心刻意設計成跟 UI 框架無關，這也是為什麼它能同時被 React、Vue、Angular 生態系借用；react-redux 才是那一層「把 Redux store 跟 React 元件橋接起來」的專屬套件。純 JS 環境（包含 Node.js 後端）安裝 redux 核心套件、使用 createStore 是完全合法且常見的用法。",
+      "verify": { "checks": [], "manual": "Redux 未安裝於本專案，跨環境相容性需要實際套件執行驗證，無法用 node -e 觀察其內部依賴關係。" }
+    },
+    {
+      "id": "ri-18-q3",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "使用 Redux 不需要特定建置工具，任何能跑 JS 的環境都行",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊用 Vite 建置一個 React 專案，有人擔心「Redux 是不是只能搭配 webpack 使用」。這個顧慮成立嗎？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "不成立：Redux 本身只是一套普通的 npm 套件（純 JavaScript 邏輯），不依賴任何特定建置工具；不管是 webpack、Vite、esbuild、還是完全不經過打包工具、直接在瀏覽器用 <script> 標籤載入，只要能執行 JavaScript，就能使用 Redux" },
+        { "id": "b", "text": "成立，Redux 只能在 webpack 建置的專案裡正常運作" },
+        { "id": "c", "text": "成立，改用 Vite 之後必須額外安裝一個叫 vite-redux-plugin 的官方外掛才能使用" },
+        { "id": "d", "text": "不成立，但只有 Create React App 這個特定工具鏈能搭配 Redux" }
+      ],
+      "answer": "a",
+      "explanation": "Redux 核心沒有任何建置工具層面的特殊需求，這個顧慮通常是把「常見的教學範例剛好用 webpack／CRA 示範」誤會成「技術上的必要條件」。只要 JavaScript 執行環境能載入這個套件，任何建置工具鏈（或完全不用打包工具）都能正常使用。",
+      "verify": { "checks": [], "manual": "屬套件相容性的事實性題目，無需執行驗證。" }
+    },
+    {
+      "id": "ri-18-q4",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "PropTypes.oneOfType：允許同一個 prop 接受多種型別之一",
+      "docs": "",
+      "story": "",
+      "prompt": "一個 Avatar 元件的 size prop 可能被傳數字（像素值）也可能被傳字串（如 \"large\"），想用 PropTypes 同時允許這兩種型別，該怎麼宣告？",
+      "code": "Avatar.propTypes = {\n  size: PropTypes.oneOfType([PropTypes.number, PropTypes.string]),\n};",
+      "options": [
+        { "id": "a", "text": "PropTypes.oneOfType([...]) 接收一個型別驗證子陣列，只要傳入的值符合陣列裡任何一種型別就算通過；這裡宣告 size 可以是 number 或 string 其中一種，比只宣告單一固定型別更能反映『這個 prop 本來就設計成接受多種輸入形式』的實際需求" },
+        { "id": "b", "text": "PropTypes 只能宣告單一固定型別，不存在允許多種型別擇一的寫法" },
+        { "id": "c", "text": "oneOfType 只能用來限制字串的可能值（例如列舉），不能混合不同的型別驗證子" },
+        { "id": "d", "text": "使用 oneOfType 之後，這個 prop 就變成必填，不能再省略" }
+      ],
+      "answer": "a",
+      "explanation": "oneOfType 是 PropTypes 提供的「聯集型別」驗證子，讓一個 prop 能合法接受多種不同型別的值，這在允許彈性輸入（像素數字或具名尺寸字串）的元件設計裡很常見，也是 TypeScript 聯集型別（number | string）在 PropTypes 這套執行期驗證系統裡的對應寫法。",
+      "verify": { "checks": [], "manual": "PropTypes 未安裝於本專案，型別驗證邏輯需要真實套件執行才能觀察，無法用 node 直接驗證。" }
+    },
+    {
+      "id": "ri-18-q5",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "render hijacking：HOC 攔截並改造被包裝元件的渲染結果",
+      "docs": "",
+      "story": "",
+      "prompt": "一個 HOC 不只是「決定要不要渲染」被包裝的元件（如前面 ri-12 章節的 withLoading），還進一步「攔截並修改」被包裝元件本來會渲染出的內容（例如額外插入除錯用的邊框）。這種手法被稱為什麼？",
+      "code": "function withDebugBorder(WrappedComponent) {\n  return function Wrapped(props) {\n    return (\n      <div style={{ border: \"1px dashed red\" }}>\n        <WrappedComponent {...props} />\n      </div>\n    );\n  };\n}",
+      "options": [
+        { "id": "a", "text": "render hijacking（渲染劫持）：HOC 不只是單純轉發 props、決定渲不渲染，而是進一步『介入並改造』被包裝元件實際渲染出的結果（這裡是額外包一層除錯邊框），本質上仍然是 HOC 模式的一種延伸應用，只是強調『對渲染結果本身動手腳』這個特性" },
+        { "id": "b", "text": "這種手法叫做 render props，跟 HOC 是完全不同的概念" },
+        { "id": "c", "text": "這種手法只能在 class component 裡實作，函式元件無法達成同樣效果" },
+        { "id": "d", "text": "這是一種反模式，React 官方明確禁止任何形式的渲染結果攔截" }
+      ],
+      "answer": "a",
+      "explanation": "render hijacking 是 HOC 眾多應用場景裡的一種說法，強調的是「HOC 不只是傳遞控制權，還能實際插手、改造子元件的渲染輸出」，跟前面 ri-12 章節示範的 withLoading（決定渲不渲染）是同一大類技巧的不同應用重點，函式元件跟 class component 都能實作。",
+      "verify": { "checks": [], "manual": "屬 HOC 應用模式的概念說明題，無可執行程式碼佐證抽象分類定義。" }
+    },
+    {
+      "id": "ri-18-q6",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "傳數字型別的 prop 不需要引號，直接放進大括號",
+      "docs": "https://react.dev/learn/passing-props-to-a-component",
+      "story": "",
+      "prompt": "想把數字 5 當作 prop 傳給元件，下面哪一種寫法傳的才是「數字」而不是「字串」？",
+      "code": "function Rating({ stars }) {\n  return <p>{typeof stars}：{stars}</p>;\n}\n\nconsole.log(renderToStaticMarkup(<Rating stars={5} />));\nconsole.log(renderToStaticMarkup(<Rating stars=\"5\" />));",
+      "options": [
+        { "id": "a", "text": "stars={5}（大括號包住字面數字）傳的才是真正的數字型別；stars=\"5\"（雙引號包住）傳的是字串 \"5\"——JSX 屬性只有用大括號包住的內容才會被當成 JavaScript 表達式求值，雙引號永遠產生字串，這條規則跟前面談過『屬性值想放變數要用大括號』是同一組語法規則的延伸" },
+        { "id": "b", "text": "兩種寫法效果完全一樣，JSX 會自動判斷數字字面值該轉換成哪種型別" },
+        { "id": "c", "text": "stars=\"5\" 傳的才是數字，stars={5} 才是字串" },
+        { "id": "d", "text": "只有 stars={5} 這種寫法合法，stars=\"5\" 會直接拋出例外" }
+      ],
+      "answer": "a",
+      "explanation": "這是前面 ri-15 章節「屬性值想放表達式要用大括號」規則的具體案例：純數字字面值也是一種表達式，只有用大括號包住才會被當成數字型別的 5 求值；雙引號無論裡面放什麼字元，永遠產生字串。混用兩者最常見的後果，就是拿到型別是字串的 \"5\"，如果後續程式碼假設它是數字（例如做加法運算），會得到字串拼接而非數字加總的意外結果。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Rating({ stars }) {\n  return <p>{typeof stars}：{stars}</p>;\n}\nconsole.log(renderToStaticMarkup(<Rating stars={5} />));\nconsole.log(renderToStaticMarkup(<Rating stars=\"5\" />));", "expected": "<p>number：5</p>\n<p>string：5</p>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-18-q7",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "Service Worker 讓 CRA 產出的應用支援離線快取，registerServiceWorker 是啟用它的進入點",
+      "docs": "",
+      "story": "",
+      "prompt": "早期 Create React App 產生的專案，index.js 裡會呼叫一個叫 registerServiceWorker() 的函式（後期版本改名為 serviceWorkerRegistration.register()）。它的用途是什麼？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "註冊瀏覽器的 Service Worker，讓應用程式的靜態資源（JS、CSS、圖片等）被快取起來，使用者離線或網路不穩時仍能開啟已經造訪過的頁面、後續造訪的載入速度也更快；這是讓一個一般的網頁應用具備 PWA（Progressive Web App）離線能力的基礎機制之一，預設通常刻意不啟用（呼叫的是 unregister，需要開發者主動選擇啟用）" },
+        { "id": "b", "text": "這個函式的用途是把 React 元件註冊到瀏覽器的除錯工具裡，跟離線快取無關" },
+        { "id": "c", "text": "這是用來啟動後端 Node.js 伺服器的函式，跟前端瀏覽器行為無關" },
+        { "id": "d", "text": "這個函式會自動幫應用程式的所有 API 請求加上快取層，跟靜態資源無關" }
+      ],
+      "answer": "a",
+      "explanation": "Service Worker 是瀏覽器提供的背景執行緒機制，能攔截網路請求、快取資源，是 PWA 離線能力的核心技術。CRA 範本內建的這段設定，讓開發者可以選擇是否啟用這層快取（早期版本預設呼叫 unregister，避免非預期地讓使用者卡在舊版快取內容），是否啟用要考量應用是否真的需要離線支援、以及快取失效策略是否處理得當。",
+      "verify": { "checks": [], "manual": "Service Worker 需要真實瀏覽器與網路環境才能觀察快取與離線行為，無法用 node 直接驗證。" }
+    },
+    {
+      "id": "ri-18-q8",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "setState／useState 更新若值沒有真的變化，React 仍可能跳過重繪（Object.is 比較）",
+      "docs": "https://react.dev/reference/react/useState",
+      "story": "",
+      "prompt": "按鈕的 onClick 呼叫 setCount(count)，傳入的值跟目前的 count 一模一樣（沒有 +1）。React 會不會因此觸發一次重繪？",
+      "code": "function Counter() {\n  const [count, setCount] = useState(5);\n  function handleClick() {\n    setCount(count); // 傳入跟目前值完全相同的 5\n  }\n  return <button onClick={handleClick}>{count}</button>;\n}",
+      "options": [
+        { "id": "a", "text": "React 內部用 Object.is() 比較新舊 state 值，如果判定『完全相同』（這裡兩次都是數字 5），會跳過這次重繪，即使呼叫了 setState／setCount；這是 React 內建的一項效能優化，避免因為呼叫了 setter 但值其實沒變而浪費一次不必要的渲染" },
+        { "id": "b", "text": "React 只要偵測到呼叫了 setCount，不管傳入值是否相同，永遠會觸發一次重繪" },
+        { "id": "c", "text": "這種寫法會拋出例外，setState 不允許傳入跟目前值相同的內容" },
+        { "id": "d", "text": "Object.is 比較只在 class component 的 setState 有效，函式元件的 useState 不會做這個優化" }
+      ],
+      "answer": "a",
+      "explanation": "這是 React 一個容易被忽略的效能優化：呼叫 state 的 setter 不代表『一定會重繪』，React 會用 Object.is（近似嚴格相等，但能正確處理 NaN 與 +0/-0 的邊界情況）比較新舊值，值真的沒變就跳過這次渲染。這條規則對函式元件的 useState 與 class component 的 setState 都適用，是 React 內部一致的優化策略。",
+      "verify": { "checks": [], "manual": "跳過重繪的效能優化需要多輪真實渲染搭配渲染次數計數才能觀察，無法用單次 node 執行驗證。" }
+    },
+    {
+      "id": "ri-18-q9",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "React 16 起支援直接回傳陣列與字串，不需要額外包一層元素",
+      "docs": "https://react.dev/learn/rendering-lists",
+      "story": "",
+      "prompt": "React 16 之前，元件的 render 方法只能回傳單一個元素，不能直接回傳一個陣列或純字串。下面這段寫法，在 React 16 之後的版本能正常渲染嗎？",
+      "code": "function Words() {\n  return [\"Hello\", \" \", \"World\"]; // 直接回傳陣列，沒有用 Fragment 或 div 包住\n}\n\nconsole.log(renderToStaticMarkup(<Words />));",
+      "options": [
+        { "id": "a", "text": "能正常渲染出 Hello World：React 16 起放寬了元件回傳值的限制，允許直接回傳陣列（陣列裡每一項會被當成手足元素依序渲染，通常建議搭配 key）或純文字字串，不強制要求一定要包一層 Fragment 或容器元素；這是 React 16 眾多改進裡，讓元件回傳值更貼近『陣列本身也是一種合法的多節點集合』這種直覺的一項放寬" },
+        { "id": "b", "text": "會拋出例外，元件永遠只能回傳單一個 JSX 元素，這條限制從未被放寬過" },
+        { "id": "c", "text": "只會顯示陣列的第一個元素 Hello，其餘元素會被忽略" },
+        { "id": "d", "text": "會顯示字面上的陣列語法（如 [\"Hello\",\" \",\"World\"]），而不是把每一項當成獨立內容渲染" }
+      ],
+      "answer": "a",
+      "explanation": "在 Fragment 正式支援之前，React 16 就已經先放寬了「元件只能回傳單一元素」這條限制，允許直接回傳陣列或字串，這也是後來 Fragment 這個更明確的語法糖出現前的一種過渡能力。實務上直接回傳陣列時，如果陣列元素是 JSX（不是純文字），仍然建議加上 key 屬性，避免前面 ri-10 章節提過的『陣列渲染缺少 key』警告。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Words() {\n  return [\"Hello\", \" \", \"World\"];\n}\nconsole.log(renderToStaticMarkup(<Words />));", "expected": "Hello World" }
+        ]
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-19-misc-hooks-foundations.json b/packages/core/src/data/questions/ri-19-misc-hooks-foundations.json
new file mode 100644
index 0000000..707bacc
--- /dev/null
+++ b/packages/core/src/data/questions/ri-19-misc-hooks-foundations.json
@@ -0,0 +1,166 @@
+{
+  "id": "ri-19",
+  "title": "React 進階探索：Hooks 基礎心智模型",
+  "questions": [
+    {
+      "id": "ri-19-q1",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "Hooks 讓函式元件也能擁有 state 與生命週期能力，不用改寫成 class",
+      "docs": "",
+      "story": "",
+      "prompt": "Hooks 出現之前，只有 class component 能有自己的 state、能用生命週期方法處理副作用。Hooks 解決了什麼根本問題？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "讓函式元件也能『掛上』狀態與生命週期相關的能力（useState 對應 state、useEffect 對應多個生命週期方法的組合），不用為了取得這些能力被迫改寫成 class component；這也連帶解決了 class component 常見的痛點——邏輯散落在不同生命週期方法裡難以重用、this 綁定容易出錯" },
+        { "id": "b", "text": "Hooks 讓函式元件擁有比 class component 更高的渲染優先權，永遠比 class component 先渲染" },
+        { "id": "c", "text": "Hooks 的存在只是為了縮短程式碼行數，跟狀態或生命週期能力無關" },
+        { "id": "d", "text": "Hooks 讓元件可以完全不需要接收任何 props" }
+      ],
+      "answer": "a",
+      "explanation": "Hooks 的官方動機文件明確列出幾個 class component 的痛點：邏輯難以在元件間重用（HOC／render props 的巢狀問題）、龐大元件難以拆分（一個 componentDidMount 裡塞了好幾種不相關的邏輯）、this 綁定容易出錯。useState／useEffect 這些 Hooks 讓函式元件也能表達同樣的能力，同時緩解這些痛點。",
+      "verify": { "checks": [], "manual": "屬 Hooks 設計動機的概念說明題，無可執行程式碼。" }
+    },
+    {
+      "id": "ri-19-q2",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "Hooks 規則：呼叫順序每次渲染都要一致，不能放進條件式",
+      "docs": "https://react.dev/warnings/invalid-hook-call-warning",
+      "story": "",
+      "prompt": "一個元件把 useState 放進 if 判斷式裡，只在某個條件成立時才呼叫。這違反了 Hooks 的哪一條核心規則？",
+      "code": "function Panel({ showExtra }) {\n  const [main, setMain] = useState(0);\n  if (showExtra) {\n    const [extra, setExtra] = useState(0); // 條件式呼叫 Hook：違規\n  }\n  return <p>{main}</p>;\n}",
+      "options": [
+        { "id": "a", "text": "違反了『Hooks 必須在每次渲染時，都以完全相同的順序被呼叫』這條規則：React 內部是依照『這是這次渲染呼叫的第 N 個 Hook』這個順序、而不是變數名稱，去對應到內部儲存的狀態；如果 showExtra 在不同渲染之間變來變去，Hook 呼叫的總數與順序就會跟著變動，導致 React 把某次渲染的狀態誤對應到錯誤的 Hook 上，這也是為什麼 use()（前面 ri-8 章節談過）刻意被設計成這條規則的例外" },
+        { "id": "b", "text": "沒有違反任何規則，Hooks 本來就可以自由放進條件式，這是完全合法的寫法" },
+        { "id": "c", "text": "違反的是『一個元件最多只能呼叫五個 Hooks』這條數量限制" },
+        { "id": "d", "text": "違反的是『useState 不能出現在函式元件裡』這條規則，只能出現在自訂 Hook 裡" }
+      ],
+      "answer": "a",
+      "explanation": "這條規則的根本原因是實作機制：React 不是用「變數名稱」記錄每個 useState 對應哪一份狀態，而是用「這是第幾次呼叫」這個呼叫順序當索引；只要呼叫順序在不同渲染間可能不一致（放進條件式、迴圈、提早 return 之後），這個索引對應就會錯亂。use() 是刻意設計成免疫這條規則的特例，其餘所有 Hooks（useState、useEffect、useContext...）都必須遵守。",
+      "verify": { "checks": [], "manual": "Hooks 呼叫順序錯亂在多輪真實渲染間才會顯現對應錯誤，無法用單次 node 執行驗證，且開發模式下才會印出對應警告。" }
+    },
+    {
+      "id": "ri-19-q3",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "遷移到 Hooks 是漸進式的選擇，不需要一次重寫所有 class component",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊有一個穩定運作多年、幾乎不再變動的 class component。Hooks 全面普及之後，是不是必須把它重寫成函式元件？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "不需要：class component 至今仍然被完整支援，React 官方從未要求、也沒有計畫強制淘汰它（唯一站得住腳的『必須用 class』情境是前面 ri-9 章節談過的 Error Boundary）。Hooks 遷移通常建議循序漸進——新元件用函式元件寫、真的需要修改邏輯的舊元件才順便改寫，沒有變動需求的穩定舊元件，重寫的風險（引入新 bug）通常大於收益，不需要為了『追新』而重寫" },
+        { "id": "b", "text": "必須立刻全部重寫，React 已經正式宣布未來版本會完全移除 class component 支援" },
+        { "id": "c", "text": "不需要，因為 class component 從技術上無法被轉換成函式元件加 Hooks 的寫法" },
+        { "id": "d", "text": "只有超過 100 行程式碼的 class component 才需要重寫，較短的可以保留" }
+      ],
+      "answer": "a",
+      "explanation": "React 官方的立場一貫是「Hooks 是新增能力，不是移除 class component」，重寫與否應該看實際維護成本與收益，而不是單純追新。這也是務實的技術債管理原則：沒有變動需求、運作穩定的程式碼，貿然重構反而承擔不必要的風險。",
+      "verify": { "checks": [], "manual": "屬技術債與重構時機判斷的推理題，無可執行程式碼。" }
+    },
+    {
+      "id": "ri-19-q4",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "useState 回傳的是一個長度固定為 2 的陣列，用陣列解構取名",
+      "docs": "https://react.dev/reference/react/useState",
+      "story": "",
+      "prompt": "useState 回傳的結果用陣列解構語法 const [count, setCount] = useState(0) 取用，而不是物件解構（const { value, setValue } = ...）。這是為什麼？",
+      "code": "function useCounter() {\n  const result = useState(0);\n  console.log(Array.isArray(result), result.length);\n  return result;\n}\nfunction Test() {\n  useCounter();\n  return null;\n}\nconsole.log(renderToStaticMarkup(<Test />));",
+      "options": [
+        { "id": "a", "text": "useState 回傳的其實就是一個長度固定為 2 的普通陣列 [目前值, setter函式]；用陣列解構的好處是呼叫端可以『自由重新命名』這兩個值（const [count, setCount]、const [name, setName]...），不像物件解構如果 useState 回傳固定的欄位名稱（例如 value、setValue），同一個元件裡用多次 useState 就會撞名，還得每次額外用 as 重新命名，陣列解構天生沒有這個困擾" },
+        { "id": "b", "text": "useState 回傳的是一個物件，陣列解構語法只是巧合能正常運作" },
+        { "id": "c", "text": "陣列解構純粹是歷史包袱，如果重新設計 React，官方會改用物件解構" },
+        { "id": "d", "text": "useState 回傳值的型別會依呼叫時機不同，有時是陣列有時是物件" }
+      ],
+      "answer": "a",
+      "explanation": "這是一個常被問到、看似小細節但背後有明確設計理由的問題：陣列解構允許呼叫端任意命名兩個值，這對『同一個元件裡會呼叫好幾次 useState，每次都需要不同名稱』的實際使用情境特別友善，是刻意的 API 設計選擇，不是隨意或歷史包袱。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { useState } from 'react'\nfunction useCounter() {\n  const result = useState(0);\n  console.log(Array.isArray(result), result.length);\n  return result;\n}\nfunction Test() {\n  useCounter();\n  return null;\n}\nimport { renderToStaticMarkup } from 'react-dom/server'\nrenderToStaticMarkup(<Test />);", "expected": "true 2" }
+        ]
+      }
+    },
+    {
+      "id": "ri-19-q5",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "Hooks 的靈感來源：函數式程式設計與其他語言的類似概念",
+      "docs": "",
+      "story": "",
+      "prompt": "React 團隊在推出 Hooks 時提到，這個設計參考了其他程式語言／函式庫的一些既有概念。這反映了什麼樣的設計態度？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "Hooks 不是憑空發明的全新概念，而是借鑑了函數式程式設計裡『用可組合的小函式表達邏輯』這個思路（呼應本專案 fp 章節談過的高階函式、組合），也參考了社群裡早已存在的一些實驗性模式（如 react-future 討論串裡提出的一些構想）；這種『站在既有想法上整理、打磨成官方一致的 API』的做法，讓 Hooks 能吸收社群已經驗證過的經驗，而不是從零開始賭一個全新的未經驗證的設計" },
+        { "id": "b", "text": "Hooks 是完全獨立於任何既有程式設計概念、React 團隊獨創、沒有參考任何外部靈感的全新發明" },
+        { "id": "c", "text": "Hooks 是直接照抄 Angular 的服務注入機制，兩者的實作與心智模型完全相同" },
+        { "id": "d", "text": "Hooks 這個名稱純粹是行銷考量，設計上跟函數式程式設計沒有任何關聯" }
+      ],
+      "answer": "a",
+      "explanation": "技術設計很少是全新發明，Hooks 的演講與文件裡都提到參考了函數式程式設計、社群已有的實驗；這種做法本身就是一種務實的工程態度——借鑑已被驗證過的想法、整理成一致的官方 API，而不是為了「原創」硬要從零設計一套沒人試過的東西。",
+      "verify": { "checks": [], "manual": "屬 Hooks 設計歷史脈絡的說明題，無可執行程式碼。" }
+    },
+    {
+      "id": "ri-19-q6",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "JSX 需要建置工具轉譯，瀏覽器本身不認得 JSX 語法",
+      "docs": "https://react.dev/learn/writing-markup-with-jsx",
+      "story": "",
+      "prompt": "如果把一個 .jsx 檔案的原始內容（未經轉譯）直接丟給瀏覽器的 <script type=\"text/javascript\"> 執行，會發生什麼事？",
+      "code": "// 未轉譯的原始 JSX\nfunction App() {\n  return <h1>Hi</h1>;\n}",
+      "options": [
+        { "id": "a", "text": "會拋出 JavaScript 語法錯誤：<h1>Hi</h1> 這種尖括號語法不是合法的 JavaScript 表達式，瀏覽器的 JS 引擎完全不認得 JSX 語法；JSX 必須先經過 Babel、esbuild、SWC 這類工具在建置階段轉譯成合法的 JavaScript 函式呼叫——用『classic』轉譯模式會轉成 React.createElement(...)，而 React 17 之後預設、目前多數工具鏈採用的『automatic』轉譯模式，則是轉成從 react/jsx-runtime 匯入的 jsx／jsxs 呼叫；不論哪一種，瀏覽器實際執行的永遠是轉譯後的產物，從來不是原始 JSX 檔案本身" },
+        { "id": "b", "text": "現代瀏覽器（Chrome、Firefox 最新版）已經原生支援直接解析 JSX 語法，不需要任何轉譯步驟" },
+        { "id": "c", "text": "瀏覽器會把 JSX 當成一段 HTML 字串直接插入頁面，忽略外層的 function 宣告" },
+        { "id": "d", "text": "只有 Safari 瀏覽器原生支援 JSX，其餘瀏覽器都需要轉譯" }
+      ],
+      "answer": "a",
+      "explanation": "JSX 從來不是瀏覽器原生理解的語法，這是需要建置工具介入的根本原因；每一個用 JSX 開發的 React 專案，背後都有一道轉譯步驟（不管是獨立呼叫 Babel、還是打包工具內建的轉譯 loader），把類 HTML 語法轉成合法的 JavaScript 呼叫，瀏覽器實際看到、執行的永遠是轉譯後的純 JavaScript。轉譯的目標會依採用的 JSX transform 而不同：舊式的 classic transform 轉成 React.createElement(...)；React 17 起、目前多數工具鏈預設的 automatic transform，則是轉成從 react/jsx-runtime 匯入的 jsx／jsxs 呼叫，不需要在每個檔案裡手動 import React。",
+      "verify": { "checks": [], "manual": "瀏覽器直接執行未轉譯 JSX 會拋出語法錯誤，需要真實瀏覽器環境觀察錯誤訊息，此處著重原理陳述。" }
+    },
+    {
+      "id": "ri-19-q7",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "prop drilling：資料要穿過好幾層跟資料本身無關的中間元件",
+      "docs": "",
+      "story": "",
+      "prompt": "一份使用者資料需要從最頂層的 App 元件，一路往下傳到第 5 層深的 Avatar 元件，中間 3 層元件（Layout、Sidebar、ProfileCard）完全不需要用到這份資料，只是負責『轉手』把 props 繼續往下傳。這個現象叫什麼，通常怎麼解決？",
+      "code": "<App>\n  <Layout user={user}>\n    <Sidebar user={user}>\n      <ProfileCard user={user}>\n        <Avatar user={user} /> {/* 真正用到 user 的只有這裡 */}\n      </ProfileCard>\n    </Sidebar>\n  </Layout>\n</App>",
+      "options": [
+        { "id": "a", "text": "這叫 prop drilling（прop 逐層鑽孔）：中間層元件被迫攜帶一份自己根本用不到的 props，純粹只是為了轉手給更深層的子元件；常見解法是用 Context（讓深層元件直接向上『訂閱』這份資料，不需要中間層手動轉傳）或狀態管理工具（Redux 等），跳過中間層直接把資料送到真正需要的地方" },
+        { "id": "b", "text": "這是正常、推薦的資料傳遞方式，不需要任何額外處理，props 穿越再多層都沒有問題" },
+        { "id": "c", "text": "這叫 Lifting State Up，跟前面 ri-10 章節談過的手足元件共享 state 是同一個概念" },
+        { "id": "d", "text": "這種情境下 React 會自動偵測並優化，中間層元件不會真的收到這份 props" }
+      ],
+      "answer": "a",
+      "explanation": "prop drilling 描述的是「資料流向」的一種痛點，跟 Lifting State Up（往上移動 state 讓手足元件共享）方向相反、目的也不同——後者是為了共享，前者是資料要往下穿越不相關的中間層。Context 正是為了解決這個具體痛點被設計出來的機制，讓深層元件可以跳過中間層直接讀到需要的資料。",
+      "verify": { "checks": [], "manual": "屬資料流動模式辨識的推理題，無可執行程式碼。" }
+    },
+    {
+      "id": "ri-19-q8",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "wrapper component：純粹負責包裝排版、把 children 轉發下去",
+      "docs": "https://react.dev/learn/passing-props-to-a-component#passing-jsx-as-children",
+      "story": "",
+      "prompt": "Card 元件本身不知道、也不關心裡面會放什麼內容，只負責提供統一的邊框與內距，把實際內容原樣轉發。這種元件被稱為什麼？",
+      "code": "function Card({ children }) {\n  return <div className=\"card\">{children}</div>;\n}\n\nconsole.log(renderToStaticMarkup(\n  <Card><p>任何內容都能放進來</p></Card>\n));",
+      "options": [
+        { "id": "a", "text": "wrapper component（包裝元件）：它的職責純粹是提供一層共通的外觀或排版（邊框、內距、置中），完全不關心、也不假設裡面實際會放什麼內容，靠 children 這個機制把控制權交還給呼叫端；Card、Modal、Layout 這類容器型元件通常都是這種設計" },
+        { "id": "b", "text": "這種元件叫 Higher-Order Component，跟一般函式元件的定義不同" },
+        { "id": "c", "text": "這種元件叫 render props 元件，因為它接收了 children 這個特殊 prop" },
+        { "id": "d", "text": "這種元件必須用 class component 實作，函式元件無法達成同樣效果" }
+      ],
+      "answer": "a",
+      "explanation": "wrapper component 這個說法強調的是「元件的職責是包裝、不是決定內容」，跟 HOC（接收元件、回傳新元件的函式）是完全不同層次的概念——wrapper component 本身就是一個普通元件，只是設計上刻意保持對內容的無知，透過 children 這個標準機制達到通用性。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Card({ children }) {\n  return <div className=\"card\">{children}</div>;\n}\nconsole.log(renderToStaticMarkup(\n  <Card><p>任何內容都能放進來</p></Card>\n));", "expected": "<div class=\"card\"><p>任何內容都能放進來</p></div>" }
+        ]
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-2-i18n.json b/packages/core/src/data/questions/ri-2-i18n.json
new file mode 100644
index 0000000..8afacd9
--- /dev/null
+++ b/packages/core/src/data/questions/ri-2-i18n.json
@@ -0,0 +1,139 @@
+{
+  "id": "ri-2",
+  "title": "React 國際化（i18n）",
+  "questions": [
+    {
+      "id": "ri-2-q1",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "FormattedMessage 不能當 placeholder 用",
+      "docs": "",
+      "story": "",
+      "prompt": "想幫輸入框設定翻譯過的 placeholder，下面這樣寫完全沒有作用（畫面上的 placeholder 是空的或直接報錯），問題出在哪？",
+      "code": "function SearchBox() {\n  return (\n    <input\n      placeholder={<FormattedMessage id=\"search.placeholder\" defaultMessage=\"搜尋...\" />}\n    />\n  );\n}",
+      "options": [
+        { "id": "a", "text": "<FormattedMessage> 渲染出來的是一個 React 元素，不是純文字字串；placeholder 這種 HTML 屬性只吃字串，塞進一個元素不會被轉成文字，要改用 useIntl() 拿到 formatMessage 函式，呼叫 formatMessage({ id }) 取得字串再放進 placeholder" },
+        { "id": "b", "text": "FormattedMessage 只能用在 class component，函式元件裡不能用" },
+        { "id": "c", "text": "defaultMessage 屬性名稱打錯了，正確名稱是 default" },
+        { "id": "d", "text": "input 元素本身不支援 placeholder 屬性" }
+      ],
+      "answer": "a",
+      "explanation": "react-intl 的 <Formatted... /> 系列元件回傳的都是「元素」，適合直接放進 JSX 當畫面內容；但像 placeholder、alt、aria-label 這種只接受純字串的 HTML 屬性，塞一個元素進去不會自動轉成文字。這種情境要改用底層的 API：useIntl() 拿到 intl 物件，呼叫 intl.formatMessage({ id: ... }) 直接算出翻譯後的字串。",
+      "verify": {
+        "checks": [],
+        "manual": "react-intl 未安裝於本專案，且需要 <IntlProvider> 的語系 context 才能實際運作，無法用 node 直接執行驗證。"
+      }
+    },
+    {
+      "id": "ri-2-q2",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "useIntl 取代舊版 injectIntl",
+      "docs": "",
+      "story": "",
+      "prompt": "舊版 react-intl 要用 injectIntl() 高階元件把 intl 物件注入 class component 的 props。改寫成 Hooks 風格的函式元件後，下面這個說法對嗎？",
+      "code": "function DebugLocale() {\n  const intl = useIntl();\n  return <p>目前語系：{intl.locale}</p>;\n}",
+      "options": [
+        { "id": "a", "text": "對：useIntl() 是 react-intl 提供的 Hook，會從最近的 <IntlProvider> 讀出目前的 locale 與格式化方法，效果等同於舊版 injectIntl 注入的 intl 物件，但不需要額外包一層高階元件" },
+        { "id": "b", "text": "不對：intl 其實是全域變數，不需要任何 Provider 包裹就能直接讀到" },
+        { "id": "c", "text": "不對：useIntl() 是 React 內建的 Hook，跟 react-intl 這個套件完全無關" },
+        { "id": "d", "text": "不對：只有 class component 才能拿到 intl 物件，函式元件必須手動用 props 傳" }
+      ],
+      "answer": "a",
+      "explanation": "react-intl 從 v3 開始提供 useIntl() 這個 Hook，作用跟舊版 injectIntl() 高階元件完全一樣——都是從最近的 <IntlProvider> context 讀出 intl 物件（裡面有 locale、formatMessage、formatDate 等）。差別只在於不用再多包一層高階元件，函式元件裡直接呼叫 Hook 就能拿到，寫法更直覺。",
+      "verify": {
+        "checks": [],
+        "manual": "react-intl 未安裝於本專案，且需要 <IntlProvider> 的語系 context 才能實際運作，無法用 node 直接執行驗證。"
+      }
+    },
+    {
+      "id": "ri-2-q3",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "用 ICU plural 語法處理單複數，而不是手刻 if/else",
+      "docs": "",
+      "story": "",
+      "prompt": "購物車要顯示「您有 1 件商品」或「您有 3 件商品」，數量不同、單複數措辭在某些語言差異很大（英文 1 item vs 3 items，阿拉伯文甚至有 6 種複數形式）。react-intl 建議用下面這種寫法，而不是自己在程式碼裡手刻 count === 1 ? ... : ... 判斷，為什麼？",
+      "code": "<FormattedMessage\n  id=\"cart.itemCount\"\n  defaultMessage=\"You have {count, plural, one {# item} other {# items}}\"\n  values={{ count: itemCount }}\n/>",
+      "options": [
+        { "id": "a", "text": "{count, plural, ...} 是 ICU MessageFormat 的語法，把單複數規則寫進翻譯字串本身，交給 react-intl 依照『當下這個語言』的複數規則自動選字；不同語言的複數規則數量、判斷邏輯都不同，寫死在 JavaScript 的 if/else 裡沒辦法涵蓋所有語言，只有把規則留給翻譯字串才能讓每個語言各自定義" },
+        { "id": "b", "text": "不管數量多少都寫死 items，反正使用者看得懂意思" },
+        { "id": "c", "text": "在 JavaScript 裡寫 count === 1 ? 'item' : 'items'，直接嵌入 defaultMessage 字串裡" },
+        { "id": "d", "text": "改用兩個完全獨立的翻譯 id，一個叫 singular 一個叫 plural，呼叫端每次都要自己手動判斷該用哪一個" }
+      ],
+      "answer": "a",
+      "explanation": "把單複數判斷寫死在 JavaScript 程式碼裡，只能覆蓋你當下想到的語言規則（例如英文的「是不是恰好等於 1」）；但像阿拉伯文有 6 種複數形式、波蘭文规则也跟英文不同。ICU plural 語法把「怎麼選字」的規則留給每一份翻譯檔自己定義，程式碼只要負責傳入 count 這個數字，跨語言的正確性就不用寫在應用程式邏輯裡。",
+      "verify": {
+        "checks": [],
+        "manual": "react-intl 未安裝於本專案，ICU MessageFormat 的複數規則需要實際的翻譯字串引擎解析，無法用 node 直接執行驗證。"
+      }
+    },
+    {
+      "id": "ri-2-q4",
+      "type": "fill-in",
+      "difficulty": 2,
+      "topic": "貨幣格式化背後其實是原生 Intl.NumberFormat",
+      "docs": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat",
+      "story": "",
+      "prompt": "react-intl 的 <FormattedNumber> 格式化貨幣，底層其實是呼叫瀏覽器原生的 Intl.NumberFormat。不依賴任何函式庫，只用原生 API 把 1234.5 格式化成美元字串，該傳入哪個 style 選項？把空格填起來",
+      "code": "const formatter = new Intl.NumberFormat(\"en-US\", { style: \"____\", currency: \"USD\" });\nconsole.log(formatter.format(1234.5));",
+      "options": [
+        { "id": "a", "text": "currency" },
+        { "id": "b", "text": "decimal" },
+        { "id": "c", "text": "money" },
+        { "id": "d", "text": "unit" }
+      ],
+      "answer": "a",
+      "explanation": "Intl.NumberFormat 的 style 選項決定輸出格式：\"currency\" 需要搭配 currency（如 \"USD\"）印出帶符號的貨幣字串（$1,234.50）；\"decimal\" 是純數字不帶符號；\"unit\" 用在公尺、公里這類度量單位；\"money\" 根本不是合法選項。react-intl 的 <FormattedNumber> 元件只是把這個原生 API 包一層 React 元件介面，格式化規則完全共通。",
+      "verify": {
+        "checks": [
+          { "code": "const formatter = new Intl.NumberFormat(\"en-US\", { style: \"currency\", currency: \"USD\" });\nconsole.log(formatter.format(1234.5));", "expected": "$1,234.50" }
+        ]
+      }
+    },
+    {
+      "id": "ri-2-q5",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "SSR 與用戶端 locale 不一致造成 hydration mismatch",
+      "docs": "",
+      "story": "",
+      "prompt": "這個 App 用 cookie 記錄使用者選擇的語系。伺服器渲染階段直接讀 cookie 決定 locale；用戶端第一次 render 卻先用瀏覽器的 navigator.language 當預設值，等 useEffect 跑完才修正成 cookie 裡的值。使用者選的是 \"en\"、但瀏覽器語言是 \"zh-TW\"，重新整理頁面時最可能出現什麼症狀？",
+      "code": "// 伺服器端（依 cookie，得到 \"en\"）\nconst serverLocale = getLocaleFromCookie(req);\n\n// 用戶端第一次 render（cookie 還沒讀到，先用瀏覽器語言）\nconst [locale, setLocale] = useState(navigator.language); // \"zh-TW\"\nuseEffect(() => {\n  setLocale(getLocaleFromCookie()); // 之後才修正成 \"en\"\n}, []);",
+      "options": [
+        { "id": "a", "text": "React 會在 console 印出 hydration mismatch 警告，畫面上也會看到文字先短暫顯示中文（用戶端第一次渲染的結果），再瞬間切換成英文（useEffect 修正之後）——因為伺服器渲染出的英文 HTML 跟用戶端第一次渲染的中文結果對不上" },
+        { "id": "b", "text": "完全沒有任何差異，React 會自動偵測並同步兩邊的 locale，不會有任何警告或畫面閃爍" },
+        { "id": "c", "text": "伺服器會直接拋出例外、整個頁面回應失敗" },
+        { "id": "d", "text": "只有 IE11 才會出現這個問題，其餘現代瀏覽器都不受影響" }
+      ],
+      "answer": "a",
+      "explanation": "SSR 的黃金原則是：伺服器渲染出的第一次 HTML，必須跟用戶端第一次（hydrate 前）render 出的結果完全一致，React 才能安全地把事件監聽器「接上」既有的 DOM，而不用整個重繪。這裡伺服器依 cookie 判斷是英文，但用戶端程式碼刻意先用瀏覽器語言、之後才用 effect 修正——這就製造出兩次不一致的渲染結果，觸發 hydration mismatch 警告，使用者也會親眼看到語系「跳一下」。正確做法是讓用戶端第一次 render 使用的初始 locale 來源跟伺服器一致（例如都從同一個 cookie 讀，而不是分別依賴 cookie 和 navigator.language）。",
+      "verify": {
+        "checks": [],
+        "manual": "hydration mismatch 需要真實的 SSR + 瀏覽器 hydrate 流程才能觀察，無法用 node 直接執行驗證。"
+      }
+    },
+    {
+      "id": "ri-2-q6",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "非 JSX 情境（如 document.title）該怎麼取得翻譯字串",
+      "docs": "",
+      "story": "",
+      "prompt": "頁籤標題 document.title 不是 JSX，不能直接塞 <FormattedMessage>。想把它設定成翻譯後的文字，下面這個自訂 Hook 的空格該填什麼？",
+      "code": "function useDocumentTitle(messageId) {\n  const intl = useIntl();\n  useEffect(() => {\n    document.title = ____;\n  }, [intl, messageId]);\n}",
+      "options": [
+        { "id": "a", "text": "intl.formatMessage({ id: messageId })" },
+        { "id": "b", "text": "<FormattedMessage id={messageId} />" },
+        { "id": "c", "text": "messageId" },
+        { "id": "d", "text": "intl.locale" }
+      ],
+      "answer": "a",
+      "explanation": "任何「不是 JSX 內容、而是需要純文字字串」的場景（document.title、alert()、瀏覽器通知內容、傳給第三方非 React 元件的文字），都得繞過 <Formatted... /> 元件、改用 intl.formatMessage() 這個底層 API 直接算出字串。選項 b 是元素，塞進 document.title（一個字串型別的屬性）只會被強制轉成類似 \"[object Object]\" 的無意義文字；c 只是翻譯 id 本身，不是翻譯結果；d 拿到的是語系代碼，不是訊息內容。",
+      "verify": {
+        "checks": [],
+        "manual": "react-intl 未安裝於本專案，且需要 <IntlProvider> 的語系 context 才能實際運作，無法用 node 直接執行驗證。"
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-20-misc-rendering-internals.json b/packages/core/src/data/questions/ri-20-misc-rendering-internals.json
new file mode 100644
index 0000000..88e61b0
--- /dev/null
+++ b/packages/core/src/data/questions/ri-20-misc-rendering-internals.json
@@ -0,0 +1,210 @@
+{
+  "id": "ri-20",
+  "title": "React 進階探索：渲染內部機制",
+  "questions": [
+    {
+      "id": "ri-20-q1",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "捕獲階段事件：onClickCapture 讓外層先於內層收到事件",
+      "docs": "",
+      "story": "",
+      "prompt": "瀏覽器事件正常是「冒泡」（由內往外，子元素先收到再往父層傳）。想讓外層容器搶先在子元素處理事件『之前』先攔截一次（例如記錄所有點擊的埋點邏輯），該用哪組事件？",
+      "code": "function Analytics({ children }) {\n  return (\n    <div onClickCapture={() => console.log(\"外層先記錄一次\")}>\n      {children}\n    </div>\n  );\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "用 Capture 字尾的事件（如 onClickCapture 對應一般的 onClick）：DOM 事件其實有兩個階段，先是由外往內的『捕獲階段』，事件真正到達目標元素後才開始由內往外的『冒泡階段』；React 一般常用的 onClick 等監聽的是冒泡階段，onClickCapture 這組則是監聽捕獲階段，讓外層容器能在子元素的一般事件處理器執行之前，就先攔截到這個事件"
+        },
+        {
+          "id": "b",
+          "text": "onClickCapture 與 onClick 完全等價，只是命名習慣不同，沒有任何執行順序差異"
+        },
+        {
+          "id": "c",
+          "text": "捕獲階段事件只存在於原生 DOM API，React 的合成事件系統完全不支援"
+        },
+        {
+          "id": "d",
+          "text": "onClickCapture 只能綁定在最外層的根節點，不能綁在任意巢狀的 div 上"
+        }
+      ],
+      "answer": "a",
+      "explanation": "捕獲／冒泡是瀏覽器事件模型的兩個階段，React 的合成事件系統完整支援兩者：一般的 onClick 對應冒泡階段（由內往外，這也是為什麼子元素的 stopPropagation 能擋掉父層的 onClick）；Capture 字尾的事件則對應捕獲階段（由外往內），適合『不管子層怎麼處理，外層都要優先攔截一次』的埋點、全域監控這類需求。",
+      "verify": {
+        "checks": [],
+        "manual": "捕獲/冒泡事件順序需要真實瀏覽器點擊互動才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-20-q2",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "螢幕更新的三個階段：觸發、渲染、提交",
+      "docs": "",
+      "story": "",
+      "prompt": "使用者點擊按鈕觸發 setState，到畫面真正顯示新內容，React 內部依序經過哪些階段？（呼應前面 ri-11 章節談過的 reconciliation 三步驟，這裡從『觸發』的角度重新描述）",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "①觸發（Trigger）：某個事件（使用者互動、資料到達）呼叫了 state 的 setter，排定一次更新；②渲染（Render）：React 呼叫元件函式，算出新的 Virtual DOM 樹；③提交（Commit）：React 把渲染階段算出的差異實際套用到真實 DOM 上，畫面才真正改變。這三個階段合起來，就是『使用者操作 → 畫面反映』這整條路徑背後的完整流程"
+        },
+        {
+          "id": "b",
+          "text": "React 只有『提交』這一個階段，觸發跟渲染其實是同一件事，沒有先後之分"
+        },
+        {
+          "id": "c",
+          "text": "這三個階段的順序不固定，每次更新可能以不同順序執行"
+        },
+        {
+          "id": "d",
+          "text": "『提交』階段永遠發生在『觸發』階段之前，React 會預先猜測使用者接下來的操作"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這是 React 官方文件對「畫面如何更新」的標準敘事框架：觸發（有什麼事件促使更新）、渲染（算出新樹）、提交（真正改 DOM）。理解這個順序，是理解 useEffect（提交完成後才執行）、useLayoutEffect（提交後、瀏覽器真正繪製前）這些時機差異的基礎，順序是固定的，不會因為情境不同而改變。",
+      "verify": {
+        "checks": [],
+        "manual": "屬 React 渲染流程的說明題，需要原始碼層級理解，無法用可執行片段驗證。"
+      }
+    },
+    {
+      "id": "ri-20-q3",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "在元件函式內部定義另一個元件，會導致內部元件每次渲染都是「全新的」，state 被重置",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊在 ParentForm 元件內部（不是外部）定義了一個 InnerField 子元件，用來包裝輸入框邏輯。使用者打字打到一半，ParentForm 因為別的原因重繪，結果輸入框裡的內容整個消失、又跳出一次奇怪的『重新掛載』行為。問題出在哪？",
+      "code": "function ParentForm() {\n  // 錯誤示範：在元件函式內部定義另一個元件\n  function InnerField() {\n    const [text, setText] = useState(\"\");\n    return <input value={text} onChange={(e) => setText(e.target.value)} />;\n  }\n\n  const [tick, setTick] = useState(0);\n  return (\n    <div>\n      <button onClick={() => setTick((t) => t + 1)}>觸發父層重繪</button>\n      <InnerField />\n    </div>\n  );\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "InnerField 是在 ParentForm 函式『內部』定義的：每次 ParentForm 重新渲染，都會重新執行這段函式定義，等於每次都產生一個『全新的函式』；React 用 type（元件函式本身的參考）判斷『這是不是同一個元件』，即使名字都叫 InnerField，每次渲染產生的都是不同的函式參考，React 因此判定『型別變了』，整個 InnerField 連同它自己的 state 一起被卸載重建——正確做法是把 InnerField 定義移到 ParentForm 外部，讓它在整個模組生命週期內只被定義一次"
+        },
+        {
+          "id": "b",
+          "text": "沒有任何問題，在元件內部定義子元件是官方建議的最佳實踐"
+        },
+        {
+          "id": "c",
+          "text": "問題出在 InnerField 沒有接收任何 props，跟它定義的位置無關"
+        },
+        {
+          "id": "d",
+          "text": "問題出在 useState 不能在巢狀定義的元件裡使用"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這是「reconciliation 依 type 判斷是否重用節點」（前面 ri-11 章節談過）在一個具體、很容易在真實專案裡發生的踩坑情境：判斷型別是否相同看的是函式本身的參考，不是名字字串是否一樣。在元件內部定義子元件，等於每次渲染都製造一個新函式、新型別，子元件連同它的 state 因此每次都被當成全新的重新掛載——這是 React 官方文件明確警告過的反模式，也是新手很容易不小心犯的錯誤。",
+      "verify": {
+        "checks": [],
+        "manual": "元件重新掛載造成的 state 重置需要多輪真實渲染與輸入互動才能觀察，無法用單次 node 執行驗證。"
+      }
+    },
+    {
+      "id": "ri-20-q4",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "key 不是只有陣列渲染才能用，任何想強制重建元件的場合都能用",
+      "docs": "https://react.dev/learn/preserving-and-resetting-state#option-2-resetting-state-with-a-key",
+      "story": "",
+      "prompt": "一個表單元件想要在使用者切換「編輯對象」時，強制整個表單的 state（包含所有輸入框內容）重置成全新狀態，而不是沿用舊資料殘留的痕跡。即使這裡只有一個表單元件，不是陣列渲染，也能用 key 達成這個效果嗎？",
+      "code": "// 只有一個元件，不是陣列渲染，但依然可以用 key\n<EditForm key={selectedUserId} userId={selectedUserId} />",
+      "options": [
+        {
+          "id": "a",
+          "text": "可以：key 的作用範圍不限於陣列渲染，任何位置的元素只要 key 值在前後兩次渲染之間改變，React 都會把它當成『不同的元素』，強制卸載舊的、掛載一個全新的實例（state 全部重置）；這裡把 key 設成 selectedUserId，使用者一切換編輯對象，key 就跟著變，表單元件會整個重新掛載，不會殘留上一個使用者的輸入痕跡"
+        },
+        {
+          "id": "b",
+          "text": "不行，key 屬性只有在 .map() 陣列渲染的情境下才會被 React 讀取，單一元件上設定 key 完全沒有作用"
+        },
+        {
+          "id": "c",
+          "text": "可以，但這樣做會讓 EditForm 收到兩次 userId 這個 prop，畫面上會出現重複的表單"
+        },
+        {
+          "id": "d",
+          "text": "不行，key 只能是字串型別，不能傳入像 selectedUserId 這種可能是數字的值"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這是「用 key 強制重置 state」這個技巧的典型應用（前面 react-9 章節已經深入談過這個機制）：key 的本質是「元素身份的標記」，不管是陣列裡的一項還是單獨一個元素都適用。刻意在 key 裡放一個「代表目前是哪個資料實例」的值，就能巧妙地讓 React 在這個值改變時把整個子樹當成全新元素處理，比自己手動寫邏輯清空每個欄位的 state 更簡潔可靠。",
+      "verify": {
+        "checks": [],
+        "manual": "key 值變化觸發的重新掛載需要多輪真實渲染才能觀察 state 重置效果，無法用單次 node 執行驗證。"
+      }
+    },
+    {
+      "id": "ri-20-q5",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "寫 reducer 的準則：純函式、不可變更新、依 action.type 分派",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊要把一段散落各處的 setState 邏輯，改寫成 useReducer 搭配一個 reducer 函式。寫 reducer 時該遵守哪些準則？",
+      "code": "function tasksReducer(tasks, action) {\n  switch (action.type) {\n    case \"added\":\n      return [...tasks, { id: action.id, text: action.text, done: false }];\n    case \"changed\":\n      return tasks.map((t) => (t.id === action.task.id ? action.task : t));\n    case \"deleted\":\n      return tasks.filter((t) => t.id !== action.id);\n    default:\n      throw new Error(\"Unknown action: \" + action.type);\n  }\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "reducer 必須是純函式：同樣的 (state, action) 輸入，永遠得到同樣的輸出，不能有副作用（不能發 API 請求、不能直接修改傳入的 state，要用展開運算子／filter／map 產生新陣列或新物件）；依照 action.type 用 switch 分派到不同的處理邏輯，每個分支各自回傳一份完整的新 state；遇到不認得的 action.type，通常明確拋出錯誤而不是靜默忽略，方便及早發現拼字錯誤或漏處理的 action 類型"
+        },
+        {
+          "id": "b",
+          "text": "reducer 可以自由呼叫 API、直接修改傳入的 state 物件，不受任何額外限制"
+        },
+        {
+          "id": "c",
+          "text": "reducer 只能處理一種 action.type，處理多種類型必須拆成多個 reducer 各自獨立呼叫"
+        },
+        {
+          "id": "d",
+          "text": "reducer 遇到不認得的 action.type 時，必須回傳 null 才是正確寫法"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這組準則其實跟 Redux 的 reducer 要求完全一致（本次新增的 ri-4 章節已細談過）：純函式、不可變更新、依 action.type 分派。useReducer 是 React 內建、規模較小的版本，共享同一套設計哲學；遇到不認得的 action.type 拋出錯誤而非靜默忽略，能在開發階段就及早暴露拼字錯誤或忘記處理的分支，是值得遵守的防禦性寫法。",
+      "verify": {
+        "checks": [],
+        "manual": "reducer 準則屬設計慣例說明，實際執行需要搭配 useReducer 的完整互動情境，無法用單一片段完整驗證。"
+      }
+    },
+    {
+      "id": "ri-20-q6",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "ReactJS 背後運作總覽：JSX → Virtual DOM → Fiber → Reconciliation → Commit",
+      "docs": "",
+      "story": "",
+      "prompt": "把前面各章節談過的機制串起來：從開發者寫下一段 JSX，到使用者眼睛看到畫面更新，整條路徑大致經過哪些環節？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "①JSX 在建置階段被轉譯成 React.createElement 呼叫（前面 ri-9 章節）；②執行後產生輕量的 Virtual DOM 元素樹（同上）；③state 變動時，React 用 Fiber 架構（前面 ri-11 章節）把渲染工作組織成可中斷、可依優先權排程的單位；④reconciliation 比對新舊 Virtual DOM 樹算出差異（同上）；⑤commit 階段把差異實際套用到真實 DOM，使用者才真正看到畫面變化——這是一條有明確先後順序、環環相扣的流程，不是各自獨立無關的機制"
+        },
+        {
+          "id": "b",
+          "text": "這些環節彼此完全獨立，沒有先後順序，React 可以任意跳過其中幾個步驟"
+        },
+        {
+          "id": "c",
+          "text": "JSX 會直接、即時地操作真實 DOM，中間不經過任何 Virtual DOM 或 Fiber 相關的處理"
+        },
+        {
+          "id": "d",
+          "text": "這整條流程只在開發模式下發生，正式環境的生產模式建置會完全跳過"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這題是把本次新增的多個 Core React 章節內容串成一條完整故事線：JSX 語法糖、Virtual DOM 資料結構、Fiber 排程架構、reconciliation 比對演算法、commit 實際更新 DOM——每一環都建立在前一環之上，共同構成「開發者寫 JSX」到「使用者看到畫面」這條路徑，這條流程在開發與生產模式下都會發生，只是生產模式拿掉了額外的開發期檢查（前面 ri-14 章節談過），核心流程本身不變。",
+      "verify": {
+        "checks": [],
+        "manual": "屬 React 整體渲染流程的總覽說明題，需要原始碼層級理解跨多個環節，無法用單一可執行片段驗證。"
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-21-misc-reducer-context-deep.json b/packages/core/src/data/questions/ri-21-misc-reducer-context-deep.json
new file mode 100644
index 0000000..c4e805d
--- /dev/null
+++ b/packages/core/src/data/questions/ri-21-misc-reducer-context-deep.json
@@ -0,0 +1,324 @@
+{
+  "id": "ri-21",
+  "title": "React 進階探索：useReducer 與 useContext 深入",
+  "questions": [
+    {
+      "id": "ri-21-q1",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "useState vs useReducer：狀態更新邏輯變複雜、彼此有關聯時改用 useReducer",
+      "docs": "",
+      "story": "",
+      "prompt": "一個購物車元件原本用好幾個獨立的 useState（items、总金額、折扣、運費各自一份 state），更新邏輯彼此牽連（加一項商品要同時更新總金額跟可能觸發的折扣門檻），程式碼變得難以追蹤『這次更新到底影響了哪些欄位』。什麼時候該考慮把這些 useState 收斂成一個 useReducer？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "當多個 state 欄位的更新邏輯彼此關聯、經常需要『同時』依某個事件一起變化時，把它們收斂進同一個 reducer，用一個 action 描述『發生了什麼事』，reducer 內部一次決定所有相關欄位該怎麼變，比分散在好幾個 useState 呼叫、還要小心翼翼確保彼此同步更新更不容易出錯；如果 state 欄位彼此獨立、更新邏輯簡單，維持多個 useState 反而更直接，不需要為了『看起來更工程化』強行改用 useReducer"
+        },
+        {
+          "id": "b",
+          "text": "任何情境下 useReducer 都比 useState 優越，應該無條件把所有 useState 都改寫成 useReducer"
+        },
+        {
+          "id": "c",
+          "text": "useReducer 只能管理數字型別的狀態，物件或陣列狀態必須用 useState"
+        },
+        {
+          "id": "d",
+          "text": "useReducer 與 useState 是完全不相關的兩個 Hook，不能用其中一個取代另一個的功能"
+        }
+      ],
+      "answer": "a",
+      "explanation": "useReducer 本質上是 useState 的一種進階形式（React 內部甚至可以把 useState 理解成一個簡化版的 useReducer），適合「更新邏輯複雜、多個欄位彼此關聯」的情境；state 簡單、彼此獨立時，多個 useState 更直接易懂，兩者是依情境選擇的工具，不是絕對優劣的關係。",
+      "verify": {
+        "checks": [],
+        "manual": "屬狀態管理工具選型的推理題，無可執行程式碼。"
+      }
+    },
+    {
+      "id": "ri-21-q2",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "useReducer 的運作方式：dispatch 一個 action，reducer 算出新 state",
+      "docs": "https://react.dev/reference/react/useReducer",
+      "story": "",
+      "prompt": "這個計數器用 useReducer 管理。連續 dispatch 兩次 { type: \"increment\" } 之後，count 會是多少？",
+      "code": "function counterReducer(state, action) {\n  switch (action.type) {\n    case \"increment\": return { count: state.count + 1 };\n    case \"reset\": return { count: 0 };\n    default: return state;\n  }\n}\n\nfunction useCounter() {\n  const [state, dispatch] = useReducer(counterReducer, { count: 0 });\n  const incrementTwice = () => {\n    dispatch({ type: \"increment\" });\n    dispatch({ type: \"increment\" });\n  };\n  return { state, incrementTwice }; // dispatch 改放進事件處理器裡呼叫，不是在 render body 直接呼叫\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "useReducer(reducer, initialState) 回傳 [目前的 state, dispatch 函式]；每次呼叫 dispatch(action)，React 會用『目前的 state』跟這個 action 呼叫 reducer 函式，把回傳結果當成新的 state；這跟 useState 的更新流程概念一致，只是把『怎麼算出新 state』這件事，從呼叫端直接給值，改成集中寫在 reducer 函式裡、由 action 描述意圖"
+        },
+        {
+          "id": "b",
+          "text": "dispatch 呼叫的當下會立刻同步更新 state 並回傳新值，不需要等待下一次渲染"
+        },
+        {
+          "id": "c",
+          "text": "reducer 函式只能回傳數字，不能回傳物件型別的 state"
+        },
+        {
+          "id": "d",
+          "text": "useReducer 的第二個參數（初始 state）只能是空物件，不能帶初始值"
+        }
+      ],
+      "answer": "a",
+      "explanation": "useReducer 的心智模型可以類比成「小型的 Redux」：dispatch 送出一個描述『發生了什麼』的 action，reducer 是一個純函式，依 (目前state, action) 算出下一個 state。跟 setState 一樣，dispatch 本身不是同步立刻反映到你手上這個變數，而是排定一次更新、下一次渲染才會拿到新的 state。",
+      "verify": {
+        "checks": [],
+        "manual": "useReducer 需要在真實元件渲染週期中觀察 dispatch 觸發的重繪與狀態更新，單次呼叫無法完整驗證非同步更新特性，需人工審核。"
+      }
+    },
+    {
+      "id": "ri-21-q3",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "useReducer 搭配 useContext：把「狀態＋操作方式」一起往下傳，取代淺層 Redux",
+      "docs": "",
+      "story": "",
+      "prompt": "一個中型應用想要「多個不相鄰的元件都能讀取、也都能觸發更新」某份共享狀態，但團隊覺得為此引入完整的 Redux 有點殺雞用牛刀。useReducer 搭配 useContext 組合起來，能扮演類似的角色嗎？",
+      "code": "const TasksContext = createContext(null);\nconst TasksDispatchContext = createContext(null);\n\nfunction TasksProvider({ children }) {\n  const [tasks, dispatch] = useReducer(tasksReducer, initialTasks);\n  return (\n    <TasksContext.Provider value={tasks}>\n      <TasksDispatchContext.Provider value={dispatch}>\n        {children}\n      </TasksDispatchContext.Provider>\n    </TasksContext.Provider>\n  );\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "可以：用 useReducer 管理狀態與更新邏輯，再把『目前狀態』跟『dispatch 函式』分別透過兩個 Context 往下傳（拆成兩個 Context 是為了讓『只需要 dispatch、不需要讀 state』的元件不會因為 state 變動而不必要地重繪），任何深層元件都能透過 useContext 讀到狀態、或拿到 dispatch 觸發更新——這正是 React 內建工具能做到、不需要引入外部狀態管理套件就能覆蓋的中型應用場景"
+        },
+        {
+          "id": "b",
+          "text": "不行，useContext 只能讀取靜態值，沒辦法搭配會隨時間變化的 state 使用"
+        },
+        {
+          "id": "c",
+          "text": "可以，但這種組合的效果跟 Redux 完全相同，包括 DevTools 時間旅行除錯這類功能也都會自動具備"
+        },
+        {
+          "id": "d",
+          "text": "不行，一個應用程式裡最多只能建立一個 Context，不能同時建立 TasksContext 與 TasksDispatchContext"
+        }
+      ],
+      "answer": "a",
+      "explanation": "React 官方文件明確示範這個組合模式，把它定位成「不需要引入外部狀態管理套件、用內建工具就能撐起中型應用共享狀態需求」的方案；但它不會自動具備 Redux DevTools 那種時間旅行除錯能力（那是 Redux 生態系額外提供的工具），選項 c 誇大了兩者的等價程度。拆成兩個 Context 是這個模式裡一個值得注意的效能細節，避免不必要的重繪範圍擴大。",
+      "verify": {
+        "checks": [],
+        "manual": "屬架構模式選型的推理題，完整效果需要多元件協調的真實互動情境才能觀察，無法用單一片段驗證。"
+      }
+    },
+    {
+      "id": "ri-21-q4",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "同一個事件處理器裡連續 dispatch 多次，會依序各自被處理",
+      "docs": "https://react.dev/learn/queueing-a-series-of-state-updates",
+      "story": "",
+      "prompt": "一個按鈕的 onClick 裡連續呼叫了三次 dispatch({ type: \"increment\" })。跟連續呼叫三次 setCount(c => c + 1) 類似，count 最終會增加多少？",
+      "code": "function reducer(count, action) {\n  if (action.type === \"increment\") return count + 1;\n  return count;\n}\n\nfunction handleClick(dispatch) {\n  dispatch({ type: \"increment\" });\n  dispatch({ type: \"increment\" });\n  dispatch({ type: \"increment\" });\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "增加 3：React 會把同一個事件處理器裡連續的 dispatch 呼叫，依序排進一個更新佇列，逐一用『前一步驟算出的最新 state』當輸入呼叫 reducer——這裡的 reducer 直接用 count + 1（讀取的是佇列裡累積到當下的最新值，不是這次渲染最初拿到的那個 count），所以三次呼叫會依序疊加，最終增加 3；這跟 useState 搭配更新函式 c => c + 1 的行為模式一致，都是『排隊、依序處理』而不是互相覆蓋"
+        },
+        {
+          "id": "b",
+          "text": "只會增加 1，因為 React 會把同一個事件裡對同一個 state 的多次更新自動去重，只保留最後一次"
+        },
+        {
+          "id": "c",
+          "text": "增加 3，但三次 dispatch 會各自觸發一次獨立的重繪，總共重繪三次"
+        },
+        {
+          "id": "d",
+          "text": "程式會拋出例外，同一個事件處理器裡不能連續呼叫多次 dispatch"
+        }
+      ],
+      "answer": "a",
+      "explanation": "React 對同一個事件處理器裡的多次狀態更新有「批次處理」機制：多次 dispatch／setState 呼叫會先排進佇列，事件處理器執行完畢後，React 才依序、一次性地把這些更新套用完、只觸發一次重繪。這裡因為 reducer 用的是 count + 1（依賴目前傳入的 count 讀取『最新排隊結果』），三次呼叫會正確疊加成 +3，而不是像『直接寫死某個值』那樣互相覆蓋。",
+      "verify": {
+        "checks": [],
+        "manual": "dispatch 佇列與批次處理需要在真實元件多次事件觸發後才能觀察最終渲染結果，無法用單次 node 執行完整驗證。"
+      }
+    },
+    {
+      "id": "ri-21-q5",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "dispatch 本身是同步呼叫，但『新的 state 值』要等下一次渲染才讀得到",
+      "docs": "",
+      "story": "",
+      "prompt": "呼叫 dispatch 之後，緊接著在同一行程式碼裡讀取 state 變數，會拿到更新後的新值嗎？",
+      "code": "function handleClick() {\n  dispatch({ type: \"increment\" });\n  console.log(state.count); // 這裡讀到的是？\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "讀到的仍然是這次渲染『當下』的舊值，不是 dispatch 之後算出的新值：dispatch 這個動作本身是同步執行的（它會立刻把 action 放進更新佇列），但『重新呼叫 reducer、算出新 state、觸發重新渲染』是之後才發生的事；state 這個變數是這次渲染閉包捕捉到的值，在這次渲染結束、下一次重新渲染發生之前，它的值不會改變——想在 dispatch 之後立刻拿到最新值，唯一可靠的辦法是在 reducer 內部自己算出這個新值並使用它，或者等到下一次渲染"
+        },
+        {
+          "id": "b",
+          "text": "讀到的是更新後的新值，dispatch 會立刻同步更新 state 變數本身"
+        },
+        {
+          "id": "c",
+          "text": "這段程式碼會拋出例外，dispatch 之後不能立刻讀取 state"
+        },
+        {
+          "id": "d",
+          "text": "讀到的值是 undefined，dispatch 呼叫的當下 state 會被暫時清空"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這是 useState／useReducer 共通、也是最常讓新手困惑的特性：state 變數是「這一次渲染」的閉包快照，dispatch／setState 呼叫不會『穿越回去』改變這個已經捕捉好的變數值，只會排定『下一次渲染』要用新值重新執行整個元件函式。想確認更新後的值，要嘛在 useEffect 裡觀察 state 依賴的變化（下一次渲染後才會跑），要嘛從 reducer 的回傳值本身推算，不能寄望 dispatch 後緊接著讀到的變數立刻反映新值。",
+      "verify": {
+        "checks": [],
+        "manual": "state 閉包快照特性需要在真實渲染週期中比對 dispatch 前後讀值的差異才能觀察，無法用單次 node 執行完整驗證。"
+      }
+    },
+    {
+      "id": "ri-21-q6",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "useContext 讀取最近一層 Provider 提供的值，沒有 Provider 就用 createContext 的預設值",
+      "docs": "https://react.dev/reference/react/useContext",
+      "story": "",
+      "prompt": "ThemeContext 用 createContext(\"light\") 建立，帶了預設值 \"light\"。下面這個元件完全沒有被任何 <ThemeContext.Provider> 包住，useContext(ThemeContext) 會拿到什麼？",
+      "code": "const ThemeContext = createContext(\"light\");\n\nfunction ThemedText() {\n  const theme = useContext(ThemeContext);\n  return <p>目前主題：{theme}</p>;\n}\n\n// 完全沒有用 Provider 包住\nconsole.log(renderToStaticMarkup(<ThemedText />));",
+      "options": [
+        {
+          "id": "a",
+          "text": "拿到 \"light\"：useContext 會沿著元件樹往上找『最近的一個』對應的 Provider，如果沒有任何 Provider 包住（就像這裡），就會退回使用 createContext(defaultValue) 當初宣告時給的預設值；這個預設值主要的用途是『在還沒接上真正的 Provider 之前，讓元件獨立渲染也不會報錯』，方便單獨測試或元件庫的預覽情境"
+        },
+        {
+          "id": "b",
+          "text": "拿到 undefined，沒有 Provider 包住時 useContext 一律回傳 undefined，忽略 createContext 給的預設值"
+        },
+        {
+          "id": "c",
+          "text": "程式會拋出例外，useContext 必須搭配至少一個 Provider 才能使用"
+        },
+        {
+          "id": "d",
+          "text": "拿到 null，這是 useContext 在缺少 Provider 時的固定回傳值"
+        }
+      ],
+      "answer": "a",
+      "explanation": "createContext(defaultValue) 的 defaultValue 不是「随便寫著好看」的參數，而是在『樹上真的找不到任何對應的 Provider』時的合法備援值。這個特性讓元件在缺少完整 Provider 情境（例如獨立測試、Storybook 預覽）下仍然能渲染出合理的結果，不會直接壞掉。",
+      "verify": {
+        "checks": [
+          {
+            "jsx": "import { createContext, useContext } from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nconst ThemeContext = createContext(\"light\");\nfunction ThemedText() {\n  const theme = useContext(ThemeContext);\n  return <p>目前主題：{theme}</p>;\n}\nconsole.log(renderToStaticMarkup(<ThemedText />));",
+            "expected": "<p>目前主題：light</p>"
+          }
+        ]
+      }
+    },
+    {
+      "id": "ri-21-q7",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "一個元件可以同時使用多個不同的 Context，彼此互不影響",
+      "docs": "https://react.dev/reference/react/useContext",
+      "story": "",
+      "prompt": "一個元件同時需要「目前主題」跟「目前語系」這兩份彼此無關的全域資訊，各自用獨立的 Context 提供。可以在同一個元件裡呼叫兩次 useContext 嗎？",
+      "code": "const ThemeContext = createContext(\"light\");\nconst LocaleContext = createContext(\"zh-TW\");\n\nfunction Header() {\n  const theme = useContext(ThemeContext);\n  const locale = useContext(LocaleContext);\n  return <p>{theme} / {locale}</p>;\n}\n\nconsole.log(renderToStaticMarkup(\n  <ThemeContext.Provider value=\"dark\">\n    <LocaleContext.Provider value=\"en-US\">\n      <Header />\n    </LocaleContext.Provider>\n  </ThemeContext.Provider>\n));",
+      "options": [
+        {
+          "id": "a",
+          "text": "可以：一個元件呼叫多次 useContext，分別讀取不同的 Context，彼此完全獨立、互不影響，每個 useContext(SomeContext) 呼叫各自沿著樹往上找『最近的』對應 Provider；這裡巢狀包了兩層不同的 Provider，Header 能同時正確讀到 dark 跟 en-US"
+        },
+        {
+          "id": "b",
+          "text": "不行，一個元件裡只能呼叫一次 useContext，需要多份全域資料時必須合併成同一個 Context"
+        },
+        {
+          "id": "c",
+          "text": "可以，但兩個 Context 的 Provider 必須放在同一層（不能巢狀），否則只有最外層的會生效"
+        },
+        {
+          "id": "d",
+          "text": "程式會拋出例外，同一個元件不能同時訂閱兩個不同的 Context"
+        }
+      ],
+      "answer": "a",
+      "explanation": "Context 之間彼此獨立，一個元件可以自由訂閱任意數量的不同 Context，也不要求它們的 Provider 一定要在同一層——巢狀包裹是完全合法且常見的寫法（例如全域主題、語系、認證資訊各自用獨立的 Provider）。這是 Context 設計上刻意保持的靈活性，讓不同關注點的全域狀態可以彼此解耦、各自管理。",
+      "verify": {
+        "checks": [
+          {
+            "jsx": "import { createContext, useContext } from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nconst ThemeContext = createContext(\"light\");\nconst LocaleContext = createContext(\"zh-TW\");\nfunction Header() {\n  const theme = useContext(ThemeContext);\n  const locale = useContext(LocaleContext);\n  return <p>{theme} / {locale}</p>;\n}\nconsole.log(renderToStaticMarkup(\n  <ThemeContext.Provider value=\"dark\">\n    <LocaleContext.Provider value=\"en-US\">\n      <Header />\n    </LocaleContext.Provider>\n  </ThemeContext.Provider>\n));",
+            "expected": "<p>dark / en-US</p>"
+          }
+        ]
+      }
+    },
+    {
+      "id": "ri-21-q8",
+      "type": "predict-output",
+      "difficulty": 3,
+      "topic": "Context 傳物件時常見陷阱：value 每次渲染都建立新物件，訂閱者會被迫重繪",
+      "docs": "https://react.dev/reference/react/useContext#optimizing-re-renders-when-passing-objects-and-functions",
+      "story": "",
+      "prompt": "Provider 的 value 每次都用行內物件字面值 { user, theme } 傳入。父層因為某個不相關的 state 重繪時，所有訂閱這個 Context 的子元件會發生什麼事？",
+      "code": "function App() {\n  const [tick, setTick] = useState(0); // 跟 user/theme 完全無關的 state\n  const [user] = useState({ name: \"Amy\" });\n  const [theme] = useState(\"dark\");\n\n  return (\n    <AppContext.Provider value={{ user, theme }}> {/* 每次渲染都是新物件 */}\n      <button onClick={() => setTick(t => t + 1)}>跟 Context 無關的按鈕</button>\n      <Dashboard />\n    </AppContext.Provider>\n  );\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "即使 user 跟 theme 這兩份『實際內容』完全沒變，光是點擊那個跟 Context 毫不相干的按鈕（觸發 App 重繪），{ user, theme } 這個行內物件字面值就會重新建立成一個新的物件參考；所有透過 useContext(AppContext) 訂閱這個 Context 的子元件，都會因為 Provider 的 value 參考變了而被迫重繪——這跟前面 ri-14 章節談過 memo 淺層比較的陷阱是同一個根本原因（物件參考不穩定），解法是用 useMemo 包住這個 value 物件，讓它只在真正的依賴（user、theme）改變時才產生新參考"
+        },
+        {
+          "id": "b",
+          "text": "訂閱的子元件不會受到任何影響，Context 的 Provider 會自動做深層比較，判斷內容沒變就跳過重繪"
+        },
+        {
+          "id": "c",
+          "text": "只有 tick 這個 state 本身相關的元件會重繪，訂閱 AppContext 的子元件完全不會被牽連"
+        },
+        {
+          "id": "d",
+          "text": "程式會拋出例外，Context 的 value 不能是行內物件字面值"
+        }
+      ],
+      "answer": "a",
+      "explanation": "Context 沒有內建的淺層或深層比較機制——它單純用參考比對判斷 value 是否改變，這個特性經常跟 memo 的陷阱一起出現：只要 Provider 所在的元件重繪、且 value 是行內建立的物件字面值，所有訂閱者都會被迫跟著重繪，即使實際內容完全沒變。用 useMemo 包住 value（依賴陣列只放真正會變動的值），讓物件參考在不相關的重繪之間保持穩定，是這個常見效能陷阱的標準解法。",
+      "verify": {
+        "checks": [],
+        "manual": "Context 訂閱者被迫重繪的行為需要多輪真實渲染搭配重繪次數計數才能觀察，無法用單次 node 執行驗證。"
+      }
+    },
+    {
+      "id": "ri-21-q9",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "巢狀 Provider 時，讀到的永遠是最近的那一層",
+      "docs": "https://react.dev/learn/passing-data-deeply-with-context#context-passes-through-intermediate-components",
+      "story": "",
+      "prompt": "同一個 ThemeContext 被巢狀包了兩層，外層 value=\"light\"、內層又包了一層 value=\"dark\"。在兩層 Provider 之間的元件，跟在最內層的元件，各自讀到的值一樣嗎？",
+      "code": "function App() {\n  return (\n    <ThemeContext.Provider value=\"light\">\n      <p>{useContext(ThemeContext)}</p> {/* 外層：應該讀到 light（示意，實際 Hook 需在元件內呼叫） */}\n      <ThemeContext.Provider value=\"dark\">\n        <Inner />\n      </ThemeContext.Provider>\n    </ThemeContext.Provider>\n  );\n}\nfunction Inner() {\n  return <p>{useContext(ThemeContext)}</p>;\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "不一樣：useContext 永遠讀取『沿著元件樹往上找，第一個遇到的』Provider 提供的值；在兩層 Provider 之間的位置，往上找到的第一層就是外層的 value=\"light\"；Inner 元件位於內層 Provider 底下，往上第一個遇到的是內層的 value=\"dark\"——巢狀 Provider 允許在樹的不同區域，用同一個 Context 提供不同的值，內層會『覆蓋』外層，但只影響內層底下的子樹，不影響內外層之間的其他元件"
+        },
+        {
+          "id": "b",
+          "text": "一樣，同一個 Context 在整棵樹裡任何位置讀到的值永遠是最外層 Provider 提供的那一個"
+        },
+        {
+          "id": "c",
+          "text": "一樣，同一個 Context 在整棵樹裡任何位置讀到的值永遠是最內層 Provider 提供的那一個"
+        },
+        {
+          "id": "d",
+          "text": "程式會拋出例外，同一個 Context 不能被巢狀的多層 Provider 重複提供"
+        }
+      ],
+      "answer": "a",
+      "explanation": "巢狀 Provider 是 Context 支援『依樹上位置提供不同值』的具體機制：越靠內層的 Provider，只會影響它底下的子樹，不會逆向影響外層或平行的其他分支。這在需要『大部分頁面用預設主題，某個特定區塊強制用另一種主題』這類局部覆蓋的情境很有用，不需要額外設計其他機制。",
+      "verify": {
+        "checks": [
+          {
+            "jsx": "import { createContext, useContext } from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nconst ThemeContext = createContext(\"light\");\nfunction Between() {\n  return <p>{useContext(ThemeContext)}</p>;\n}\nfunction Inner() {\n  return <p>{useContext(ThemeContext)}</p>;\n}\nfunction App() {\n  return (\n    <ThemeContext.Provider value=\"light\">\n      <Between />\n      <ThemeContext.Provider value=\"dark\">\n        <Inner />\n      </ThemeContext.Provider>\n    </ThemeContext.Provider>\n  );\n}\nconsole.log(renderToStaticMarkup(<App />));",
+            "expected": "<p>light</p><p>dark</p>"
+          }
+        ]
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-22-misc-useeffect-deep.json b/packages/core/src/data/questions/ri-22-misc-useeffect-deep.json
new file mode 100644
index 0000000..1a8587e
--- /dev/null
+++ b/packages/core/src/data/questions/ri-22-misc-useeffect-deep.json
@@ -0,0 +1,198 @@
+{
+  "id": "ri-22",
+  "title": "React 進階探索：useEffect 深入",
+  "questions": [
+    {
+      "id": "ri-22-q1",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "依賴陣列裡的每一項都用 Object.is 比較，任何一項變了就重新執行 effect",
+      "docs": "https://react.dev/reference/react/useEffect#specifying-reactive-dependencies",
+      "story": "",
+      "prompt": "這個 effect 的依賴陣列有兩個值：userId 跟 filters（一個物件）。父層重繪時 userId 沒變，但 filters 是每次都重新建立的行內物件字面值。effect 會不會重新執行？",
+      "code": "function Profile({ userId }) {\n  const filters = { active: true }; // 每次渲染都是新物件\n\n  useEffect(() => {\n    console.log(\"fetch profile\", userId, filters);\n  }, [userId, filters]);\n\n  return <p>{userId}</p>;\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "會重新執行：React 對依賴陣列裡的『每一項』分別用 Object.is 做參考比較，只要任何一項在前後兩次渲染間參考不同，就會重新執行 effect；filters 是行內物件字面值，每次渲染都建立一個內容相同、但參考不同的新物件，依賴比較判定『變了』，即使 userId 沒變、filters 的實際內容也沒變，effect 依然會重新執行——這跟前面 ri-14 章節 memo 陷阱、ri-21 章節 Context value 陷阱是同一個『參考不穩定』的根本原因"
+        },
+        {
+          "id": "b",
+          "text": "不會重新執行，只要 userId 沒變，effect 就會跳過，不管 filters 是否為新物件"
+        },
+        {
+          "id": "c",
+          "text": "會重新執行，但只有在 userId 真的改變時才會，filters 完全不影響是否重新執行的判斷"
+        },
+        {
+          "id": "d",
+          "text": "程式會拋出例外，依賴陣列不能包含物件型別的值"
+        }
+      ],
+      "answer": "a",
+      "explanation": "依賴陣列比較是「逐項參考比較」，不是把整個陣列當一個值比較，也不是深層比較物件內容。物件、陣列、函式這類參考型別放進依賴陣列前，如果沒有想辦法讓它在不需要的時候保持穩定參考（useMemo、把它移到元件外部宣告、或者拆解成只放真正的原始值如 filters.active），effect 就容易比預期更頻繁地重新執行。",
+      "verify": {
+        "checks": [],
+        "manual": "依賴陣列比較觸發 effect 重新執行需要多輪真實渲染才能觀察，無法用單次 node 執行驗證。"
+      }
+    },
+    {
+      "id": "ri-22-q2",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "每次 effect 重新執行前，React 會先呼叫上一次的清理函式",
+      "docs": "",
+      "story": "",
+      "prompt": "一個聊天室元件依 roomId 連線；roomId 從 \"general\" 換成 \"random\" 時，React 呼叫這個 effect 的順序是什麼？",
+      "code": "useEffect(() => {\n  const connection = createConnection(roomId);\n  connection.connect();\n  return () => connection.disconnect(); // 清理函式\n}, [roomId]);",
+      "options": [
+        {
+          "id": "a",
+          "text": "roomId 改變、effect 需要重新執行時，React 會先呼叫『上一次』effect 回傳的清理函式（用舊的 roomId=\"general\" 斷開連線），接著才執行『這一次』新的 effect 本體（用新的 roomId=\"random\" 建立新連線）；這個『先清理、再重新設置』的順序，正是確保不會有兩個 roomId 的連線同時活著、造成資源洩漏的關鍵設計"
+        },
+        {
+          "id": "b",
+          "text": "React 會先執行新的 effect 本體建立新連線，之後才呼叫舊的清理函式斷開舊連線，兩個連線會短暫同時存在"
+        },
+        {
+          "id": "c",
+          "text": "清理函式只會在元件卸載（從畫面上完全移除）時執行一次，依賴變化重新執行 effect 不會觸發清理函式"
+        },
+        {
+          "id": "d",
+          "text": "React 會跳過清理函式，直接把新的 roomId 傳給舊的連線物件，不會重新建立連線"
+        }
+      ],
+      "answer": "a",
+      "explanation": "清理函式的呼叫時機有兩種情境：元件卸載時（呼應前面既有 react 章節談過），以及『依賴陣列裡的值變化、effect 即將重新執行』時——後者容易被忽略，但正是避免資源洩漏（舊連線沒斷、新連線又開）的關鍵機制。順序永遠是「先清理舊的，才設置新的」，不會讓兩份資源同時存在。",
+      "verify": {
+        "checks": [],
+        "manual": "effect 清理與重新執行的順序需要多輪真實渲染與外部連線觀察才能驗證，無法用單次 node 執行完整驗證。"
+      }
+    },
+    {
+      "id": "ri-22-q3",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "useEffect 的函式本身不能是 async，回傳 Promise 會被 React 忽略甚至警告",
+      "docs": "",
+      "story": "",
+      "prompt": "想在 useEffect 裡直接用 async/await 抓資料，把整個 effect 函式宣告成 async，這樣寫合法嗎？",
+      "code": "// 容易犯的錯誤寫法\nuseEffect(async () => {\n  const res = await fetch(`/api/user/${userId}`);\n  setUser(await res.json());\n}, [userId]);",
+      "options": [
+        {
+          "id": "a",
+          "text": "不合法，會在 console 印出警告：useEffect 預期傳入的函式，如果有回傳值，那個回傳值必須是『清理函式』（或什麼都不回傳）；async 函式不管內部邏輯是什麼，呼叫後永遠回傳一個 Promise，React 會把這個 Promise 誤認為是清理函式，導致清理機制失效並印出警告。正確寫法是在 effect 內部另外定義一個 async 函式、立刻呼叫它，effect 本體自己保持同步、不回傳 Promise；但這只解決了『回傳值型別對不上』的問題，還不足以避免競態：userId 若在請求完成前又變了、或元件已經卸載，先前送出的舊請求仍可能晚於新請求才 resolve，用過期結果覆寫最新 state。正確寫法還要搭配一個 ignore 旗標或 AbortController——cleanup 時把 ignore 設為 true（或呼叫 abort()），async 函式收到結果、要 setUser 之前先檢查這個旗標，確認自己不是過期請求才更新狀態"
+        },
+        {
+          "id": "b",
+          "text": "合法，React 會自動 await 這個 effect 函式回傳的 Promise，等非同步邏輯完成才繼續"
+        },
+        {
+          "id": "c",
+          "text": "合法，但只有在 React 18 之後的版本才支援，舊版會直接拋出例外"
+        },
+        {
+          "id": "d",
+          "text": "不合法，但原因是 useEffect 完全不能處理任何非同步邏輯，即使不宣告成 async 也無法在裡面呼叫 fetch"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這是前面既有 react 章節談過『元件函式不能是 async』（因為 React 預期同步拿到 element）背後同一套原理的延伸：useEffect 的回傳值有特定意義（清理函式），async 函式的回傳值永遠是 Promise，兩者的『契約』對不上。正確的寫法是 effect 內部包一層立即呼叫的 async 函式（IIFE）或另外定義的具名 async 函式，effect 本身仍然同步執行、且不回傳那個 Promise。但這只解決了『回傳值不能是 Promise』的問題，不代表資料一定會正確更新——依賴變化或元件卸載後，先前送出的請求仍可能晚點才 resolve，若不做任何防範，就會用過期資料覆寫掉當下最新的 state，甚至對已卸載的元件呼叫 setState。標準做法是在 cleanup 函式裡設定一個 ignore 旗標（或呼叫 AbortController 的 abort()），async 函式在 resolve 之後、呼叫 setState 之前先檢查這個旗標，確認自己不是過期的請求才更新狀態。",
+      "verify": {
+        "checks": [],
+        "manual": "useEffect 的回傳值型別檢查與警告、以及依賴變化或卸載後的競態行為，都需要真實開發環境搭配多輪非同步時序才能觀察，無法用 node -e 直接捕捉此類 React 內部警告與競態時序。"
+      }
+    },
+    {
+      "id": "ri-22-q4",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "一個元件可以有多個 useEffect，各自處理獨立的關注點",
+      "docs": "",
+      "story": "",
+      "prompt": "一個元件需要「依 roomId 連線聊天室」跟「依 documentTitle 更新網頁標籤標題」這兩件互不相關的副作用。該把它們塞進同一個 useEffect，還是拆成兩個？",
+      "code": "function ChatRoom({ roomId, title }) {\n  useEffect(() => {\n    document.title = title;\n  }, [title]);\n\n  useEffect(() => {\n    const connection = createConnection(roomId);\n    connection.connect();\n    return () => connection.disconnect();\n  }, [roomId]);\n\n  return <p>{title}</p>;\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "拆成兩個獨立的 useEffect：每個 effect 應該只對應『一件』彼此獨立的同步邏輯，各自宣告自己真正需要的依賴陣列；把不相關的邏輯硬塞進同一個 effect，會導致依賴陣列變得又臭又長、也讓『這個 effect 到底是為了處理什麼』變得模糊——一個元件裡出現多個 useEffect 是完全正常且推薦的做法，不是程式碼寫得不夠精簡的象徵"
+        },
+        {
+          "id": "b",
+          "text": "必須合併成同一個 useEffect，一個元件只能呼叫一次 useEffect"
+        },
+        {
+          "id": "c",
+          "text": "拆成兩個會導致執行順序無法預測，必須合併才能保證標題先更新、連線後建立"
+        },
+        {
+          "id": "d",
+          "text": "合併成一個效能比較好，因為只需要走一次依賴陣列比較"
+        }
+      ],
+      "answer": "a",
+      "explanation": "『依關注點拆分 effect』是官方文件明確建議的實踐：拆開的 effect 各自維護自己精確的依賴陣列，不會因為合併而互相牽連（例如 title 變了卻不小心也重新連線一次）。多個 useEffect 在同一個元件裡依宣告順序依序執行，順序是可預測的，不需要為了『順序保證』刻意合併。",
+      "verify": {
+        "checks": [],
+        "manual": "多個 useEffect 各自獨立執行的順序與依賴隔離，需要真實渲染與副作用觀察才能驗證，無法用單次 node 執行完整驗證。"
+      }
+    },
+    {
+      "id": "ri-22-q5",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "useEffect 造成無窮迴圈的經典成因：effect 內部更新了自己依賴陣列裡的 state，且沒有條件把關",
+      "docs": "",
+      "story": "",
+      "prompt": "這個元件一渲染，瀏覽器就開始不斷閃爍、CPU 佔用飆高。問題出在哪？",
+      "code": "function Counter() {\n  const [count, setCount] = useState(0);\n\n  useEffect(() => {\n    setCount(count + 1); // 在 effect 裡更新了依賴陣列裡的 count 本身\n  }, [count]); // count 變 → effect 重新執行 → 又更新 count → 無限循環\n\n  return <p>{count}</p>;\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "這個 effect 的依賴陣列裡有 count，但 effect 內部又呼叫 setCount 更新了 count 本身：count 變化 → 觸發 effect 重新執行 → effect 又把 count 改變 → 再次觸發 effect……形成一個沒有終止條件的無窮迴圈，這是 useEffect 最常見、也最容易在重構時不小心引入的錯誤模式之一；修法通常是重新檢視這個更新到底需不需要放進 effect（很多時候這種『依賴自己又改自己』的邏輯，可以直接在事件處理器裡處理，根本不需要 effect）"
+        },
+        {
+          "id": "b",
+          "text": "沒有任何問題，這是計數器每秒自動遞增的正常實作方式"
+        },
+        {
+          "id": "c",
+          "text": "問題出在依賴陣列是空陣列 []，應該改成不給依賴陣列"
+        },
+        {
+          "id": "d",
+          "text": "問題出在 setCount 的呼叫方式，應該改用 setCount(prev => prev + 1) 才能避免無窮迴圈"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這是 useEffect 無窮迴圈最典型的成因：依賴陣列裡的值，被 effect 自己的邏輯又改了一次，形成『改變觸發自己、自己又觸發改變』的循環。選項 d 提到的函式式更新（prev => prev + 1）能避免『閉包捕捉到過期值』這個不同的問題，但不能解決這裡『effect 依賴自己又改自己』這個更根本的迴圈成因——真正的修法是重新思考這段邏輯該不該放進 effect，而不是換一種呼叫 setCount 的寫法。",
+      "verify": {
+        "checks": [],
+        "manual": "無窮迴圈需要真實渲染週期反覆觸發才能觀察，執行 node -e 會直接卡死或耗盡呼叫堆疊，不適合自動化驗證，需人工審核。"
+      }
+    },
+    {
+      "id": "ri-22-q6",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "依賴陣列的三種寫法決定 effect 的執行頻率：不給、空陣列、有值",
+      "docs": "",
+      "story": "",
+      "prompt": "useEffect 的第二個參數（依賴陣列）有三種寫法：整個省略、給一個空陣列 []、給一個有值的陣列 [count]。這三種寫法分別讓 effect 在什麼時機重新執行？",
+      "code": "useEffect(() => { console.log(\"A\"); }); // 沒有依賴陣列\nuseEffect(() => { console.log(\"B\"); }, []); // 空依賴陣列\nuseEffect(() => { console.log(\"C\"); }, [count]); // 依賴 count",
+      "options": [
+        { "id": "a", "text": "A：完全沒給依賴陣列，代表『每一次渲染完成後都要重新執行』，沒有任何省略的判斷；B：空陣列代表『依賴清單裡沒有任何值會變』，在 production 環境只在元件第一次掛載後執行一次，之後不管重繪幾次都不會再執行——但在開發環境搭配 StrictMode 時，React 會刻意多跑一輪『掛載→清理→再掛載』來幫忙揪出沒寫清理函式的副作用，effect 本身會被多執行一次，這是刻意設計的開發期行為，不會出現在 production build；C：只有當 count 在前後兩次渲染間真的改變時才重新執行——三者是『每次都跑』、『只跑一次（production）』、『依條件跑』這三種不同的頻率設定，不是隨意的語法選擇" },
+        { "id": "b", "text": "三種寫法完全等價，效果沒有任何差異，只是語法風格不同" },
+        { "id": "c", "text": "省略依賴陣列代表『只在掛載時執行一次』，空陣列代表『每次渲染都執行』，兩者剛好相反於一般認知" },
+        { "id": "d", "text": "只有給依賴陣列的寫法（如 C）才合法，A、B 兩種寫法都會導致程式拋出例外" }
+      ],
+      "answer": "a",
+      "explanation": "依賴陣列的三種寫法對應三種明確的執行頻率語意：省略＝每次渲染後都執行（最少見、通常代表忘記加依賴陣列）；空陣列＝只在掛載時執行一次（最常見於「訂閱外部資源、只需要設置一次」的情境）；有值的陣列＝依那些值是否改變決定要不要重新執行。三者都是合法語法，選錯只會導致執行頻率不符預期，不會直接拋出例外。",
+      "verify": {
+        "checks": [],
+        "manual": "三種依賴陣列寫法的執行頻率差異需要多輪真實渲染才能觀察，無法用單次 node 執行驗證。"
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-23-misc-layouteffect-ref-imperative.json b/packages/core/src/data/questions/ri-23-misc-layouteffect-ref-imperative.json
new file mode 100644
index 0000000..d0cb9e1
--- /dev/null
+++ b/packages/core/src/data/questions/ri-23-misc-layouteffect-ref-imperative.json
@@ -0,0 +1,248 @@
+{
+  "id": "ri-23",
+  "title": "React 進階探索：useLayoutEffect、useRef 與 useImperativeHandle",
+  "questions": [
+    {
+      "id": "ri-23-q1",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "useLayoutEffect 的典型用途：量測 DOM 尺寸並在畫面繪製前調整，避免閃爍",
+      "docs": "",
+      "story": "",
+      "prompt": "一個提示框（Tooltip）要顯示在觸發元素正上方，但必須先知道提示框本身的實際高度，才能算出正確的垂直位移。用 useEffect 量測會出現『先閃一下在錯誤位置、才跳到正確位置』的畫面閃爍；改用 useLayoutEffect 能解決嗎？",
+      "code": "function Tooltip({ targetRect }) {\n  const ref = useRef(null);\n  const [top, setTop] = useState(0);\n\n  useLayoutEffect(() => {\n    const height = ref.current.getBoundingClientRect().height;\n    setTop(targetRect.top - height);\n  }, [targetRect]);\n\n  return <div ref={ref} style={{ position: \"absolute\", top }}>提示內容</div>;\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "能：useLayoutEffect 保證在瀏覽器『真正把畫面繪製到螢幕上』之前同步執行完畢，這裡在裡面量測 DOM 尺寸、呼叫 setTop 調整位置，會在使用者眼睛看到任何畫面之前就完成，因此不會有『先顯示錯誤位置、再跳到正確位置』這種閃爍；useEffect 則通常是在瀏覽器已經繪製完成『之後』才非同步執行（並非保證絕對如此——某些情況下瀏覽器實際排程仍可能讓它在下一次繪製前執行），如果裡面也做了會改變版面的更新，使用者通常會先看到一次錯誤位置的畫面，才看到修正後的結果，這正是兩者最關鍵的時機差異：useLayoutEffect 是『保證繪製前』，useEffect 則是『通常繪製後、但沒有像 useLayoutEffect 那樣的同步保證』"
+        },
+        {
+          "id": "b",
+          "text": "不能，useLayoutEffect 跟 useEffect 的執行時機完全相同，都無法避免這種閃爍"
+        },
+        {
+          "id": "c",
+          "text": "能，但原因是 useLayoutEffect 會自動快取上一次量測的結果，不需要重新計算"
+        },
+        {
+          "id": "d",
+          "text": "不能，useLayoutEffect 只能在 class component 裡使用，函式元件必須用 useEffect"
+        }
+      ],
+      "answer": "a",
+      "explanation": "useLayoutEffect 與 useEffect 的 API 用法幾乎一樣，差別純粹在『相對瀏覽器繪製的時機』：useLayoutEffect 同步執行在繪製之前，適合『需要量測 DOM、並且這次量測結果會回頭影響這次要顯示的畫面』這種場景，避免使用者看到中間過渡狀態的閃爍；代價是它會阻塞瀏覽器繪製，如果邏輯耗時較長，會讓畫面卡頓，這也是為什麼官方建議『沒有明確需要才別用它，優先用 useEffect』的原因。",
+      "verify": {
+        "checks": [],
+        "manual": "useLayoutEffect 相對瀏覽器繪製時機的差異需要真實瀏覽器環境觀察畫面閃爍與否，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-23-q2",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "useLayoutEffect 在伺服器端渲染會印出警告，因為 SSR 沒有真實的瀏覽器繪製步驟",
+      "docs": "https://react.dev/reference/react/useLayoutEffect#usage",
+      "story": "",
+      "prompt": "一個用了 useLayoutEffect 量測 DOM 尺寸的元件，如果被用在伺服器端渲染（renderToString／renderToStaticMarkup）的流程裡，會發生什麼事？",
+      "code": "function Widget() {\n  useLayoutEffect(() => {\n    console.log(\"量測 DOM\");\n  }, []);\n  return <div>Hi</div>;\n}\n\nconsole.log(renderToStaticMarkup(<Widget />));",
+      "options": [
+        {
+          "id": "a",
+          "text": "useLayoutEffect（以及 useEffect）在伺服器端渲染階段完全不會執行——這呼應前面 ri-7 章節已經驗證過的事實：SSR 沒有真實 DOM、沒有瀏覽器繪製這個時間點，兩種 Effect 依賴的時機根本不存在；額外值得注意的是，React 在 SSR 環境使用 useLayoutEffect 通常會在開發模式印出一則警告，提醒『這個 Hook 在伺服器端不會有任何效果，建議確認是否真的需要在 SSR 也執行這段邏輯』"
+        },
+        {
+          "id": "b",
+          "text": "useLayoutEffect 會在伺服器端同步執行，因為它本來就是『同步』的 Hook，不受渲染環境影響"
+        },
+        {
+          "id": "c",
+          "text": "程式會直接拋出例外，useLayoutEffect 完全不能用在任何會被伺服器端渲染的元件裡"
+        },
+        {
+          "id": "d",
+          "text": "useLayoutEffect 會被自動轉換成 useEffect 在伺服器端執行"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這題把前面 ri-7 章節已經用真實程式碼驗證過的事實（SSR 階段兩種 Effect 都不執行），延伸到 useLayoutEffect 特有的警告行為：因為它「同步阻塞、依賴繪製時機」的特性在 SSR 完全沒有對應概念，React 會主動提醒開發者留意這個落差，而不是靜默忽略。",
+      "verify": {
+        "checks": [
+          {
+            "jsx": "import { useLayoutEffect } from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nfunction Widget() {\n  useLayoutEffect(() => {\n    console.log(\"量測 DOM\");\n  }, []);\n  return <div>Hi</div>;\n}\nconsole.log(renderToStaticMarkup(<Widget />));",
+            "expected": "<div>Hi</div>"
+          }
+        ]
+      }
+    },
+    {
+      "id": "ri-23-q3",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "把不需要同步阻塞繪製的邏輯放進 useLayoutEffect，會讓畫面感覺卡頓",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊把一段「元件掛載時打一次 API 記錄使用者行為」的邏輯，寫進了 useLayoutEffect（而不是 useEffect）。這樣做對使用者體驗有什麼實際影響？",
+      "code": "// 不必要地使用 useLayoutEffect\nuseLayoutEffect(() => {\n  logAnalytics(\"page_view\"); // 跟畫面版面完全無關的邏輯\n}, []);",
+      "options": [
+        {
+          "id": "a",
+          "text": "會讓畫面感覺卡頓：useLayoutEffect 保證在瀏覽器真正繪製畫面之前『同步』執行完畢，代表它會阻塞繪製——如果放進去的邏輯（像這裡打 API 記錄）本身不影響這次要顯示的版面、不需要在繪製前就緒，卻被迫同步阻塞繪製流程，等於讓使用者多等一段本來不需要等待的時間才看到畫面；這種跟版面調整無關的邏輯，該用 useEffect（非同步、繪製後才執行，不阻塞使用者看到畫面）"
+        },
+        {
+          "id": "b",
+          "text": "沒有任何負面影響，useLayoutEffect 與 useEffect 的效能表現完全相同"
+        },
+        {
+          "id": "c",
+          "text": "會讓 API 請求的回應速度變快，因為 useLayoutEffect 有更高的網路請求優先權"
+        },
+        {
+          "id": "d",
+          "text": "會導致這段程式碼完全不會被執行，useLayoutEffect 只能放置與 DOM 量測相關的邏輯"
+        }
+      ],
+      "answer": "a",
+      "explanation": "「這段邏輯跟這次要顯示的版面有沒有關係」是判斷該用 useEffect 還是 useLayoutEffect 的關鍵問題：只有『量測 DOM、並且結果會回頭影響這次繪製』這類場景才值得付出阻塞繪製的代價；跟版面無關的邏輯（記錄分析、發送不影響畫面的請求）放進 useLayoutEffect，只會平白讓使用者等待，是常見的誤用情境。",
+      "verify": {
+        "checks": [],
+        "manual": "阻塞繪製造成的使用者體驗差異需要真實瀏覽器環境與效能量測工具才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-23-q4",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "layout thrashing：在 useLayoutEffect 裡反覆讀寫 DOM 版面資訊，強迫瀏覽器重複計算版面",
+      "docs": "",
+      "story": "",
+      "prompt": "一個 useLayoutEffect 裡，對多個元素依序執行「讀取這個元素目前的高度 → 依高度設定另一個元素的樣式 → 再讀取另一個元素的高度 → ...」這種讀寫交錯的邏輯，發現效能明顯變差。這是什麼問題？",
+      "code": "useLayoutEffect(() => {\n  items.forEach((item) => {\n    const height = item.ref.current.getBoundingClientRect().height; // 讀\n    item.ref.current.style.marginTop = height / 2 + \"px\"; // 寫，接著又讀下一個\n  });\n}, [items]);",
+      "options": [
+        {
+          "id": "a",
+          "text": "layout thrashing（版面震盪）：瀏覽器為了效能，通常會把多次版面相關的『讀取』盡量批次處理、延後計算；但只要中間穿插了一次『寫入』（改變樣式），就會強迫瀏覽器立刻同步重新計算一次版面（因為寫入可能影響了還沒讀取的其他元素），才能讓下一次讀取拿到正確的值。這裡反覆讀、寫、讀、寫，等於強迫瀏覽器一次又一次同步重新計算版面，效能開銷遠高於『先把所有讀取集中做完，再統一做所有寫入』的寫法"
+        },
+        {
+          "id": "b",
+          "text": "這是正常且無法避免的效能表現，任何版面量測邏輯都會有相同的效能開銷"
+        },
+        {
+          "id": "c",
+          "text": "問題純粹出在使用了 forEach 迴圈，改用 for 迴圈就能完全解決效能問題"
+        },
+        {
+          "id": "d",
+          "text": "這只在 Firefox 瀏覽器上會發生，其餘瀏覽器不受影響"
+        }
+      ],
+      "answer": "a",
+      "explanation": "layout thrashing 是前端效能裡一個經典的瀏覽器層級議題，跟 React 本身無關，但很容易在 useLayoutEffect 這種『本來就是為了同步操作 DOM』的場合裡不小心踩到。解法是把邏輯改寫成『先集中做完所有讀取（例如先算出一個包含所有高度的陣列），再集中做完所有寫入』，讓瀏覽器只需要重新計算一次版面，而不是讀寫交錯地反覆計算。",
+      "verify": {
+        "checks": [],
+        "manual": "layout thrashing 屬瀏覽器版面重新計算的效能議題，需要真實瀏覽器與效能量測工具才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-23-q5",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "useRef 除了抓 DOM，也常用來存放「不希望變動觸發重繪」的跨渲染資料",
+      "docs": "https://react.dev/reference/react/useRef",
+      "story": "",
+      "prompt": "這個元件用 useRef 記錄「目前已經送出過幾次表單」，這個數字只給內部邏輯判斷用（例如超過 3 次要鎖住按鈕），完全不顯示在畫面上。用 ref 而不是 state 記錄，對重繪次數有什麼影響？",
+      "code": "function Form() {\n  const submitCountRef = useRef(0);\n\n  function handleSubmit() {\n    submitCountRef.current += 1;\n    if (submitCountRef.current > 3) {\n      console.log(\"鎖住按鈕\");\n    }\n  }\n\n  return <button onClick={handleSubmit}>送出</button>;\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "累加 submitCountRef.current 完全不會觸發這個元件重繪：ref 的 current 屬性改變，不像 state 那樣會排定一次更新，這正是 useRef 的定義性特徵（前面既有 react-11 章節談過）；這裡的送出次數純粹是內部邏輯判斷用的計數器，畫面上沒有任何內容依賴它，用 ref 而不是 state 記錄，省下了『每次送出表單都要多重繪一次、卻沒有任何畫面內容真的改變』這種浪費"
+        },
+        {
+          "id": "b",
+          "text": "累加 submitCountRef.current 每次都會觸發這個元件重繪，效果跟用 state 記錄完全一樣"
+        },
+        {
+          "id": "c",
+          "text": "submitCountRef.current 每次都會被重置回 0，無法跨越多次點擊累加"
+        },
+        {
+          "id": "d",
+          "text": "程式會拋出例外，ref 不能用來存放數字，只能存放 DOM 節點"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這是「state vs ref」判斷準則（前面既有章節反覆談過）在一個具體案例上的應用：畫面完全不需要顯示的內部計數器，用 ref 記錄既能跨渲染保留、又不會製造不必要的重繪，是比 state 更貼切的選擇；若這個次數需要顯示在畫面上（例如提示『已送出 2 次』），才會需要改用 state。",
+      "verify": {
+        "checks": [],
+        "manual": "原本的檢查直接在 Form 的 render body 裡連續累加 submitCountRef.current 兩次來湊出『2』這個結果，但這等於在渲染過程直接做 ref 的副作用寫入——跟題目本身『useRef 值該在事件處理器裡更新，不該寫在 render body』的重點矛盾（render 可能被 React 多次呼叫，例如開發模式的 StrictMode 雙重呼叫，會讓寫在 render body 的累加被多算）。要真正驗證『點擊 handleSubmit 兩次、ref 累加到 2，但不觸發重新渲染』，需要真實 DOM 環境搭配點擊互動（如 fireEvent.click／userEvent.click）並觀察渲染次數，本專案 verify 執行環境僅支援 react-dom/server 的單次靜態渲染、沒有 jsdom 或互動能力，無法用 node 直接驗證，需人工審核。"
+      }
+    },
+    {
+      "id": "ri-23-q6",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "useImperativeHandle：讓父層透過 ref 呼叫子元件內部定義的特定方法，而不是拿到整個 DOM 節點",
+      "docs": "",
+      "story": "",
+      "prompt": "父層想透過 ref 呼叫子元件 VideoPlayer 的 play()／pause() 方法，但不希望父層能拿到底層 <video> 的完整 DOM 節點、任意亂改它的屬性。useImperativeHandle 怎麼解決這個需求？",
+      "code": "const VideoPlayer = forwardRef(function VideoPlayer(props, ref) {\n  const videoRef = useRef(null);\n\n  useImperativeHandle(ref, () => ({\n    play() { videoRef.current.play(); },\n    pause() { videoRef.current.pause(); },\n  }));\n\n  return <video ref={videoRef} src={props.src} />;\n});",
+      "options": [
+        {
+          "id": "a",
+          "text": "useImperativeHandle(ref, () => ({...}))：讓父層透過 ref.current 拿到的，不是底層真正的 DOM 節點，而是一個『開發者自己客製化的物件』，裡面只暴露想讓外部呼叫的方法（這裡是 play、pause）；父層完全碰不到 videoRef 這個內部的、真正指向 <video> 的 ref，等於把『子元件對外暴露的操作介面』限縮到刻意設計的最小範圍，而不是整個 DOM 節點的所有屬性與方法"
+        },
+        {
+          "id": "b",
+          "text": "useImperativeHandle 讓父層自動拿到底層 DOM 節點的完整存取權限，跟不使用它時完全一樣"
+        },
+        {
+          "id": "c",
+          "text": "useImperativeHandle 只能用在函式元件上，class component 無法使用等價功能"
+        },
+        {
+          "id": "d",
+          "text": "useImperativeHandle 的用途是取代 useState，管理元件內部的狀態"
+        }
+      ],
+      "answer": "a",
+      "explanation": "useImperativeHandle 解決的是「用 ref 溝通時，怎麼控制暴露的介面範圍」這個問題：一般搭配 ref 轉發（forwardRef／React 19 的 ref-as-prop）拿到的是完整 DOM 節點，父層理論上什麼都能改；useImperativeHandle 讓子元件自己決定要暴露哪些方法，是命令式（imperative）API 設計裡「最小暴露原則」的具體實踐，官方文件也提醒這是相對少用的進階 Hook，優先考慮宣告式（用 props 控制）的設計。",
+      "verify": {
+        "checks": [],
+        "manual": "useImperativeHandle 搭配真實 DOM 影音播放需要瀏覽器環境才能觀察 play/pause 效果，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-23-q7",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "useImperativeHandle 該搭配 forwardRef（或 React 19 的 ref-as-prop）使用，才能讓父層的 ref 生效",
+      "docs": "",
+      "story": "",
+      "prompt": "一個函式元件內部呼叫了 useImperativeHandle，但這個元件本身沒有用 forwardRef 包裝、也沒有在 React 19 風格下把 ref 當成一般 prop 接收。父層傳進來的 ref 能正確拿到 useImperativeHandle 暴露的物件嗎？",
+      "code": "// 沒有接收 ref，useImperativeHandle 的第一個參數傳了什麼？\nfunction Broken() {\n  useImperativeHandle(???, () => ({ focus() {} })); // 沒有 ref 可以傳\n  return <input />;\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "不能：useImperativeHandle 的第一個參數必須是父層透過某種管道（forwardRef 的第二個參數、或 React 19 直接從 props 解構出的 ref）傳進來的那個 ref 物件，這個元件才知道要把自訂的操作介面『掛』到哪個 ref 上；沒有先透過 forwardRef（或 ref-as-prop）拿到父層的 ref，useImperativeHandle 根本沒有東西可以傳，第一個參數會是 undefined，父層的 ref.current 也就拿不到任何東西"
+        },
+        {
+          "id": "b",
+          "text": "能，useImperativeHandle 會自動幫元件補上一個 forwardRef 包裝，不需要開發者手動處理"
+        },
+        {
+          "id": "c",
+          "text": "能，只要元件內部有呼叫 useRef，父層的 ref 就會自動連接上"
+        },
+        {
+          "id": "d",
+          "text": "能，useImperativeHandle 完全不依賴 forwardRef 或 ref-as-prop，兩者是彼此獨立無關的機制"
+        }
+      ],
+      "answer": "a",
+      "explanation": "useImperativeHandle 只是負責『客製化要掛在 ref 上的內容』，它本身不負責『怎麼從父層拿到這個 ref』——這件事必須靠 forwardRef（舊寫法）或 React 19 起把 ref 當一般 prop 解構（新寫法，前面既有 react-11 章節談過）先完成，兩者是搭配使用、缺一不可的組合，不是各自獨立的機制。",
+      "verify": {
+        "checks": [],
+        "manual": "ref 轉發與 useImperativeHandle 的搭配需要真實元件掛載與父層 ref 存取才能觀察，無法用 node 直接驗證。"
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-24-misc-memo-callback-custom-hooks.json b/packages/core/src/data/questions/ri-24-misc-memo-callback-custom-hooks.json
new file mode 100644
index 0000000..e804c4b
--- /dev/null
+++ b/packages/core/src/data/questions/ri-24-misc-memo-callback-custom-hooks.json
@@ -0,0 +1,214 @@
+{
+  "id": "ri-24",
+  "title": "React 進階探索：useMemo、useCallback 與自訂 Hook",
+  "questions": [
+    {
+      "id": "ri-24-q1",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "useMemo：記憶化一個昂貴計算的結果，依賴沒變就重用舊值",
+      "docs": "https://react.dev/reference/react/useMemo",
+      "story": "",
+      "prompt": "getFilteredList 是一個昂貴的篩選運算。用 useMemo 包住它，items 沒變、只有 unrelatedState 變化觸發重繪時，這段昂貴運算會重新執行嗎？",
+      "code": "let callCount = 0;\nfunction getFilteredList(items) {\n  callCount++;\n  return items.filter((i) => i.active);\n}\n\nfunction List({ items }) {\n  const filtered = useMemo(() => getFilteredList(items), [items]);\n  return <ul>{filtered.map((i) => <li key={i.id}>{i.name}</li>)}</ul>;\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "不會重新執行：useMemo(calculateFn, deps) 只有在依賴陣列（這裡是 [items]）裡的值真的改變時，才會重新呼叫 calculateFn；items 沒變的情況下，即使這個元件因為其他原因重新渲染，useMemo 都會直接回傳上一次快取的結果，不會再呼叫一次 getFilteredList，callCount 也不會增加"
+        },
+        {
+          "id": "b",
+          "text": "每次元件重繪都會重新執行，useMemo 只是把計算結果多印出一份 log，不影響實際執行次數"
+        },
+        {
+          "id": "c",
+          "text": "只有第一次渲染會執行，之後不管 items 是否改變都不會再執行"
+        },
+        {
+          "id": "d",
+          "text": "useMemo 只能包住回傳數字或字串的計算，不能用在回傳陣列的函式上"
+        }
+      ],
+      "answer": "a",
+      "explanation": "useMemo 的記憶化跟 useEffect 的依賴陣列比較是同一套機制（逐項參考比較），差別在於 useMemo 是『在渲染過程中』同步算出並快取一個值，而不是渲染完成後才執行的副作用。這讓「昂貴但輸入沒變就該重用」的計算，不會因為元件因其他不相干原因重繪而被迫重新計算一次。",
+      "verify": {
+        "checks": [],
+        "manual": "useMemo 的記憶化行為需要多輪真實渲染搭配呼叫次數計數才能觀察，無法用單次 node 執行驗證。"
+      }
+    },
+    {
+      "id": "ri-24-q2",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "useMemo 記憶化的是「值」，本身不會阻止子元件重繪，要搭配 memo 才有效果",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊在父層用 useMemo 包住傳給子元件的一個物件 prop，以為這樣就能讓子元件跳過不必要的重繪，結果子元件還是每次都跟著父層一起重繪。問題出在哪？",
+      "code": "function Parent() {\n  const [tick, setTick] = useState(0);\n  const config = useMemo(() => ({ max: 100 }), []); // 物件參考穩定了\n\n  return (\n    <div>\n      <button onClick={() => setTick(t => t + 1)}>tick</button>\n      <Child config={config} /> {/* Child 沒有包 memo */}\n    </div>\n  );\n}\nfunction Child({ config }) {\n  console.log(\"Child 渲染了\");\n  return <p>{config.max}</p>;\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "useMemo 只解決了『config 這個物件本身的參考是否穩定』這個問題，但 Child 元件本身沒有用 React.memo 包起來，代表它『不管 props 有沒有變，父層重繪它就跟著重繪』；useMemo 讓 config 的參考在父層重繪之間保持穩定，是為了讓『搭配 memo 的子元件』能正確判斷『props 沒變、可以跳過重繪』，如果子元件本身沒包 memo，穩定的 props 參考完全派不上用場，兩者必須搭配使用才有效果"
+        },
+        {
+          "id": "b",
+          "text": "useMemo 本身有 bug，無法讓物件參考在渲染之間保持穩定"
+        },
+        {
+          "id": "c",
+          "text": "問題出在依賴陣列給了空陣列，應該把 tick 也放進依賴陣列裡"
+        },
+        {
+          "id": "d",
+          "text": "Child 元件重繪是正常現象，跟 useMemo 或 memo 完全無關，任何子元件都無法避免跟著父層重繪"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這是一個常見的誤解：useMemo 只負責『讓某個值的參考保持穩定』，它本身不會、也沒辦法讓任何子元件跳過重繪——真正決定『props 沒變就跳過重繪』的是子元件外面包的 React.memo。兩者是互補的一對工具：memo 負責『比較 props、決定要不要跳過』，useMemo（或 useCallback）負責『確保比較的對象參考穩定』，只用其中一個通常達不到預期效果。",
+      "verify": {
+        "checks": [],
+        "manual": "子元件是否跳過重繪需要多輪真實渲染搭配 memo 包裝與否的對照觀察，無法用單次 node 執行驗證。"
+      }
+    },
+    {
+      "id": "ri-24-q3",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "useCallback 是「記憶化一個函式」，等同於對函式呼叫 useMemo",
+      "docs": "",
+      "story": "",
+      "prompt": "useCallback(fn, deps) 跟 useMemo(() => fn, deps) 這兩種寫法，效果一樣嗎？",
+      "code": "const handleClick1 = useCallback(() => {\n  console.log(\"clicked\");\n}, []);\n\nconst handleClick2 = useMemo(() => {\n  return () => console.log(\"clicked\");\n}, []);",
+      "options": [
+        {
+          "id": "a",
+          "text": "效果一樣：useCallback(fn, deps) 本質上就是 useMemo(() => fn, deps) 的語法糖——兩者都是『依賴沒變就回傳上一次的那個值』，差別只在於 useMemo 記憶化的是『呼叫一個函式後算出的結果』，useCallback 記憶化的是『函式本身這個值』，讓函式在依賴不變的渲染之間保持同一個參考，通常搭配 memo 包裝的子元件、或需要函式參考穩定的依賴陣列（如 useEffect 的依賴）一起使用"
+        },
+        {
+          "id": "b",
+          "text": "完全不一樣，useCallback 只能用在事件處理器，useMemo 只能用在計算結果"
+        },
+        {
+          "id": "c",
+          "text": "useCallback 每次渲染都會回傳一個全新的函式，跟依賴陣列無關"
+        },
+        {
+          "id": "d",
+          "text": "useMemo 不能用來記憶化函式，只能記憶化基本型別的值"
+        }
+      ],
+      "answer": "a",
+      "explanation": "useCallback 常被誤解成一個獨立、特別的機制，但它其實就是 useMemo 針對『記憶化函式』這個常見情境的語法糖，兩者的依賴比較規則完全相同。理解這一點，能幫助判斷『這裡該用哪一個』——記憶化計算結果用 useMemo，記憶化函式參考本身（讓它能安全放進其他 Hook 的依賴陣列、或傳給 memo 包裝的子元件）用 useCallback。",
+      "verify": {
+        "checks": [],
+        "manual": "useCallback 與 useMemo 記憶化函式的等價行為需要多輪真實渲染比對參考是否相同，無法用單次 node 執行驗證。"
+      }
+    },
+    {
+      "id": "ri-24-q4",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "自訂 Hook：把可重用的邏輯抽成一個以 use 開頭的函式，本身也遵守 Hooks 規則",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊在三個不同元件裡都寫了幾乎一樣的邏輯：追蹤瀏覽器目前是否連線（online/offline），只是各自元件裡的變數名稱不同。該怎麼消除這種重複？",
+      "code": "function useOnlineStatus() {\n  const [isOnline, setIsOnline] = useState(navigator.onLine);\n  useEffect(() => {\n    function handleOnline() { setIsOnline(true); }\n    function handleOffline() { setIsOnline(false); }\n    window.addEventListener(\"online\", handleOnline);\n    window.addEventListener(\"offline\", handleOffline);\n    return () => {\n      window.removeEventListener(\"online\", handleOnline);\n      window.removeEventListener(\"offline\", handleOffline);\n    };\n  }, []);\n  return isOnline;\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "把重複的邏輯抽成一個自訂 Hook（依慣例以 use 開頭命名，這裡是 useOnlineStatus），內部照樣呼叫其他內建 Hooks（useState、useEffect）；自訂 Hook 本質上就是一個『把幾個 Hooks 呼叫包裝起來、重新導出一份簡化介面』的普通函式，本身也必須遵守 Hooks 的呼叫規則（不能放進條件式），這是消除跨元件重複邏輯最直接的做法，比複製貼上同一段邏輯到三個元件更容易維護"
+        },
+        {
+          "id": "b",
+          "text": "自訂 Hook 只是把邏輯包成一個物件，內部不能再呼叫 useState 或 useEffect 這些內建 Hooks"
+        },
+        {
+          "id": "c",
+          "text": "自訂 Hook 必須用 class 語法定義，不能是一般函式"
+        },
+        {
+          "id": "d",
+          "text": "這種情境應該改用 HOC 才能消除重複，自訂 Hook 無法處理『追蹤瀏覽器連線狀態』這類副作用邏輯"
+        }
+      ],
+      "answer": "a",
+      "explanation": "自訂 Hook 是 Hooks 機制裡「邏輯重用」這個核心價值最直接的體現：把一段包含 state、effect 的邏輯抽成一個函式，函式名稱以 use 開頭（這個命名慣例讓 linter 能正確套用 Hooks 檢查規則），任何元件呼叫它就能拿到同一份邏輯的獨立副本（不同元件呼叫同一個自訂 Hook，各自的 state 是獨立的，不會共享）。",
+      "verify": {
+        "checks": [],
+        "manual": "自訂 Hook 的邏輯共用效果需要多個真實元件實例分別掛載並觀察狀態獨立性，無法用單次 node 執行完整驗證。"
+      }
+    },
+    {
+      "id": "ri-24-q5",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "同一個自訂 Hook 被兩個元件分別呼叫，各自的 state 是獨立的，不會共享",
+      "docs": "https://react.dev/learn/reusing-logic-with-custom-hooks#custom-hooks-let-you-share-stateful-logic-not-state-itself",
+      "story": "",
+      "prompt": "useCounter 這個自訂 Hook 內部用 useState 管理一個計數。ComponentA 跟 ComponentB 各自呼叫了一次 useCounter()。ComponentA 把自己的計數加到 5，ComponentB 的計數會不會也變成 5？",
+      "code": "function useCounter() {\n  const [count, setCount] = useState(0);\n  const increment = () => setCount((c) => c + 1);\n  return { count, increment };\n}\n\nfunction ComponentA() {\n  const { count, increment } = useCounter();\n  return <button onClick={increment}>A: {count}</button>;\n}\nfunction ComponentB() {\n  const { count } = useCounter();\n  return <p>B: {count}</p>;\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "不會：自訂 Hook 分享的是『邏輯』（同一段 useState/useEffect 的寫法），不是『狀態』本身——每個呼叫 useCounter() 的元件，都會各自建立一份完全獨立的 count state，彼此互不影響；ComponentA 把自己的計數加到 5，只會影響 ComponentA 內部這一份 state，ComponentB 的 count 仍然是它自己獨立的初始值 0，除非兩者刻意透過 Context 或提升 state 等機制共享同一份資料來源"
+        },
+        {
+          "id": "b",
+          "text": "會，因為兩個元件呼叫的是同一個 useCounter 函式，所以會共用同一份 count 狀態"
+        },
+        {
+          "id": "c",
+          "text": "會，但只有在兩個元件同時掛載在畫面上時才會共享狀態"
+        },
+        {
+          "id": "d",
+          "text": "不會，但原因是自訂 Hook 每次呼叫都必須傳入不同的初始值，才能保持獨立"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這是自訂 Hook 官方文件明確強調、也是最容易被誤解的一點：「共用邏輯，不是共用狀態」。每次呼叫一個自訂 Hook，內部的 useState／useEffect 呼叫都會在『呼叫它的那個元件』的渲染上下文裡各自建立獨立的一份，就像把同一段程式碼複製貼上到每個元件內部一樣，只是換成呼叫一個函式的形式表達，多個呼叫者之間預設完全不會互相影響。",
+      "verify": {
+        "checks": [
+          {
+            "jsx": "import { useState } from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nfunction useCounter() {\n  const [count] = useState(0);\n  return count;\n}\nfunction ComponentA() {\n  const count = useCounter();\n  return <p>A: {count}</p>;\n}\nfunction ComponentB() {\n  const count = useCounter();\n  return <p>B: {count}</p>;\n}\nconsole.log(renderToStaticMarkup(<div><ComponentA /><ComponentB /></div>));",
+            "expected": "<div><p>A: 0</p><p>B: 0</p></div>"
+          }
+        ]
+      }
+    },
+    {
+      "id": "ri-24-q6",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "useDebugValue：讓自訂 Hook 在 React DevTools 裡顯示一段易懂的除錯標籤",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊寫了一個自訂 Hook useOnlineStatus，在 React DevTools 的元件樹裡，只會看到它底層用到的 useState、useEffect 這些內建 Hook 的原始名稱，看不出『這是連線狀態』這個語意。useDebugValue 能怎麼幫上忙？",
+      "code": "function useOnlineStatus() {\n  const [isOnline, setIsOnline] = useState(true);\n  useDebugValue(isOnline ? \"在線\" : \"離線\"); // 只在 DevTools 顯示，不影響實際渲染或邏輯\n  // ...\n  return isOnline;\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "useDebugValue(value) 讓這個自訂 Hook 在 React DevTools 檢查元件樹時，額外顯示一段開發者自訂的標籤（這裡是『在線』或『離線』），純粹是除錯輔助用途，完全不影響元件實際的渲染結果或運作邏輯；這在自訂 Hook 內部邏輯較複雜、光看內建 Hook 名稱看不出語意的情況下，能讓除錯時更快理解目前狀態"
+        },
+        {
+          "id": "b",
+          "text": "useDebugValue 會把傳入的值顯示在使用者實際看到的畫面上，等同於一般的渲染內容"
+        },
+        {
+          "id": "c",
+          "text": "useDebugValue 只能在正式環境（production build）生效，開發模式下完全沒有作用"
+        },
+        {
+          "id": "d",
+          "text": "useDebugValue 是用來設定這個 Hook 的預設值，如果呼叫端沒有傳入任何參數就會使用它"
+        }
+      ],
+      "answer": "a",
+      "explanation": "useDebugValue 是一個純粹為了「開發體驗」設計的 Hook，只影響 React DevTools 裡顯示的除錯資訊，跟畫面渲染、應用程式邏輯完全無關；它主要的價值在於自己寫的、給其他開發者（或未來的自己）共用的自訂 Hook 函式庫，讓除錯時能一眼看出這個 Hook 目前的狀態語意，而不用自己在腦中翻譯內建 Hook 的原始數值。",
+      "verify": {
+        "checks": [],
+        "manual": "useDebugValue 只在 React DevTools 檢視時顯示，需要真實瀏覽器擴充功能環境才能觀察，無法用 node 直接驗證。"
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-25-misc-advanced-hooks.json b/packages/core/src/data/questions/ri-25-misc-advanced-hooks.json
new file mode 100644
index 0000000..d3bbe31
--- /dev/null
+++ b/packages/core/src/data/questions/ri-25-misc-advanced-hooks.json
@@ -0,0 +1,202 @@
+{
+  "id": "ri-25",
+  "title": "React 進階探索：進階 Hooks 與最佳實踐",
+  "questions": [
+    {
+      "id": "ri-25-q1",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "useDeferredValue：讓一個值的『更新』可以延後，優先保持輸入框本身的即時回應",
+      "docs": "https://react.dev/reference/react/useDeferredValue",
+      "story": "",
+      "prompt": "一個搜尋框，輸入框本身用 query 這個 state 即時反映使用者打字；下方的搜尋結果清單改用 useDeferredValue(query) 包過的 deferredQuery 渲染。第一次渲染（沒有任何延遲的必要）時，deferredQuery 會是什麼？",
+      "code": "function Search() {\n  const [query, setQuery] = useState(\"\");\n  const deferredQuery = useDeferredValue(query);\n  return (\n    <div>\n      <input value={query} onChange={(e) => setQuery(e.target.value)} />\n      <p>目前查詢：{deferredQuery}</p>\n    </div>\n  );\n}\n\nconsole.log(renderToStaticMarkup(<Search />));",
+      "options": [
+        {
+          "id": "a",
+          "text": "第一次渲染，deferredQuery 就等於 query 本身（這裡都是空字串）：useDeferredValue 只有在『這個值變化、且畫面正忙著處理更緊急的更新』時，才會讓渲染結果暫時落後於最新值幾拍；沒有任何延遲需求的初次渲染，兩者完全一致。它真正發揮作用的時機，是使用者快速打字時：input 本身（受控於 query）保持每個按鍵都立即反映，下方使用 deferredQuery 渲染的搜尋結果清單，可以暫時使用『稍舊一點』的查詢字串重新渲染，讓昂貴的清單重新計算不阻塞打字的流暢度"
+        },
+        {
+          "id": "b",
+          "text": "deferredQuery 永遠比 query 慢一個字元，即使是初次渲染也一樣"
+        },
+        {
+          "id": "c",
+          "text": "deferredQuery 永遠是空字串，不管 query 是什麼值"
+        },
+        {
+          "id": "d",
+          "text": "程式會拋出例外，useDeferredValue 只能接收數字型別的值"
+        }
+      ],
+      "answer": "a",
+      "explanation": "useDeferredValue 的心智模型是「這個值允許暫時落後」：平常（沒有效能壓力）它就是原始值本身；當渲染負擔重、有更緊急的更新需要優先處理時，React 才會讓依賴這個延後值的部分暫時使用舊值渲染，避免拖慢輸入框這種需要即時回饋的互動。這跟 useTransition（前面 ri-8 章節談過）解決的是同一類問題，但 useDeferredValue 包的是一個『值』，useTransition 包的是一段『更新的動作』，適用情境略有不同。",
+      "verify": {
+        "checks": [
+          {
+            "jsx": "import { useState, useDeferredValue } from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nfunction Search() {\n  const [query] = useState(\"\");\n  const deferredQuery = useDeferredValue(query);\n  return (\n    <div>\n      <p>目前查詢：{deferredQuery}</p>\n    </div>\n  );\n}\nconsole.log(renderToStaticMarkup(<Search />));",
+            "expected": "<div><p>目前查詢：</p></div>"
+          }
+        ]
+      }
+    },
+    {
+      "id": "ri-25-q2",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "useSyncExternalStore：安全地訂閱 React 狀態管理系統之外的外部資料來源",
+      "docs": "",
+      "story": "",
+      "prompt": "一個第三方函式庫（不是 useState/useReducer 管理，是自己維護一份全域資料＋訂閱機制）想跟 React 元件整合，讓元件在這份外部資料變化時正確重繪。為什麼不能直接用 useState + useEffect 手動訂閱，而官方建議改用 useSyncExternalStore？",
+      "code": "const value = useSyncExternalStore(\n  externalStore.subscribe, // 訂閱函式：外部資料變化時呼叫傳入的 callback\n  externalStore.getSnapshot // 取值函式：回傳目前的值\n);",
+      "options": [
+        {
+          "id": "a",
+          "text": "手動用 useState + useEffect 訂閱外部資料源，在 React 18 引入的並行渲染（concurrent rendering）機制下，容易出現『畫面上不同部分讀到不一致的外部資料快照』這種細微的錯誤（不同渲染批次讀到的外部值時間點不一致）；useSyncExternalStore 是官方針對『安全訂閱 React 之外的資料源』設計的專屬 Hook，內部處理了並行渲染下的一致性問題，這是手動拼湊 useState/useEffect 很難自己正確做到的保證"
+        },
+        {
+          "id": "b",
+          "text": "useState + useEffect 技術上完全無法訂閱任何外部資料源，只有 useSyncExternalStore 能做到"
+        },
+        {
+          "id": "c",
+          "text": "useSyncExternalStore 純粹是效能優化，跟並行渲染的一致性問題無關"
+        },
+        {
+          "id": "d",
+          "text": "useSyncExternalStore 只是 useState 的別名，兩者沒有任何行為差異"
+        }
+      ],
+      "answer": "a",
+      "explanation": "useSyncExternalStore 是 React 18 為了「跟外部狀態源正確整合」新增的專屬 Hook，很多狀態管理函式庫（包含 react-redux 的新版 useSelector）內部改用它實作，正是為了處理並行渲染模式下手動訂閱容易出現的細微不一致問題；一般應用程式開發者較少直接使用它，通常是透過已經整合好它的函式庫間接受益。",
+      "verify": {
+        "checks": [],
+        "manual": "useSyncExternalStore 需要真實外部資料源與並行渲染情境才能觀察一致性保證，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-25-q3",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "useInsertionEffect：CSS-in-JS 函式庫專用，在 DOM 變動前注入樣式，一般應用程式幾乎用不到",
+      "docs": "",
+      "story": "",
+      "prompt": "useInsertionEffect 執行時機比 useLayoutEffect 還要更早（在 DOM 真正發生變動之前）。官方文件明確說這個 Hook 主要是設計給誰用的？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "主要是設計給 CSS-in-JS 函式庫（如 styled-components、Emotion 這類在執行期動態注入 <style> 標籤的方案）在底層實作用的，用來確保『動態產生的樣式規則』能在瀏覽器計算版面、useLayoutEffect 執行之前就已經插入到 DOM 裡，避免樣式套用時機錯亂造成的版面抖動；一般應用程式開發者幾乎不需要直接使用這個 Hook，絕大多數情境用 useEffect 或 useLayoutEffect 就足夠"
+        },
+        {
+          "id": "b",
+          "text": "這是給一般應用程式開發者處理表單輸入驗證邏輯用的標準 Hook"
+        },
+        {
+          "id": "c",
+          "text": "這是用來取代 useState 管理元件狀態的新版 Hook，官方建議所有新專案優先採用"
+        },
+        {
+          "id": "d",
+          "text": "這個 Hook 專門用來處理路由跳轉邏輯，是搭配 React Router 使用的專屬 API"
+        }
+      ],
+      "answer": "a",
+      "explanation": "useInsertionEffect 是一個目標讀者非常明確、範圍很窄的底層 API：解決的是「CSS-in-JS 函式庫在執行期動態插入樣式規則」這個特定時機問題。React 官方文件也直接寫明「這個 Hook 是給函式庫作者用的，應用程式程式碼幾乎不需要用到它」，一般業務邏輯用 useEffect／useLayoutEffect 完全足夠，不需要因為看到這個名字就以為必須學會使用它。",
+      "verify": {
+        "checks": [],
+        "manual": "useInsertionEffect 的樣式注入時機屬 CSS-in-JS 函式庫內部實作細節，需要真實瀏覽器環境與函式庫原始碼才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-25-q4",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "useEffectEvent（React 19.2 起為穩定 API）：讓 effect 內部讀到「最新」的值，但不把它列進依賴陣列觸發重新執行",
+      "docs": "",
+      "story": "",
+      "prompt": "一個聊天室連線的 effect，依賴陣列只想放 roomId（連線本身只跟房間有關），但 effect 內部想在收到訊息時，用『當下最新』的 theme 這個 state 決定通知樣式——theme 改變不該觸發重新連線，但也不想讀到過期的 theme 值。這個『既要最新值、又不想列入依賴觸發重新執行』的矛盾，React 19.2 起已穩定發布的 useEffectEvent（或社群慣稱的 useEvent）想解決什麼？",
+      "code": "// React 19.2 起為穩定、正式文件化的 API，可直接從 'react' 匯入\nconst onMessage = useEffectEvent((message) => {\n  showNotification(message, theme); // 讀到的永遠是『最新』的 theme\n});\n\nuseEffect(() => {\n  const connection = createConnection(roomId);\n  connection.on(\"message\", onMessage);\n  return () => connection.disconnect();\n}, [roomId]); // 依賴陣列不需要放 theme，也不會讀到過期值",
+      "options": [
+        {
+          "id": "a",
+          "text": "useEffectEvent 讓開發者可以把『effect 裡需要用到、但改變時不該觸發 effect 重新執行』的邏輯抽出來，包裝成一個特殊函式：這個函式內部永遠能讀到呼叫當下最新的 props/state（不像一般函式會被閉包鎖定在定義那一刻的值），但它本身不需要（也不能）被放進 effect 的依賴陣列——解決了『依賴陣列想保持精簡（只放真正該觸發重新執行的值），又不想因此讀到過期閉包值』這個長期存在的兩難"
+        },
+        {
+          "id": "b",
+          "text": "useEffectEvent 是用來取代 useEffect 本身的新 Hook，官方建議所有 effect 都改寫成這種形式"
+        },
+        {
+          "id": "c",
+          "text": "useEffectEvent 讓依賴陣列變得完全不重要，任何值都不需要再放進依賴陣列"
+        },
+        {
+          "id": "d",
+          "text": "useEffectEvent 建立出來的函式可以在任何地方直接呼叫，包括直接寫在 render 過程或一般事件處理器（如 onClick）裡，沒有呼叫時機上的限制"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這個 Hook 想解決的是 useEffect 依賴陣列一個長期的兩難：『只放真正該觸發重新執行的依賴』與『effect 內部不該讀到過期閉包值』這兩個目標有時會衝突。它不是要取代 useEffect，也不會讓依賴陣列本身變得不重要——真正該觸發重新連線的 roomId 仍然要放在依賴陣列裡，只是把『讀最新值但不觸發重新執行』的那部分邏輯，抽出來用專屬機制處理。useEffectEvent 從 React 19.2 起已經是穩定、正式文件化的官方 API，不再是實驗性功能，可以直接從 'react' 匯入使用。使用上有幾個限制：Effect Event 要在元件內呼叫 useEffectEvent(...) 建立（呼叫時機跟其他 Hook 一樣，位於元件的渲染範圍內），但建立出來的這個函式本身只能在 effect 內部呼叫、或是被另一個 Effect Event 呼叫——不能直接從 render 過程或一般事件處理器（如 onClick）呼叫；也正因為它讀到的永遠是最新值，通常不需要（也不應該）被放進呼叫端 effect 的依賴陣列。",
+      "verify": {
+        "checks": [],
+        "manual": "useEffectEvent 為 React 19.2 起的穩定官方 API，但其『讀到最新閉包值、且只能從 effect 內呼叫』的行為仍需要多輪真實渲染與 effect 觸發才能觀察，無法用單次 node 執行完整驗證。"
+      }
+    },
+    {
+      "id": "ri-25-q5",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "Hooks 使用的幾條實務準則：命名慣例、依賴陣列誠實、拆分關注點",
+      "docs": "",
+      "story": "",
+      "prompt": "把本次深入談過的各種 Hooks 陷阱（依賴陣列參考不穩定、effect 混雜不相關邏輯、記憶化用錯地方）收斂成幾條實務準則，下列哪一組最貼切？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "①自訂 Hook 一律以 use 開頭命名，讓 ESLint 的 Hooks 規則外掛能正確辨識並套用檢查；②依賴陣列要『誠實』列出 effect 內部實際讀取的每一個外部值，而不是為了避免重新執行刻意省略某些依賴；③一個 effect 只處理一件事，關注點不同的邏輯拆成多個 effect；④memo／useMemo／useCallback 是效能優化工具，先確認真的有效能問題、且參考穩定性有意義的地方才用，不是每個元件、每個值都要無腦包一層"
+        },
+        {
+          "id": "b",
+          "text": "任何情境下都應該讓每個元件用盡可能多的 useMemo/useCallback 包住所有的值與函式，越多越好"
+        },
+        {
+          "id": "c",
+          "text": "依賴陣列應該永遠留空（[]），避免 effect 因為依賴變化而重新執行造成困擾"
+        },
+        {
+          "id": "d",
+          "text": "所有跟副作用相關的邏輯都應該合併進同一個 useEffect，減少 Hook 呼叫的總數"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這幾條準則是把本次深入的多個章節（依賴陣列比較、effect 拆分關注點、memo 陷阱）收斂成可以直接應用的原則。選項 b、c、d 分別對應到常見的過度優化（無差別亂包 memo 反而增加程式碼複雜度跟些微額外開銷）、隱藏依賴陷阱（省略依賴會讀到過期閉包值）、混雜關注點（依賴陣列變得又臭又長）這些反模式，都不是建議的做法。",
+      "verify": {
+        "checks": [],
+        "manual": "Hooks 最佳實踐屬綜合性推理與規範說明，無單一可執行程式碼片段能完整驗證所有準則。"
+      }
+    },
+    {
+      "id": "ri-25-q6",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "useTransition 包的是『動作』，useDeferredValue 包的是『值』——該用哪一個看你能不能控制更新的觸發點",
+      "docs": "",
+      "story": "",
+      "prompt": "同樣是「篩選一份大清單、不要卡住輸入框」這個需求，什麼情境該用 useTransition，什麼情境該用 useDeferredValue？",
+      "code": "// 情境一：你自己觸發這次更新（呼叫 setState 的地方就在你手上）\nfunction handleChange(e) {\n  setQuery(e.target.value); // 這裡你可以自己決定要不要包進 startTransition\n}\n\n// 情境二：值是從 props 傳進來的，你控制不了它什麼時候變\nfunction SearchResults({ query }) {\n  // query 的更新時機不是這個元件決定的\n}",
+      "options": [
+        { "id": "a", "text": "情境一（你自己能決定在哪裡呼叫 setState）適合用 useTransition：直接把這次 setState 包進 startTransition，標記成低優先權；情境二（值是從外部 props 傳入，你沒辦法控制觸發更新的那一行程式碼）適合用 useDeferredValue：對拿到的這個值本身『延後使用』，不需要控制它是怎麼被更新的" },
+        { "id": "b", "text": "兩者在任何情境下都完全可以互相替代，選哪個純粹看個人喜好" },
+        { "id": "c", "text": "useTransition 只能用在 class component，useDeferredValue 只能用在函式元件" },
+        { "id": "d", "text": "情境一該用 useDeferredValue，情境二該用 useTransition，跟描述剛好相反" }
+      ],
+      "answer": "a",
+      "explanation": "兩者解決的是同一類「大量重新渲染拖慢緊急互動」的問題，差別在切入點：useTransition 要求你能拿到「觸發這次更新的那個動作」本身，把它包進 startTransition；useDeferredValue 則不需要碰觸發更新的程式碼，只需要對『收到的值』宣告『這裡允許暫時落後』，適合值來自 props、你無法控制觸發時機的情境。",
+      "verify": {
+        "checks": [],
+        "manual": "兩者的取捨情境需要真實多元件協作與實際輸入互動才能完整驗證，無法用單一可執行片段驗證。"
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-26-misc-code-splitting-perf.json b/packages/core/src/data/questions/ri-26-misc-code-splitting-perf.json
new file mode 100644
index 0000000..e6a5b2b
--- /dev/null
+++ b/packages/core/src/data/questions/ri-26-misc-code-splitting-perf.json
@@ -0,0 +1,210 @@
+{
+  "id": "ri-26",
+  "title": "React 進階探索：程式碼分割與效能技巧",
+  "questions": [
+    {
+      "id": "ri-26-q1",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "code-splitting：把打包產物拆成多個小塊，需要時才載入",
+      "docs": "",
+      "story": "",
+      "prompt": "一個應用程式把所有頁面的程式碼打包成單一個巨大的 JS 檔案，使用者不管要不要用到「後台管理」這個很少人會進去的頁面，都得先下載完這包含後台程式碼的完整檔案才能開始使用首頁。code-splitting 想解決這個問題的思路是什麼？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "把打包產物拆成多個較小的檔案（chunk），依『使用者實際會不會用到』決定要不要載入——例如首頁需要的程式碼先載入，後台管理頁面的程式碼包成獨立的一塊，只有使用者真的導航到那個頁面時才觸發下載；這讓『使用者第一次打開網站』需要下載、解析、執行的程式碼量大幅減少，改善首次載入速度"
+        },
+        {
+          "id": "b",
+          "text": "code-splitting 是把同一份程式碼複製成多份存放在不同伺服器，跟載入時機無關"
+        },
+        {
+          "id": "c",
+          "text": "code-splitting 要求把所有的 CSS 樣式都改寫成行內樣式，不能使用外部樣式檔案"
+        },
+        {
+          "id": "d",
+          "text": "code-splitting 只能套用在圖片資源上，不能套用在 JavaScript 程式碼"
+        }
+      ],
+      "answer": "a",
+      "explanation": "code-splitting 的核心思路很直接：使用者不需要的程式碼，就不該強迫他們的瀏覽器先下載。這在大型應用（多頁面、多角色權限）特別有價值，React.lazy 搭配動態 import() 是 React 生態系裡實現這個思路最常見的手法（下一題會具體示範）。",
+      "verify": {
+        "checks": [],
+        "manual": "code-splitting 的實際載入行為需要真實建置工具與瀏覽器網路面板才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-26-q2",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "動態 import()：語法上就是一個回傳 Promise 的函式呼叫，是 code-splitting 的底層機制",
+      "docs": "",
+      "story": "",
+      "prompt": "React.lazy(() => import(\"./AdminPage\")) 這段程式碼裡的 import(\"./AdminPage\")，跟檔案最上方常見的 import AdminPage from \"./AdminPage\" 有什麼本質上的差異？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "檔案最上方的 import 是靜態語法，建置工具在打包當下就會把這個模組的程式碼一起打進最終產物（不管執行期用不用得到）；import(\"...\") 是動態、回傳 Promise 的函式呼叫，讓建置工具能辨識出『這裡是一個可以獨立拆開的邊界』，把這個模組拆成一個獨立的 chunk，只有程式碼真正執行到這一行、Promise 被呼叫時，才會觸發對應 chunk 的網路請求下載"
+        },
+        {
+          "id": "b",
+          "text": "兩者在打包後的最終產物裡完全沒有差異，只是撰寫語法不同"
+        },
+        {
+          "id": "c",
+          "text": "動態 import() 只能用來載入圖片或 CSS 檔案，不能用來載入 JavaScript 模組"
+        },
+        {
+          "id": "d",
+          "text": "靜態 import 語法本身就會觸發程式碼分割，動態 import() 反而不會"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這是 code-splitting 能夠實現的語法基礎：建置工具（webpack、Vite 等）都把「動態 import()」當成程式碼分割點的訊號，靜態的頂層 import 則是無條件打包進去。React.lazy 只是把這個原生的動態 import 語法，包裝成一個能被 Suspense 識別、等待載入完成的元件形式。",
+      "verify": {
+        "checks": [],
+        "manual": "動態 import 的打包分割行為需要真實建置工具處理才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-26-q3",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "loadable components：react-loadable／@loadable/component 是 React.lazy 官方支援之前，社群常用的替代方案",
+      "docs": "",
+      "story": "",
+      "prompt": "在 React.lazy＋Suspense 這組官方方案成熟之前，社群普遍怎麼做動態載入元件（code-splitting）？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "使用 react-loadable（或後繼的 @loadable/component）這類第三方套件：概念上跟 React.lazy 很相似（包一層動態 import()、載入完成前顯示 loading 畫面），差異在於它們額外補上了官方早期版本缺乏的能力，例如伺服器端渲染（SSR）時期的動態載入支援；React.lazy＋Suspense 現在已經是官方內建的標準做法，多數新專案不再需要額外安裝第三方套件"
+        },
+        {
+          "id": "b",
+          "text": "社群完全沒有任何解法，動態載入元件的能力是 React.lazy 首次引入才變得可能"
+        },
+        {
+          "id": "c",
+          "text": "loadable components 是一種瀏覽器內建 API，跟 React 生態系的第三方套件無關"
+        },
+        {
+          "id": "d",
+          "text": "loadable components 只能用來載入 CSS，不能用來動態載入 JavaScript 元件"
+        }
+      ],
+      "answer": "a",
+      "explanation": "react-loadable／@loadable/component 是 code-splitting 生態系裡「官方方案還不夠完善時，社群先補上」的典型案例，尤其是 SSR 場景下的動態載入曾經一度是 React.lazy 的弱項（前面 ri-8 章節談過同步 SSR 對 Suspense/lazy 的限制），這也是這類第三方套件當時仍有其存在價值的原因，隨著官方方案（如串流 SSR）逐漸完善，依賴這些套件的必要性也隨之下降。",
+      "verify": {
+        "checks": [],
+        "manual": "第三方 loadable components 套件未安裝於本專案，需要真實套件執行才能觀察其 SSR 支援，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-26-q4",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "route-based code splitting：以「頁面」為單位做程式碼分割，是最常見、投資報酬率最高的切分粒度",
+      "docs": "",
+      "story": "",
+      "prompt": "一個有 10 個頁面的應用，想導入 code-splitting，但不確定該用什麼粒度切分（每個元件都獨立切一塊？還是整個頁面切一塊？）。「以路由（頁面）為單位」切分，為什麼是常見的起手式？",
+      "code": "const Dashboard = lazy(() => import(\"./pages/Dashboard\"));\nconst Settings = lazy(() => import(\"./pages/Settings\"));\n\n<Routes>\n  <Route path=\"/dashboard\" element={<Dashboard />} />\n  <Route path=\"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/settings\" element={<Settings />} />\n</Routes>",
+      "options": [
+        {
+          "id": "a",
+          "text": "使用者在同一個時間點，通常只會看到『一個頁面』的內容，不同頁面之間天生就有清楚的『這批程式碼現在用不到』的邊界；以路由為單位切分，能用最少的重構成本，換取『使用者只下載目前這個頁面需要的程式碼』這個最大的效益，是投資報酬率很高的起手式。切得比這更細（例如每個小元件都獨立切分）雖然理論上能再省一點，但過多的小 chunk 會增加網路請求數量與管理複雜度，不一定划算"
+        },
+        {
+          "id": "b",
+          "text": "以路由為單位切分是唯一合法的切分方式，React.lazy 不支援對非頁面層級的元件做程式碼分割"
+        },
+        {
+          "id": "c",
+          "text": "路由層級切分完全不會影響應用程式的載入效能，純粹是程式碼組織上的個人偏好"
+        },
+        {
+          "id": "d",
+          "text": "路由層級切分要求整個應用程式必須放棄使用任何全域狀態管理工具"
+        }
+      ],
+      "answer": "a",
+      "explanation": "「使用者在同一時刻通常只看一個頁面」這個自然邊界，讓路由層級成為 code-splitting 最直覺、效益最明顯的切分粒度，這也是 React Router 官方文件直接提供搭配範例的原因。切得更細（元件層級）在特定情境（例如一個很少被打開的巨大 Modal、圖表函式庫）依然有價值，但不是通用的起手式，過度切分反而會增加請求數與維護複雜度。",
+      "verify": {
+        "checks": [],
+        "manual": "路由層級的程式碼分割效益需要真實建置產物與網路請求分析才能量化觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-26-q5",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "windowing／虛擬化：只渲染使用者目前看得到的那一小段清單，而不是全部",
+      "docs": "",
+      "story": "",
+      "prompt": "一份有 10,000 筆資料的清單，一次全部渲染成 10,000 個 DOM 節點，導致捲動卡頓、記憶體佔用過高。windowing（虛擬化）技術想怎麼解決這個問題？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "只實際渲染『使用者目前捲動視窗看得到的那一小段』（例如畫面上看得到的 20 筆，加上上下各緩衝幾筆），其餘 9,900 多筆完全不建立對應的 DOM 節點；使用者捲動時，動態計算目前該顯示哪些項目、卸載捲出畫面的舊項目、掛載捲進畫面的新項目，讓實際存在的 DOM 節點數量始終維持在一個小範圍內，不管資料總筆數有多大，效能表現都差不多"
+        },
+        {
+          "id": "b",
+          "text": "windowing 是把整份清單資料先壓縮成一個檔案，下載完成後才一次性解壓縮渲染"
+        },
+        {
+          "id": "c",
+          "text": "windowing 純粹是 CSS 層面的技巧（例如用 overflow: hidden），不影響實際建立的 DOM 節點數量"
+        },
+        {
+          "id": "d",
+          "text": "windowing 要求後端一次把所有 10,000 筆資料都不分頁地傳給前端，這樣才能正確運作"
+        }
+      ],
+      "answer": "a",
+      "explanation": "windowing（也稱虛擬清單／虛擬捲動）的核心思路是「只渲染看得到的部分」，這跟一次全部渲染、用 CSS 隱藏其餘部分完全不同——後者仍然要付出建立大量 DOM 節點的成本，前者從根本上避免了這個成本。react-window、react-virtualized 是 React 生態系裡實作這個技巧的常見函式庫，適合資料量很大、單筆項目版面相對一致的清單場景。",
+      "verify": {
+        "checks": [],
+        "manual": "虛擬化清單需要真實瀏覽器捲動互動與 DOM 節點數量觀察才能驗證效果，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-26-q6",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "CSS-in-JS 該不該用，取決於團隊需求，不是無條件推薦",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊在討論新專案要不要導入 CSS-in-JS（如 styled-components、Emotion）。什麼情境下這類方案的優勢比較明顯，什麼情境下傳統 CSS／CSS Modules 可能更合適？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "CSS-in-JS 在『樣式需要頻繁依 props／state 動態變化』『元件庫需要跟 JS 邏輯緊密封裝在同一個檔案』的情境下優勢明顯；但它有執行期額外的效能開銷（前面 ri-6 章節談過），如果專案的樣式相對靜態、已經有一套穩定的 design system、或者對執行期效能特別敏感（例如效能受限的裝置），CSS Modules 或 Tailwind 這類建置期就決定好樣式的方案通常更划算。沒有哪一種方案在所有情境下都無條件優於另一種"
+        },
+        {
+          "id": "b",
+          "text": "CSS-in-JS 在任何情境下都應該被優先採用，傳統 CSS 方案已經完全過時"
+        },
+        {
+          "id": "c",
+          "text": "CSS-in-JS 唯一的用途是取代 JavaScript 的邏輯運算，跟樣式完全無關"
+        },
+        {
+          "id": "d",
+          "text": "CSS Modules 與 CSS-in-JS 在瀏覽器最終渲染出的效果與效能表現上完全沒有任何差異"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這題延續前面 ri-6 章節談過的 CSS-in-JS 取捨，強調的是「沒有放諸四海皆準的最佳選擇」——樣式需求的動態程度、團隊對執行期效能的敏感度、既有 design system 的成熟度，都是實際決策時該納入考量的變數，技術選型的成熟判斷永遠是「什麼情境適合什麼工具」，不是「哪個工具絕對最好」。",
+      "verify": {
+        "checks": [],
+        "manual": "屬技術選型取捨的推理題，無可執行程式碼。"
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-27-misc-error-boundaries.json b/packages/core/src/data/questions/ri-27-misc-error-boundaries.json
new file mode 100644
index 0000000..35fe606
--- /dev/null
+++ b/packages/core/src/data/questions/ri-27-misc-error-boundaries.json
@@ -0,0 +1,198 @@
+{
+  "id": "ri-27",
+  "title": "React 進階探索：Error Boundary 深入",
+  "questions": [
+    {
+      "id": "ri-27-q1",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "componentDidCatch(error, info) 的第二個參數提供元件堆疊資訊",
+      "docs": "https://react.dev/reference/react/Component#componentdidcatch",
+      "story": "",
+      "prompt": "componentDidCatch 這個生命週期方法接收兩個參數。第二個參數 info 裡的 componentStack，內容大致是什麼？",
+      "code": "class ErrorBoundary extends React.Component {\n  state = { hasError: false };\n  static getDerivedStateFromError() {\n    return { hasError: true };\n  }\n  componentDidCatch(error, info) {\n    console.log(error.message);\n    console.log(typeof info.componentStack);\n  }\n  render() {\n    if (this.state.hasError) return <p>發生錯誤了</p>;\n    return this.props.children;\n  }\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "info.componentStack 是一段字串，記錄『拋出錯誤的那個元件，在元件樹裡是被哪些父層元件層層包裹著』的完整路徑（類似瀏覽器原生錯誤的 stack trace，但這裡記的是 React 元件的巢狀關係，不是 JS 函式呼叫堆疊）；這讓開發者能快速定位『這個錯誤是在畫面的哪個區塊、哪個元件層級發生的』，而不只是知道『哪個函式拋出了這個錯誤』"
+        },
+        {
+          "id": "b",
+          "text": "componentStack 是一個布林值，代表這個錯誤是否已經被其他 Error Boundary 攔截過"
+        },
+        {
+          "id": "c",
+          "text": "componentStack 是拋出錯誤那個元件的 props 物件快照"
+        },
+        {
+          "id": "d",
+          "text": "componentDidCatch 只接收一個參數，不存在第二個 info 參數"
+        }
+      ],
+      "answer": "a",
+      "explanation": "componentDidCatch(error, info) 的第二個參數是專門給 Error Boundary 用的除錯資訊，componentStack 這段字串記錄的是「元件層級」的巢狀路徑，補足了原生 JS 錯誤堆疊只看得到函式呼叫關係、看不出 React 元件樹結構的落差，在除錯『這個錯誤發生在畫面哪個區塊』時特別有用。",
+      "verify": {
+        "checks": [],
+        "manual": "componentDidCatch 需要真實的用戶端渲染與子元件拋錯才能觸發並觀察 componentStack 內容，無法用 renderToStaticMarkup 或 node -e 驗證（前面 ri-7 章節已驗證同步 SSR 不會觸發 Error Boundary）。"
+      }
+    },
+    {
+      "id": "ri-27-q2",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "Error Boundary 攔不到的幾種情境：事件處理器、非同步程式碼、SSR、自己拋的錯",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊在整個應用程式外層包了一個 Error Boundary，以為所有錯誤都會被攔截、顯示成統一的錯誤畫面。結果一個按鈕的 onClick 事件處理器裡拋出的錯誤，完全沒有被攔到——只是這次點擊觸發的 handleClick 執行到一半中斷，console 出現一個未捕捉的例外，畫面其他部分仍正常運作，也沒有出現任何 Error Boundary 的備援畫面。為什麼 Error Boundary 沒有生效？",
+      "code": "function Button() {\n  function handleClick() {\n    throw new Error(\"boom\"); // 事件處理器裡拋出的錯誤\n  }\n  return <button onClick={handleClick}>點我</button>;\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "Error Boundary 只攔截『渲染過程』中拋出的錯誤（元件函式執行、生命週期方法執行期間），不包含事件處理器裡的錯誤、非同步程式碼（setTimeout、Promise）裡的錯誤，也不包含伺服器端渲染期間的錯誤（前面 ri-7 章節已驗證過）；事件處理器裡的錯誤需要自己用一般的 try/catch 包住，或搭配全域的錯誤監控工具（如 window.onerror）才能攔截，Error Boundary 這個機制的設計範圍從一開始就限定在渲染階段"
+        },
+        {
+          "id": "b",
+          "text": "Error Boundary 應該要能攔截所有情境的錯誤，這裡沒有攔到是因為套件版本過舊的 bug"
+        },
+        {
+          "id": "c",
+          "text": "問題出在 Error Boundary 沒有包在 <Suspense> 裡面，兩者必須搭配使用才能攔截事件處理器的錯誤"
+        },
+        {
+          "id": "d",
+          "text": "事件處理器裡的錯誤只有在 React 19 之後的版本才能被 Error Boundary 攔截，這個專案的版本太舊"
+        }
+      ],
+      "answer": "a",
+      "explanation": "「Error Boundary 只管渲染階段」是官方文件明確劃定的邊界，這也是它常讓新手誤判涵蓋範圍的地方：事件處理器、setTimeout／Promise 這類非同步回呼、伺服器端渲染，都在這個邊界之外。事件處理器裡的錯誤處理，官方建議直接用一般的 try/catch 包住易出錯的邏輯，這是完全不同的錯誤處理機制，不能靠 Error Boundary 一次涵蓋所有情境。",
+      "verify": {
+        "checks": [],
+        "manual": "事件處理器內拋出的錯誤需要真實瀏覽器點擊互動才能觸發並觀察是否被攔截，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-27-q3",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "React 16 起，渲染階段的未捕捉錯誤會讓整棵元件樹被卸載，而不是停留在半毀壞的畫面",
+      "docs": "",
+      "story": "",
+      "prompt": "React 16 之前，一個元件渲染時拋出的未捕捉錯誤，可能只會讓畫面停留在『部分損壞、UI 顯示不完整』的狀態。React 16 起，如果沒有任何 Error Boundary 攔截這個錯誤，行為改成了什麼？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "React 16 起，渲染階段一旦出現沒有被任何 Error Boundary 攔截的錯誤，會把『整棵』受影響的元件樹（不只是拋錯的那個元件）從畫面上完全卸載，而不是讓應用程式停留在一個不完整、可能顯示錯誤或誤導資訊的『半毀壞』畫面；這是刻意的設計決策——寧可讓使用者看到空白（配合 Error Boundary 顯示合理的備援畫面），也不要讓使用者看到一個邏輯已經壞掉、卻表面上看起來還在運作的 UI"
+        },
+        {
+          "id": "b",
+          "text": "React 16 起，未捕捉的渲染錯誤會被自動忽略，畫面照樣正常顯示，不會有任何變化"
+        },
+        {
+          "id": "c",
+          "text": "React 16 起，未捕捉的錯誤會自動重試渲染三次，三次都失敗才會卸載元件樹"
+        },
+        {
+          "id": "d",
+          "text": "這個行為在 React 16 前後完全沒有任何改變"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這是 React 16 一項重要但容易被忽略的行為改變：與其冒著讓使用者看到一個邏輯已經壞掉、卻可能還顯示著誤導性內容的畫面，不如乾脆卸載掉受影響的整棵樹。這也直接提高了 Error Boundary 的重要性——沒有妥善布建 Error Boundary，一個原本只影響小範圍的渲染錯誤，可能會讓一大片（甚至整個）UI 消失。",
+      "verify": {
+        "checks": [],
+        "manual": "整棵樹卸載的行為需要真實用戶端渲染環境搭配未捕捉錯誤才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-27-q4",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "Error Boundary 該放在哪：依「希望多大範圍一起失效」決定放置的層級",
+      "docs": "",
+      "story": "",
+      "prompt": "一個頁面同時有「側邊導覽列」跟「主要內容區塊」。主要內容區塊裡某個元件渲染出錯時，理想的使用者體驗是側邊導覽列依然正常顯示、可以正常導頁離開，只有主要內容區塊顯示錯誤訊息。Error Boundary 該放在哪一層？",
+      "code": "// 好的做法：分別包住彼此獨立的區塊\n<Layout>\n  <Sidebar />\n  <ErrorBoundary fallback={<p>內容載入失敗</p>}>\n    <MainContent />\n  </ErrorBoundary>\n</Layout>\n\n// 不好的做法：整個頁面共用一個 Error Boundary\n<ErrorBoundary fallback={<p>發生錯誤了</p>}>\n  <Layout>\n    <Sidebar />\n    <MainContent />\n  </Layout>\n</ErrorBoundary>",
+      "options": [
+        {
+          "id": "a",
+          "text": "把 Error Boundary 放在『各自獨立、希望彼此不互相拖累』的區塊外層，而不是整個頁面共用一個：這裡把 Error Boundary 放在 MainContent 外面，Sidebar 出錯不會影響 MainContent，反過來 MainContent 出錯也不會連累 Sidebar 一起消失。如果 Error Boundary 只放在最外層包住整個頁面，任何一個小區塊出錯，都會讓整頁（包含原本運作正常的 Sidebar）一起顯示備援畫面，影響範圍被不必要地放大"
+        },
+        {
+          "id": "b",
+          "text": "Error Boundary 只能放在整個應用程式的最外層，不能包住頁面內部的局部區塊"
+        },
+        {
+          "id": "c",
+          "text": "Error Boundary 的放置位置對錯誤影響範圍完全沒有任何差異，放哪裡效果都一樣"
+        },
+        {
+          "id": "d",
+          "text": "Error Boundary 應該包住每一個最小的 DOM 元素，粒度越細越好，沒有任何取捨"
+        }
+      ],
+      "answer": "a",
+      "explanation": "Error Boundary 的放置粒度直接決定「一個錯誤會拖累多大範圍」，這是實務上需要依產品體驗權衡的設計決策：太粗（只放最外層）會讓小範圍錯誤波及整頁；太細（每個最小元素都包一層）會增加大量樣板程式碼、也不見得每個地方都需要獨立的錯誤隔離。常見的合理做法是依「使用者體驗上，這幾塊彼此獨立、希望能各自失效互不影響」的功能區塊邊界來放置。",
+      "verify": {
+        "checks": [],
+        "manual": "Error Boundary 影響範圍的實際使用者體驗需要真實渲染錯誤情境才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-27-q5",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "元件堆疊資訊的好處：定位錯誤發生在哪個畫面區塊，而不只是哪一行程式碼",
+      "docs": "",
+      "story": "",
+      "prompt": "只看瀏覽器原生的 JavaScript 錯誤堆疊（哪個函式呼叫了哪個函式），跟額外看 Error Boundary 提供的元件堆疊（componentStack），兩者能幫忙定位問題的角度有什麼不同？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "JS 原生堆疊回答『這個錯誤是被哪一連串函式呼叫觸發的』（程式碼執行路徑的角度）；元件堆疊回答『這個錯誤發生在畫面上、元件樹的哪個位置』（UI 結構的角度）——同一個工具函式如果被多個不同畫面區塊共用，光看 JS 堆疊可能看不出『這次是哪個畫面在用它時出錯』，元件堆疊能直接告訴你『是 Sidebar 裡的 UserAvatar，還是 MainContent 裡的 CommentList 用到它時出的錯』，兩種資訊互補，一起看能更快定位問題"
+        },
+        {
+          "id": "b",
+          "text": "兩者提供的資訊完全相同，只是呈現格式不同"
+        },
+        {
+          "id": "c",
+          "text": "元件堆疊只在正式環境（production build）才會顯示，開發模式反而看不到"
+        },
+        {
+          "id": "d",
+          "text": "JS 原生堆疊在使用 React 之後會完全消失，只剩下元件堆疊可以參考"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這兩種堆疊資訊分別對應「程式碼執行路徑」與「UI 結構位置」這兩個不同的除錯視角，在共用元件、共用工具函式的專案裡特別互補——單看其中一種常常不足以快速定位問題，元件堆疊補足了原生堆疊看不到的『這是畫面上哪個區塊』這層資訊。",
+      "verify": {
+        "checks": [],
+        "manual": "屬除錯資訊互補性的概念說明題，無可執行程式碼佐證兩種堆疊格式的實際呈現差異。"
+      }
+    },
+    {
+      "id": "ri-27-q6",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "getDerivedStateFromError（算 state，無副作用）vs componentDidCatch（處理副作用，如記錄錯誤）",
+      "docs": "",
+      "story": "",
+      "prompt": "一個完整的 Error Boundary 通常會同時定義 static getDerivedStateFromError() 跟 componentDidCatch()，而不是只寫其中一個。這兩者的分工是什麼？",
+      "code": "class ErrorBoundary extends React.Component {\n  state = { hasError: false };\n  static getDerivedStateFromError(error) {\n    return { hasError: true }; // 只回傳新 state，不做任何副作用\n  }\n  componentDidCatch(error, info) {\n    logErrorToService(error, info.componentStack); // 副作用：回報錯誤到監控服務\n  }\n  render() {\n    if (this.state.hasError) return <p>發生錯誤了</p>;\n    return this.props.children;\n  }\n}",
+      "options": [
+        { "id": "a", "text": "getDerivedStateFromError 是一個靜態方法，只負責『根據這個錯誤，算出新的 state 該長什麼樣』，官方明確要求它不能有副作用（不能在裡面呼叫 API、寫 log）；componentDidCatch 才是允許執行副作用的地方，通常用來把錯誤回報給監控服務。兩者刻意分開，是延續 React『state 計算』與『副作用執行』要分開的一貫設計原則" },
+        { "id": "b", "text": "兩者功能完全重複，隨便留一個、刪掉另一個都不會有任何影響" },
+        { "id": "c", "text": "getDerivedStateFromError 才是用來記錄錯誤到監控服務的地方，componentDidCatch 只負責算 state" },
+        { "id": "d", "text": "只有 componentDidCatch 是必要的，getDerivedStateFromError 是已經被棄用的舊 API" }
+      ],
+      "answer": "a",
+      "explanation": "這組分工呼應 React 一貫的設計哲學：『算出下一個 state』跟『執行副作用』是兩件事，該放在不同的地方（這也是 reducer 必須是純函式、useEffect 才能做副作用的同一套原則）。getDerivedStateFromError 只管當機時 state 該變成什麼樣，componentDidCatch 才是记錄、上報這類有副作用的操作該待的地方，兩者都保留、各司其職，才是官方建議的完整寫法。",
+      "verify": {
+        "checks": [],
+        "manual": "getDerivedStateFromError／componentDidCatch 需要真實用戶端渲染與子元件拋錯才能觸發並觀察兩者各自的呼叫時機，無法用 renderToStaticMarkup 或 node -e 驗證。"
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-28-misc-component-conventions.json b/packages/core/src/data/questions/ri-28-misc-component-conventions.json
new file mode 100644
index 0000000..bd05624
--- /dev/null
+++ b/packages/core/src/data/questions/ri-28-misc-component-conventions.json
@@ -0,0 +1,332 @@
+{
+  "id": "ri-28",
+  "title": "React 進階探索：元件慣例與表單生態",
+  "questions": [
+    {
+      "id": "ri-28-q1",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "displayName：讓 HOC 包裝過的元件，在 DevTools 裡顯示有意義的名字，而不是 Anonymous",
+      "docs": "https://react.dev/reference/react/Component#static-displayname",
+      "story": "",
+      "prompt": "一個 HOC 把元件包了一層之後，回傳的新元件在 React DevTools 裡顯示成 \"Anonymous\" 或一個看不出來源的名字，很難分辨『這是包裝了哪個原始元件的版本』。displayName 怎麼解決這個除錯困擾？",
+      "code": "function withLogging(WrappedComponent) {\n  function Wrapped(props) {\n    return <WrappedComponent {...props} />;\n  }\n  Wrapped.displayName = `WithLogging(${WrappedComponent.displayName || WrappedComponent.name})`;\n  return Wrapped;\n}\n\nfunction Button() { return <button />; }\nconst LoggedButton = withLogging(Button);\nconsole.log(LoggedButton.displayName);",
+      "options": [
+        {
+          "id": "a",
+          "text": "手動設定 displayName 這個靜態屬性，讓 React DevTools 顯示這個自訂的名稱，而不是函式本身的名字（HOC 回傳的包裝函式常常是匿名或名稱不具辨識度）；這裡組合成 WithLogging(Button) 這種『HOC名稱(原始元件名稱)』的慣例寫法，讓除錯時能一眼看出這是哪個原始元件被哪個 HOC 包裝過的結果，是撰寫可重用 HOC 時的推薦實踐"
+        },
+        {
+          "id": "b",
+          "text": "displayName 只是一個裝飾性屬性，React DevTools 完全不會讀取它，永遠顯示函式本身的名字"
+        },
+        {
+          "id": "c",
+          "text": "displayName 只能設定在 class component 上，函式元件無法使用這個屬性"
+        },
+        {
+          "id": "d",
+          "text": "設定 displayName 之後，這個元件就無法再被其他 HOC 繼續包裝"
+        }
+      ],
+      "answer": "a",
+      "explanation": "displayName 是 React 元件（函式或 class 都適用）上的一個靜態屬性，DevTools 顯示元件樹時會優先讀取它。HOC 這種『動態產生包裝元件』的模式特別需要它——不設定的話，DevTools 很難分辨一長串巢狀的 HOC 包裝分別對應到哪個原始元件，組合成慣例格式的 displayName 是解決這個除錯痛點的標準做法。",
+      "verify": {
+        "checks": [
+          {
+            "code": "function withLogging(WrappedComponent) {\n  function Wrapped(props) {\n    return null;\n  }\n  Wrapped.displayName = `WithLogging(${WrappedComponent.displayName || WrappedComponent.name})`;\n  return Wrapped;\n}\nfunction Button() { return null; }\nconst LoggedButton = withLogging(Button);\nconsole.log(LoggedButton.displayName);",
+            "expected": "WithLogging(Button)"
+          }
+        ]
+      }
+    },
+    {
+      "id": "ri-28-q2",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "React 應用的瀏覽器支援範圍：由 React 本身與專案的建置設定共同決定",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊被問到「這個 React 應用支援 IE11 嗎？」該怎麼判斷，而不是憑印象回答？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "瀏覽器支援範圍取決於兩層：①React 本身這個版本官方支援到哪些瀏覽器（新版 React 通常鎖定現代瀏覽器，逐步放棄對非常舊的瀏覽器如 IE 的支援）；②專案的建置工具設定（如 browserslist 設定、是否引入了必要的 polyfill）決定最終產出的 JS/CSS 能不能在目標瀏覽器上正確執行。要準確回答，得同時檢查 React 版本的官方支援聲明，以及專案自己的建置設定，不是單看其中一項就能下定論"
+        },
+        {
+          "id": "b",
+          "text": "React 應用永遠能在任何瀏覽器上正常運作，不受瀏覽器版本影響"
+        },
+        {
+          "id": "c",
+          "text": "瀏覽器支援完全由使用者的作業系統決定，跟 React 或建置工具設定無關"
+        },
+        {
+          "id": "d",
+          "text": "只要專案有安裝 TypeScript，就自動具備所有瀏覽器的完整相容性"
+        }
+      ],
+      "answer": "a",
+      "explanation": "「支援哪些瀏覽器」是一個需要具體查證、而非憑印象回答的問題——React 核心版本的支援聲明、專案建置工具的 polyfill／transpile 設定，兩者共同決定實際的相容範圍。這也是為什麼同一份 React 程式碼，在不同專案的建置設定下，對舊瀏覽器的相容性可能完全不同。",
+      "verify": {
+        "checks": [],
+        "manual": "瀏覽器相容性需要在目標瀏覽器實際開啟測試才能驗證，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-28-q3",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "React 支援絕大多數標準 HTML 屬性，也支援 aria-* 與 data-* 這類非標準但慣例明確的屬性",
+      "docs": "https://react.dev/reference/react-dom/components/common",
+      "story": "",
+      "prompt": "想在一個 div 上同時加標準 HTML 屬性 title、無障礙屬性 aria-label、跟自訂的 data-testid，這三種屬性能不能在同一個元素上混用？",
+      "code": "function Card() {\n  return (\n    <div title=\"卡片\" aria-label=\"使用者卡片\" data-testid=\"user-card\">\n      內容\n    </div>\n  );\n}\n\nconsole.log(renderToStaticMarkup(<Card />));",
+      "options": [
+        {
+          "id": "a",
+          "text": "可以混用，三者都會正確輸出到最終的 HTML：title 是標準 HTML 全域屬性；aria-* 開頭的屬性是無障礙（ARIA）規範定義的屬性，React 完整支援；data-* 開頭的屬性是 HTML 規範明確保留給開發者自訂使用的『資料屬性』，這正好呼應前面 ri-15 章節談過『React 16 起支援自訂屬性透傳』——只是 data-*／aria-* 這兩種前綴，即使在 React 16 之前的舊版也一直都受到支援，不受那條規則放寬的影響"
+        },
+        {
+          "id": "b",
+          "text": "只能擇一使用，同一個元素不能同時擁有標準屬性、ARIA 屬性與自訂資料屬性"
+        },
+        {
+          "id": "c",
+          "text": "aria-label 只能用在 class component 渲染出的元素上，函式元件不支援"
+        },
+        {
+          "id": "d",
+          "text": "data-testid 這種屬性只在測試環境下才會被渲染，正式環境會被自動移除"
+        }
+      ],
+      "answer": "a",
+      "explanation": "HTML 標準屬性、ARIA 屬性、data-* 自訂屬性三者可以自由並存在同一個元素上，這是原生 HTML／DOM 規範本身就允許的事，React 完整支援、原樣輸出，不會因為環境是開發還是正式模式而有任何差異，也不限定只能用在特定類型的元件上。",
+      "verify": {
+        "checks": [
+          {
+            "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Card() {\n  return (\n    <div title=\"卡片\" aria-label=\"使用者卡片\" data-testid=\"user-card\">\n      內容\n    </div>\n  );\n}\nconsole.log(renderToStaticMarkup(<Card />));",
+            "expected": "<div title=\"卡片\" aria-label=\"使用者卡片\" data-testid=\"user-card\">內容</div>"
+          }
+        ]
+      }
+    },
+    {
+      "id": "ri-28-q4",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "布林型 prop 可以省略值，直接寫屬性名稱等同傳 true",
+      "docs": "https://react.dev/learn/passing-props-to-a-component",
+      "story": "",
+      "prompt": "一個 Checkbox 元件的 disabled prop 是布林值。下面兩種寫法，效果一樣嗎？",
+      "code": "function Checkbox({ disabled }) {\n  return <p>disabled: {String(disabled)}</p>;\n}\n\nconsole.log(renderToStaticMarkup(<Checkbox disabled={true} />));\nconsole.log(renderToStaticMarkup(<Checkbox disabled />));",
+      "options": [
+        {
+          "id": "a",
+          "text": "效果一樣：JSX 有一條慣例語法糖——屬性只寫名稱、不給值（如 disabled），等同於 disabled={true}；這條規則只對『省略值』的情境生效，如果要傳 false，必須明確寫成 disabled={false}，不能靠省略達成（省略永遠等同 true，不存在『省略等於 false』的寫法）"
+        },
+        {
+          "id": "b",
+          "text": "不一樣，disabled（沒有值）等同於 disabled={false}，跟 disabled={true} 效果相反"
+        },
+        {
+          "id": "c",
+          "text": "不一樣，disabled（沒有值）會被當成字串 \"disabled\"，不是布林值"
+        },
+        {
+          "id": "d",
+          "text": "這段程式碼會拋出例外，JSX 屬性不能省略等號後面的值"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這是 JSX 對布林 prop 提供的一條語法糖，源自 HTML 本身『某些屬性只要出現就代表啟用』的慣例（如原生的 disabled、checked）。要注意這條規則是單向的——只有『省略值』才等同 true，沒有對稱的『省略等於 false』寫法，false 永遠得顯式寫出來。",
+      "verify": {
+        "checks": [
+          {
+            "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Checkbox({ disabled }) {\n  return <p>disabled: {String(disabled)}</p>;\n}\nconsole.log(renderToStaticMarkup(<Checkbox disabled={true} />));\nconsole.log(renderToStaticMarkup(<Checkbox disabled />));",
+            "expected": "<p>disabled: true</p>\n<p>disabled: true</p>"
+          }
+        ]
+      }
+    },
+    {
+      "id": "ri-28-q5",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "Next.js：在 React 之上加上路由、SSR/SSG、API 路由等應用框架能力",
+      "docs": "",
+      "story": "",
+      "prompt": "React 本身只是一個 View 層函式庫（前面 ri-13 章節談過），不內建路由、伺服器端渲染這些能力。Next.js 這類「React 框架」在這之上補足了什麼？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "Next.js 在 React 核心之上，內建了檔案系統路由（依資料夾/檔名自動產生路由，不用手動設定 React Router）、伺服器端渲染／靜態網站生成（SSR/SSG）、API 路由（在同一個專案裡寫後端 API 端點）、圖片與字型最佳化等一整套應用程式框架能力，把『React 只是 View 層』這件事的其餘拼圖（路由、資料抓取策略、部署）補齊，讓開發者不用從零手動組裝各個第三方套件"
+        },
+        {
+          "id": "b",
+          "text": "Next.js 是一個完全獨立於 React 的框架，兩者的元件語法互不相容"
+        },
+        {
+          "id": "c",
+          "text": "Next.js 唯一的功能是提供 CSS 樣式方案，跟路由、伺服器端渲染無關"
+        },
+        {
+          "id": "d",
+          "text": "使用 Next.js 之後就不能再使用任何 React Hooks"
+        }
+      ],
+      "answer": "a",
+      "explanation": "Next.js 是「React 框架」這個類別的代表：以 React 為核心，補齊路由、渲染策略（SSR/SSG/ISR）、API 層這些「完整應用程式」通常需要、但 React 本身刻意不內建的能力（呼應前面 ri-13 章節談過 React 的定位限制）。它跟 React 語法完全相容，Hooks、元件寫法都照常使用。",
+      "verify": {
+        "checks": [],
+        "manual": "Next.js 未安裝於本專案，框架功能需要真實建置與伺服器環境才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-28-q6",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "傳遞事件處理器：直接傳函式參考，不要在 JSX 裡直接呼叫它",
+      "docs": "https://react.dev/learn/responding-to-events",
+      "story": "",
+      "prompt": "onClick={handleClick} 跟 onClick={handleClick()} 這兩種寫法，效果一樣嗎？",
+      "code": "function Button() {\n  function handleClick() {\n    console.log(\"clicked\");\n  }\n  return (\n    <div>\n      <button id=\"a\" onClick={handleClick}>正確寫法</button>\n      <button id=\"b\" onClick={handleClick()}>錯誤寫法</button>\n    </div>\n  );\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "不一樣：onClick={handleClick} 傳的是『函式本身的參考』，React 會在使用者真正點擊時才呼叫它；onClick={handleClick()} 因為多了一組括號，代表『立刻呼叫 handleClick()』，這個呼叫會在渲染當下（元件函式執行時）就立即執行一次，而它的回傳值（這裡是 undefined，因為 handleClick 沒有 return 任何東西）才是最終被賦值給 onClick 的內容——結果是點擊 id=\"b\" 這顆按鈕完全沒有反應，因為 onClick 收到的其實是 undefined，不是一個函式"
+        },
+        {
+          "id": "b",
+          "text": "兩者效果完全相同，React 會自動判斷該不該在渲染當下呼叫這個函式"
+        },
+        {
+          "id": "c",
+          "text": "onClick={handleClick()} 才是正確寫法，onClick={handleClick} 會導致按鈕永遠無法點擊"
+        },
+        {
+          "id": "d",
+          "text": "兩種寫法都會拋出例外，事件處理器不能用這兩種方式傳遞"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這是新手最常犯的錯誤之一，根源在於混淆了『傳遞一個函式』跟『呼叫一個函式、傳遞它的結果』：多了括號就是立即呼叫，這在渲染階段就會執行（而不是等待點擊），而且執行結果通常不是一個函式，導致真正點擊時 React 找不到有效的處理器可以呼叫。需要『帶參數呼叫』時，正確做法是用一個箭頭函式包起來（如 onClick={() => handleClick(id)}），而不是直接呼叫。",
+      "verify": {
+        "checks": [
+          {
+            "code": "let calls = 0;\nfunction handleClick() {\n  calls++;\n  return undefined;\n}\nconst passedAsReference = handleClick;\nconst passedAsCallResult = handleClick();\nconsole.log(calls, typeof passedAsReference, typeof passedAsCallResult);",
+            "expected": "1 function undefined"
+          }
+        ]
+      }
+    },
+    {
+      "id": "ri-28-q7",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "防止函式被連續呼叫多次：debounce／throttle，或用旗標鎖住重複觸發",
+      "docs": "",
+      "story": "",
+      "prompt": "一個「送出訂單」按鈕，使用者手滑連續點擊了三下，結果送出了三筆重複的訂單。該怎麼防止同一個函式在短時間內被重複觸發？",
+      "code": "function OrderButton() {\n  const [isSubmitting, setIsSubmitting] = useState(false);\n\n  async function handleSubmit() {\n    if (isSubmitting) return; // 用旗標鎖住，避免重複觸發\n    setIsSubmitting(true);\n    try {\n      await submitOrder();\n    } finally {\n      setIsSubmitting(false); // 無論成功或拋出例外都會執行，避免旗標卡在 true\n    }\n  }\n\n  return <button onClick={handleSubmit} disabled={isSubmitting}>送出訂單</button>;\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "用一個『正在處理中』的旗標（這裡是 isSubmitting 這份 state）在函式一開頭就檢查，處理中就直接 return、不重複執行；同時搭配把按鈕 disabled 掉，從使用者互動的源頭就防止重複點擊。另外要注意 await submitOrder() 這段要包在 try/finally 裡，把 setIsSubmitting(false) 放進 finally——這樣不管送出成功還是拋出例外，旗標都保證會被重置，不會因為送出失敗就讓按鈕永遠卡在 disabled 狀態。另一種常見手法是用 debounce（等使用者停止操作一段時間才真正執行一次）或 throttle（固定時間內最多執行一次），適合搜尋框打字這類高頻率觸發的場景，跟這裡『防止表單重複送出』的旗標鎖手法側重點略有不同"
+        },
+        {
+          "id": "b",
+          "text": "React 會自動防止同一個函式在短時間內被重複呼叫，不需要開發者額外處理"
+        },
+        {
+          "id": "c",
+          "text": "唯一的解法是把按鈕從畫面上完全移除，讓使用者無法再次點擊"
+        },
+        {
+          "id": "d",
+          "text": "只要函式宣告成 async，就會自動具備防止重複呼叫的能力"
+        }
+      ],
+      "answer": "a",
+      "explanation": "「防止重複觸發」在不同情境下有不同的合適手法：表單送出這種『同一個操作不該重複執行』的場景，旗標鎖（搭配 disabled 按鈕）最直接；搜尋框打字這種『使用者操作結束後才需要真正執行一次』的場景，debounce 更合適；捲動、resize 這種『持續觸發，但只需要固定頻率反應』的場景，throttle 更合適。React 本身不會自動處理這些情境，需要開發者依實際需求選擇對應的手法。另外旗標鎖本身也要注意一個細節：把重置旗標的程式碼放進 try/finally 的 finally 區塊，才能保證不管 submitOrder() 成功還是拋出例外，isSubmitting 都會被重置成 false；如果只在成功路徑（或 try 區塊結尾）重置，一旦送出失敗，旗標會卡在 true、按鈕永遠停在 disabled，使用者從此再也無法重新送出。",
+      "verify": {
+        "checks": [],
+        "manual": "重複點擊防止需要真實瀏覽器連續點擊互動才能觀察效果，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-28-q8",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "更新已經渲染出的元素：不是直接改 DOM，而是改變驅動它的 state/props、讓 React 重新渲染",
+      "docs": "",
+      "story": "",
+      "prompt": "畫面上已經顯示了一段文字「Hello」，現在想把它改成「Hi」。在 React 裡，正確的做法是直接找到那個 DOM 節點、呼叫 node.textContent = \"Hi\" 修改嗎？",
+      "code": "// 錯誤示範：繞過 React，直接操作 DOM\ndocument.getElementById(\"greeting\").textContent = \"Hi\";\n\n// 正確做法：改變驅動畫面的 state，讓 React 重新渲染\nfunction Greeting() {\n  const [text, setText] = useState(\"Hello\");\n  return (\n    <div>\n      <p id=\"greeting\">{text}</p>\n      <button onClick={() => setText(\"Hi\")}>改成 Hi</button>\n    </div>\n  );\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "不建議：直接用原生 DOM API 繞過 React 手動修改內容，會讓這個節點的實際內容跟 React 內部維護的 Virtual DOM 紀錄產生落差——下一次 React 因為其他原因重新渲染這個區域時，很可能會根據它自己記錄的（舊的）狀態把內容改回去，或者出現難以預期的顯示錯誤；正確做法永遠是透過改變驅動這段內容的 state（或 props），讓 React 依照它自己的機制重新渲染，保持『畫面內容』與『React 內部認知』的一致"
+        },
+        {
+          "id": "b",
+          "text": "建議這樣做，直接操作 DOM 比透過 state 更新更有效率，是官方推薦的做法"
+        },
+        {
+          "id": "c",
+          "text": "兩種做法完全等價，React 會自動偵測到外部對 DOM 的修改並同步更新內部狀態"
+        },
+        {
+          "id": "d",
+          "text": "直接操作 DOM 的寫法會導致程式立即拋出例外，無法執行"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這是 React 心智模型最核心的一條紀律：畫面內容永遠應該是 state／props 的『函式』，任何想要的變化都該透過改變這些驅動資料達成，而不是繞過 React 直接動手改 DOM。繞過去修改雖然當下可能看起來有效，卻讓 React 對『這個節點現在長什麼樣』的內部認知跟真實 DOM 產生分歧，之後的重繪很容易出現難以預期的行為。",
+      "verify": {
+        "checks": [],
+        "manual": "React 內部認知與真實 DOM 分歧的後續錯誤行為需要多輪真實互動渲染才能觀察，無法用單次 node 執行驗證。"
+      }
+    },
+    {
+      "id": "ri-28-q9",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "key 只需要在「同一層兄弟節點之間」唯一，不需要整個應用程式全域唯一",
+      "docs": "https://react.dev/learn/rendering-lists#rules-of-keys",
+      "story": "",
+      "prompt": "頁面上有兩份各自獨立的清單（左邊「待辦事項」、右邊「已完成事項」），兩份清單裡都各自用了 key=\"1\"、key=\"2\" 這種簡單的編號，兩邊出現了重複的 key 值。這樣合法嗎？",
+      "code": "<div>\n  <ul>{/* 待辦事項清單 */}\n    <li key=\"1\">買菜</li>\n    <li key=\"2\">倒垃圾</li>\n  </ul>\n  <ul>{/* 已完成事項清單，key 值剛好也是 1、2 */}\n    <li key=\"1\">洗碗</li>\n    <li key=\"2\">拖地</li>\n  </ul>\n</div>",
+      "options": [
+        {
+          "id": "a",
+          "text": "合法：key 只需要在『同一次 .map() 產生的、彼此為兄弟關係的元素之間』保持唯一，不需要在整個應用程式、甚至整個頁面裡全域唯一；這裡兩個 <ul> 底下的 <li> 各自是獨立的兄弟群組，彼此的 key 是否重複完全不影響 React 的判斷，只要『在各自那一組』裡不重複即可"
+        },
+        {
+          "id": "b",
+          "text": "不合法，key 值必須在整個應用程式裡全域唯一，重複使用會導致渲染錯誤"
+        },
+        {
+          "id": "c",
+          "text": "不合法，但只有在兩份清單使用同一個父層元件時才會出問題"
+        },
+        {
+          "id": "d",
+          "text": "合法，但只有字串型別的 key 可以重複，數字型別的 key 必須全域唯一"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這是關於 key 的一個常見誤解：key 的比較範圍是「同一層的兄弟節點」，不是全域命名空間。React 在協調某一組兄弟元素時，只需要在『這一組』裡面能唯一識別每個元素即可，不同群組（不同的 .map() 呼叫、不同的父層）之間的 key 值完全可以重複，不會互相干擾。",
+      "verify": {
+        "checks": [
+          {
+            "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Lists() {\n  return (\n    <div>\n      <ul>\n        <li key=\"1\">買菜</li>\n        <li key=\"2\">倒垃圾</li>\n      </ul>\n      <ul>\n        <li key=\"1\">洗碗</li>\n        <li key=\"2\">拖地</li>\n      </ul>\n    </div>\n  );\n}\nconsole.log(renderToStaticMarkup(<Lists />));",
+            "expected": "<div><ul><li>買菜</li><li>倒垃圾</li></ul><ul><li>洗碗</li><li>拖地</li></ul></div>"
+          }
+        ]
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-29-misc-forms-composition.json b/packages/core/src/data/questions/ri-29-misc-forms-composition.json
new file mode 100644
index 0000000..3008313
--- /dev/null
+++ b/packages/core/src/data/questions/ri-29-misc-forms-composition.json
@@ -0,0 +1,199 @@
+{
+  "id": "ri-29",
+  "title": "React 進階探索：表單生態與組合優先原則",
+  "questions": [
+    {
+      "id": "ri-29-q1",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "表單處理的主流選擇：react-hook-form／Formik 這類「狀態留在元件本地」的方案",
+      "docs": "",
+      "story": "",
+      "prompt": "現在的 React 專案要處理複雜表單（多欄位驗證、巢狀欄位、非同步驗證），普遍會選擇什麼方案，而不是自己從零手刻每個欄位的 state 與驗證邏輯？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "react-hook-form 或 Formik 這類專門處理表單的函式庫：它們把『欄位值管理、驗證規則、提交狀態、錯誤訊息顯示』這些每個表單都會重複遇到的樣板邏輯封裝起來，開發者只需要宣告『有哪些欄位、驗證規則是什麼』，不用每個表單都手刻一遍 useState + 驗證函式；react-hook-form 特別強調盡量用非受控元件＋ref 減少重繪次數，是目前效能表現與開發體驗都受到廣泛採用的選擇"
+        },
+        {
+          "id": "b",
+          "text": "所有表單都應該手動用多個 useState 管理每個欄位，這是官方唯一建議的做法，不該依賴任何第三方函式庫"
+        },
+        {
+          "id": "c",
+          "text": "表單處理必須依賴 Redux 才能運作，沒有全域狀態管理工具就無法處理任何表單邏輯"
+        },
+        {
+          "id": "d",
+          "text": "React 內建了一套完整的表單處理 API，不需要任何額外的函式庫或手動邏輯"
+        }
+      ],
+      "answer": "a",
+      "explanation": "表單邏輯（驗證、錯誤顯示、提交狀態）是高度重複、也容易寫錯的樣板工作，這正是專責函式庫存在的價值。react-hook-form 這幾年特別受歡迎的原因，除了 API 設計簡潔，還在於它刻意減少不必要的重繪（前面 ri-4 章節談過 Redux Form 把每個按鍵都塞進全域 store 的效能代價，react-hook-form 走的是相反的路線）。",
+      "verify": {
+        "checks": [],
+        "manual": "react-hook-form／Formik 未安裝於本專案，實際驗證與提交行為需要真實套件執行才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-29-q2",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "Formik 相對 Redux Form 的優勢：狀態留在元件本地，不需要繞經全域 store",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊原本用 Redux Form（欄位值存進 Redux store），評估改用 Formik（欄位值留在元件本地 state）。除了前面 ri-4 章節談過『高頻按鍵不該進全域 store』這個效能考量，Formik 這類方案還帶來什麼額外好處？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "表單邏輯不再需要跟 Redux 這個特定的全域狀態管理方案綁定——即使專案完全沒有使用 Redux、或未來想換掉 Redux，表單元件也不受影響；同時每個表單實例的狀態天生就是獨立的（不用擔心像 Redux Form 那樣，多個表單共用同一個全域 store 時需要額外處理『表單之間的狀態如何互不干擾』這個問題），元件卸載時表單狀態也自然跟著清除，不需要額外的清理邏輯"
+        },
+        {
+          "id": "b",
+          "text": "Formik 唯一的優勢是套件檔案體積比 Redux Form 小，其餘功能完全相同"
+        },
+        {
+          "id": "c",
+          "text": "Formik 必須跟 Redux 一起安裝才能運作，兩者是互相依賴的關係"
+        },
+        {
+          "id": "d",
+          "text": "Formik 不支援任何形式的欄位驗證，驗證邏輯必須完全自己手刻"
+        }
+      ],
+      "answer": "a",
+      "explanation": "把表單狀態的『依賴範圍』從全域狀態管理方案（Redux）收斂回元件本地，除了效能考量，還帶來架構上的解耦——表單邏輯不再是『必須先有 Redux 才能用』的功能，也天生避免了『多個表單實例共用同一個全域 store，得額外處理彼此狀態不要互相汙染』這類問題，元件卸載後狀態自動消失也更符合直覺。",
+      "verify": {
+        "checks": [],
+        "manual": "屬架構解耦優勢的推理題，無可執行程式碼佐證，需搭配真實套件比較兩者實作差異。"
+      }
+    },
+    {
+      "id": "ri-29-q3",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "React 官方建議「組合優先於繼承」，用 children／props 而不是 class 繼承共用邏輯",
+      "docs": "",
+      "story": "",
+      "prompt": "一個新人有物件導向背景，習慣用『類別繼承』共用程式碼，想寫一個 BaseButton class，再讓 PrimaryButton extends BaseButton 取得樣式與行為。React 官方對這種繼承式的元件設計，抱持什麼態度？",
+      "code": "// 不建議的繼承寫法\nclass BaseButton extends React.Component { /* ... */ }\nclass PrimaryButton extends BaseButton { /* ... */ }\n\n// 建議的組合寫法：用 props／children 傳遞客製化內容\nfunction Button({ variant, children }) {\n  return <button className={variant}>{children}</button>;\n}\nfunction PrimaryButton({ children }) {\n  return <Button variant=\"primary\">{children}</Button>;\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "React 官方文件明確指出，元件之間很少有需要用到『類別繼承』的情境，絕大多數程式碼重用的需求，用『組合』（一個元件把另一個元件當 children 或透過 props 包起來使用，如前面 ri-12 章節談過的 wrapper component）就能達成，而且更靈活、耦合更低；不像類別繼承會讓子類別跟父類別的實作細節緊密綁定，組合讓元件之間的關係更像『使用某個功能』而不是『是某個東西的一種』"
+        },
+        {
+          "id": "b",
+          "text": "React 官方強烈建議所有元件都應該用類別繼承組織，這是撰寫可重用元件的標準做法"
+        },
+        {
+          "id": "c",
+          "text": "React 從技術上完全禁止使用 class 語法的繼承，寫了會直接拋出例外"
+        },
+        {
+          "id": "d",
+          "text": "組合與繼承在 React 元件設計裡完全等價，選哪一種純粹是個人偏好，沒有官方立場"
+        }
+      ],
+      "answer": "a",
+      "explanation": "「組合優先於繼承」是 React 官方文件一段專門討論過的立場：物件導向裡常見的繼承模式，容易讓元件之間產生過度緊密的耦合（子類別要清楚知道父類別的實作細節才能正確覆寫）；React 元件之間透過 props、children 組合彼此的使用方式，職責更清楚、耦合更鬆散，這也是本次新增的多個章節（wrapper component、HOC）反覆展示的設計方向。",
+      "verify": {
+        "checks": [],
+        "manual": "屬官方設計哲學立場的說明題，無可執行程式碼佐證此架構原則的優劣比較。"
+      }
+    },
+    {
+      "id": "ri-29-q4",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "React 元件裡使用 Web Components（自訂元素）的方式，跟一般 HTML 標籤類似",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊想在 React 元件裡使用一個第三方提供、用 Web Components 標準寫成的 <fancy-slider> 自訂元素。可以直接把它當成一般標籤寫進 JSX 裡使用嗎？",
+      "code": "function App() {\n  return (\n    <div>\n      <fancy-slider min={0} max={100}></fancy-slider>\n    </div>\n  );\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "可以：React 把小寫、帶連字號命名的標籤（符合自訂元素命名慣例，如 fancy-slider）當成一般 DOM 標籤直接渲染，瀏覽器認得這是一個已註冊的自訂元素就會正確初始化它。React 19 起，傳給自訂元素的 props 會依這個元素本身有沒有對應的同名『屬性（property）』決定走哪條路：如果這個自訂元素定義了對應的 property，React 會直接把 props 的值（包含物件、陣列、函式這類複雜型別）設成那個 DOM 節點的 property，不會被字串化；只有『元素本身沒有對應 property』的 props，才會退回設成 HTML attribute（這種情況下才只能是字串）。也就是說，能不能直接傳複雜資料，取決於這個自訂元素有沒有定義對應的 property，不是一律只能走字串 attribute。不過自訂事件的監聽仍可能需要額外處理（例如透過 ref 呼叫 addEventListener），這部分沒有改變"
+        },
+        {
+          "id": "b",
+          "text": "不行，React 完全無法在 JSX 裡渲染任何 Web Components 自訂元素"
+        },
+        {
+          "id": "c",
+          "text": "可以，而且複雜資料型別（物件、函式）也能像一般 React 元件一樣直接透過 props 正常傳遞給自訂元素，沒有任何限制"
+        },
+        {
+          "id": "d",
+          "text": "只有用 TypeScript 撰寫的專案才能在 JSX 裡使用 Web Components"
+        }
+      ],
+      "answer": "a",
+      "explanation": "JSX 語法本身能直接寫自訂元素標籤，React 也會把它當成一般 DOM 元素處理。React 19 對自訂元素 props 的實際規則是『看目的元素有沒有對應的 property』：有對應 property 就直接設成 property（物件、陣列、函式都能原樣傳過去，不會被字串化），沒有對應 property 才退回設成 HTML attribute。這跟『複雜資料一律得靠 ref』的舊印象不同——只要第三方自訂元素有把對應的 property 定義出來，React 就能直接傳。自訂事件的監聽則是另一回事，通常還是需要額外處理（例如透過 ref 手動 addEventListener），這部分不受這個 property/attribute 規則影響。",
+      "verify": {
+        "checks": [],
+        "manual": "Web Components 自訂元素需要真實瀏覽器註冊自訂元素定義才能觀察渲染與互動行為，無法用 node -e 或 renderToStaticMarkup 驗證。"
+      }
+    },
+    {
+      "id": "ri-29-q5",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "存取 Web Component 的命令式 API（方法呼叫），要透過 ref 抓到底層節點",
+      "docs": "",
+      "story": "",
+      "prompt": "上一題的 <fancy-slider> 自訂元素提供了一個 reset() 方法（命令式 API，不是透過 attribute 設定）。想在某個按鈕點擊時呼叫它的 reset()，該怎麼做？",
+      "code": "function SliderPanel() {\n  const sliderRef = useRef(null);\n\n  function handleReset() {\n    sliderRef.current.reset(); // 呼叫自訂元素提供的命令式方法\n  }\n\n  return (\n    <div>\n      <fancy-slider ref={sliderRef} min={0} max={100}></fancy-slider>\n      <button onClick={handleReset}>重設</button>\n    </div>\n  );\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "用 ref 抓到這個自訂元素的真實 DOM 節點（前面既有章節多次談過『ref 抓 DOM』的正當用途），透過 sliderRef.current 直接呼叫這個節點上定義的 reset() 方法；這是存取任何『非標準 React props、而是命令式方法』的通用做法，不限於 Web Components，前面 ri-23 章節談過的 useImperativeHandle 解決的也是同一類『透過 ref 呼叫方法』的需求，只是那裡的目標是 React 元件自己定義的方法，這裡是瀏覽器自訂元素原生提供的方法"
+        },
+        {
+          "id": "b",
+          "text": "直接把 reset 當成一般 prop 傳給 fancy-slider，例如 <fancy-slider reset={true} />"
+        },
+        {
+          "id": "c",
+          "text": "無法呼叫，React 元件完全沒有辦法存取 Web Components 提供的任何命令式方法"
+        },
+        {
+          "id": "d",
+          "text": "必須把 fancy-slider 改寫成一個 React 元件才能呼叫它的方法"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這題把「ref 抓 DOM 節點呼叫方法」這個貫穿本次多個章節的技巧（既有 react-11、本次 ri-23 的 useImperativeHandle），應用到 Web Components 整合的具體情境：命令式 API（不是用 attribute 設定值、而是呼叫方法）不管來源是瀏覽器原生自訂元素還是 React 元件本身，存取方式的核心思路都是透過 ref 拿到底層節點或物件、直接呼叫它暴露的方法。",
+      "verify": {
+        "checks": [],
+        "manual": "Web Components 命令式方法呼叫需要真實瀏覽器自訂元素定義才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-29-q6",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "compound components：<Tabs><Tabs.Tab /></Tabs> 這種寫法怎麼共享狀態",
+      "docs": "https://react.dev/learn/passing-data-deeply-with-context",
+      "story": "",
+      "prompt": "想設計一個 <Tabs><Tabs.Tab label=\"A\" /><Tabs.Tab label=\"B\" /></Tabs> 這種 API，讓每個 Tabs.Tab 都知道『目前選中的是哪一個』，但不想在每個 Tabs.Tab 標籤上手動傳一堆 props（例如 active、onSelect）。這種「一組元件搭配使用、共享同一份狀態」的設計，該怎麼實作？",
+      "code": "const TabsContext = createContext(null);\n\nfunction Tabs({ children }) {\n  return (\n    <TabsContext.Provider value={{ active: 0 }}>\n      {children}\n    </TabsContext.Provider>\n  );\n}\nfunction Tab({ index, label }) {\n  const { active } = useContext(TabsContext);\n  return <span>{label}{active === index ? \"(選中)\" : \"\"}</span>;\n}\nTabs.Tab = Tab;\n\nconsole.log(renderToStaticMarkup(\n  <Tabs>\n    <Tabs.Tab index={0} label=\"A\" />\n    <Tabs.Tab index={1} label=\"B\" />\n  </Tabs>\n));",
+      "options": [
+        { "id": "a", "text": "<span>A(選中)</span><span>B</span>：compound components（複合元件）模式讓父層 Tabs 用 Context 建立一份共享狀態，子元件（Tab）透過 useContext 直接訂閱這份狀態，不需要呼叫端手動把 active 這類 props 一層層往下傳給每個 Tab；把 Tab 掛成 Tabs.Tab 這個靜態屬性，純粹是慣例上讓 API 讀起來更像『這是 Tabs 專屬的子元件』，實際運作靠的是 Context，不是這個掛載方式本身" },
+        { "id": "b", "text": "<span>A</span><span>B</span>：Tab 元件內部其實完全不需要 Context，這種寫法能動只是巧合" },
+        { "id": "c", "text": "程式會拋出例外，Tabs.Tab 這種把元件掛成另一個元件靜態屬性的寫法不合法" },
+        { "id": "d", "text": "兩個 Tab 都會顯示「(選中)」，因為 Context 沒辦法讓不同的子元件讀到不同的判斷結果" }
+      ],
+      "answer": "a",
+      "explanation": "compound components 模式把「一組元件協同運作、共享狀態」這個需求，交給 Context 承擔，而不是要求呼叫端手動逐層傳遞。這裡 index=0 的 Tab 讀到 Context 裡的 active（固定為 0）相符，顯示「(選中)」；index=1 的 Tab 讀到不相符，不顯示。把 Tab 掛成 Tabs.Tab 只是命名慣例，不影響底層透過 Context 共享狀態的運作方式。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { createContext, useContext } from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nconst TabsContext = createContext(null);\nfunction Tabs({ children }) {\n  return (\n    <TabsContext.Provider value={{ active: 0 }}>\n      {children}\n    </TabsContext.Provider>\n  );\n}\nfunction Tab({ index, label }) {\n  const { active } = useContext(TabsContext);\n  return <span>{label}{active === index ? \"(選中)\" : \"\"}</span>;\n}\nTabs.Tab = Tab;\nconsole.log(renderToStaticMarkup(\n  <Tabs>\n    <Tabs.Tab index={0} label=\"A\" />\n    <Tabs.Tab index={1} label=\"B\" />\n  </Tabs>\n));", "expected": "<span>A(選中)</span><span>B</span>" }
+        ]
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-3-testing.json b/packages/core/src/data/questions/ri-3-testing.json
new file mode 100644
index 0000000..f4a9af1
--- /dev/null
+++ b/packages/core/src/data/questions/ri-3-testing.json
@@ -0,0 +1,138 @@
+{
+  "id": "ri-3",
+  "title": "React 測試觀念",
+  "questions": [
+    {
+      "id": "ri-3-q1",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "測行為，不測實作細節",
+      "docs": "",
+      "story": "",
+      "prompt": "一個計數器元件目前是用 class component 寫的，內部用 this.state 維護 count。下面兩種測試寫法，哪一種比較不會在『重構了內部實作、但外部行為完全不變』時被誤判成失敗？",
+      "code": "// 寫法一：直接戳內部狀態\nconst wrapper = shallow(<Counter />);\nexpect(wrapper.state('count')).toBe(0);\n\n// 寫法二：只看使用者看得到、操作得到的畫面\nrender(<Counter />);\nexpect(screen.getByText('目前次數：0')).toBeInTheDocument();\nawait userEvent.click(screen.getByRole('button', { name: '加一' }));\nexpect(screen.getByText('目前次數：1')).toBeInTheDocument();",
+      "options": [
+        { "id": "a", "text": "寫法二：只斷言使用者實際會看到、會操作的畫面內容（文字、按鈕），完全不理會元件內部是 class 的 this.state 還是 useState／useReducer 管理資料；之後把 Counter 從 class 改寫成函式元件（例如改用 useReducer），只要畫面行為不變，測試依然通過。寫法一直接戳 wrapper.state('count')，這個 API 本來就只對『class 元件、且真的有 this.state』有效，一旦把元件改寫成函式元件，this.state 根本不存在，測試會直接壞掉，即使使用者體驗完全沒變" },
+        { "id": "b", "text": "寫法一：直接檢查內部 state 最精確，永遠不會誤判" },
+        { "id": "c", "text": "兩種寫法效果完全一樣，選哪個都無所謂" },
+        { "id": "d", "text": "寫法二有 bug，getByText 找不到文字時不會拋出任何錯誤" }
+      ],
+      "answer": "a",
+      "explanation": "測試越貼近元件的內部實作（state 名稱、資料結構），越容易變成「重構的絆腳石」——明明使用者體驗沒變，測試卻因為內部換了寫法而報紅。React Testing Library 的核心哲學就是「像使用者一樣測試」：只斷言畫面上真的會出現的文字、真的能點的按鈕，這樣測試才能只在『行為真的壞掉』時才失敗。",
+      "verify": {
+        "checks": [],
+        "manual": "React Testing Library / Jest 未安裝於本專案，測試框架的渲染、查詢、斷言機制需要真實測試環境才能執行，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-3-q2",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "查詢優先順序：先找語意化角色，最後才用 test id",
+      "docs": "",
+      "story": "",
+      "prompt": "想測試「使用者按下送出按鈕」這件事，Testing Library 建議的查詢優先順序，下列哪一種做法最合適？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "優先用 getByRole('button', { name: '送出' }) 這種貼近『使用者眼中看到的介面語意』的查詢；只有前面幾種語意化查詢都不適用時，才退而求其次用 getByTestId('submit-btn')" },
+        { "id": "b", "text": "一律優先用 getByTestId，因為最不容易因為文案改版而壞掉" },
+        { "id": "c", "text": "一律優先用 container.querySelector('.submit-button')，直接操作 CSS class 最精準" },
+        { "id": "d", "text": "查詢方式怎麼選都一樣，Testing Library 沒有建議的優先順序" }
+      ],
+      "answer": "a",
+      "explanation": "role-based 查詢（getByRole）確保「這個按鈕不只肉眼看得到，滑鼠使用者、鍵盤使用者、螢幕閱讀器使用者也都找得到」，等於順便驗證了可及性（a11y）；test-id 是官方明講的逃生口，代表沒有更好的語意化查詢方式時才用。過度依賴 CSS class 或 selector，等於把測試跟實作細節（樣式命名）綁死，UI 改版時測試容易無故壞掉。",
+      "verify": {
+        "checks": [],
+        "manual": "React Testing Library 未安裝於本專案，查詢 API 的實際比對行為需要真實測試環境才能執行，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-3-q3",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "userEvent 比 fireEvent 更貼近真實使用者操作",
+      "docs": "",
+      "story": "",
+      "prompt": "想模擬使用者「點擊」一個按鈕，下面兩種寫法在測試真實度上有什麼差別？",
+      "code": "// 寫法一\nfireEvent.click(button);\n\n// 寫法二\nawait userEvent.click(button);",
+      "options": [
+        { "id": "a", "text": "userEvent.click 會依序觸發一整串瀏覽器實際會發生的事件（pointerdown、mousedown、focus、pointerup、mouseup、click 等），行為更貼近真實使用者的滑鼠操作；fireEvent.click 只單獨觸發一個 click 事件，如果元件的邏輯是綁在 mousedown 或 focus 上，fireEvent 版本測不出問題" },
+        { "id": "b", "text": "兩者完全等價，只是命名不同" },
+        { "id": "c", "text": "fireEvent 比較真實，因為它是 React 官方唯一支援的測試方式" },
+        { "id": "d", "text": "userEvent 只能用在 TypeScript 專案裡" }
+      ],
+      "answer": "a",
+      "explanation": "fireEvent 是低階 API，直接在 DOM 上派送『指定的那一個』事件；userEvent 是建立在 fireEvent 之上的高階封裝，會模擬使用者操作實際觸發的完整事件序列（例如點擊還牽涉到 pointer 事件、focus 轉移）。當元件邏輯依賴這些中間事件（例如 onMouseDown 就先做某件事、或依賴 focus 狀態）時，只用 fireEvent.click 可能測不出真正的行為，userEvent 更貼近使用者實際體驗。",
+      "verify": {
+        "checks": [],
+        "manual": "React Testing Library user-event 未安裝於本專案，事件序列的實際觸發需要真實 DOM 與測試環境才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-3-q4",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "非同步資料要用 findBy／waitFor，不是 getBy",
+      "docs": "",
+      "story": "",
+      "prompt": "元件掛載後會發送 API 請求，資料回來才顯示使用者名稱。下面這段測試為什麼一執行就會拋出「Unable to find an element」？",
+      "code": "render(<UserProfile userId=\"1\" />);\nexpect(screen.getByText(\"Alice\")).toBeInTheDocument(); // 立刻拋錯",
+      "options": [
+        { "id": "a", "text": "getByText 是『同步、立刻檢查』的查詢，執行當下 API 請求可能都還沒回來，畫面上根本還沒有 Alice 這段文字；應該改用內建等待機制的 findByText（回傳 Promise），或搭配 waitFor，等非同步資料真的渲染出來後再斷言" },
+        { "id": "b", "text": "Alice 這個名字拼錯了，測試框架其實不區分大小寫" },
+        { "id": "c", "text": "getByText 只能用在同步元件，非同步元件要用完全不同的測試框架" },
+        { "id": "d", "text": "render 函式本身是非同步的，這裡少寫了 await render(...)" }
+      ],
+      "answer": "a",
+      "explanation": "getBy 系列查詢找不到元素會立刻拋出錯誤，適合斷言「這個當下應該存在」的內容；findBy 系列則會在指定的時間內反覆重試查詢，直到元素出現或逾時，天生適合搭配非同步渲染。這裡的 bug 不是拼字或框架限制，而是選錯了「同步查詢」去斷言一個要等 API 回應才會出現的內容。",
+      "verify": {
+        "checks": [],
+        "manual": "React Testing Library 未安裝於本專案，findBy/waitFor 的實際等待重試機制需要真實測試環境才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-3-q5",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "Mock 網路請求，不要打真實 API",
+      "docs": "",
+      "story": "",
+      "prompt": "元件內部呼叫 fetch('/api/user/1') 拿資料。單元測試裡，下列哪種做法最恰當？",
+      "code": "// 做法一：測試直接打真實後端\nrender(<UserProfile userId=\"1\" />);\n\n// 做法二：攔截並提供假回應\nglobal.fetch = jest.fn(() =>\n  Promise.resolve({\n    json: () => Promise.resolve({ name: \"Alice\" }),\n  })\n);\nrender(<UserProfile userId=\"1\" />);",
+      "options": [
+        { "id": "a", "text": "做法二：mock 掉 fetch，讓測試不依賴真實後端、網路狀況或資料庫當下的內容；測試因此變得穩定（跑一百次結果都一樣、不受外部狀態影響），也能刻意模擬後端回傳錯誤或空結果這些平常很難重現的邊界情境" },
+        { "id": "b", "text": "做法一：打真實 API 才能證明整個系統真的能動，永遠優先選這個" },
+        { "id": "c", "text": "兩種做法效果一樣，mock 只是多此一舉" },
+        { "id": "d", "text": "mock fetch 違反測試的『誠實』原則，應該完全避免使用" }
+      ],
+      "answer": "a",
+      "explanation": "單元測試的目標是「快速、穩定、可重複」，打真實後端會讓測試結果受網路狀況、資料庫當下內容、後端是否啟動等外部因素影響，同一份測試在不同時間跑可能得到不同結果。mock 網路請求把「這個元件在收到某種回應時該怎麼渲染」跟「後端真的能不能正常運作」這兩件事切開，後者應該交給整合測試或 E2E 測試負責，不是單元測試的職責。",
+      "verify": {
+        "checks": [],
+        "manual": "jest.fn / global.fetch mock 未安裝於本專案，且需要真實測試環境才能觀察 mock 是否生效，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-3-q6",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "Snapshot 測試被無腦更新，等於失去測試意義",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊在每個元件都加上 expect(container).toMatchSnapshot()。半年後，PR review 時常看到「快照有變化」，工程師的反射動作幾乎都是直接執行更新快照的指令讓測試變綠，沒有人真的去看差異內容。這個習慣最可能造成什麼問題？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "Snapshot 測試退化成『橡皮圖章』：只要有變化就無腦更新快照，測試等於完全失去『捕捉不小心引入的錯誤』這個原本的目的——哪天某次改動真的是 bug，也會被同一套『看到差異就更新』的反射動作直接蓋過去，不會被攔下來" },
+        { "id": "b", "text": "沒有任何問題，Snapshot 測試本來就是設計成這樣使用的" },
+        { "id": "c", "text": "唯一的問題是快照檔案會佔用比較多硬碟空間" },
+        { "id": "d", "text": "Snapshot 測試會讓應用程式在正式環境執行得比較慢" }
+      ],
+      "answer": "a",
+      "explanation": "Snapshot 測試的價值建立在「差異出現時，人真的會看一眼再決定要不要接受」；一旦更新快照變成看到失敗就反射性執行的動作，快照測試就從『安全網』退化成『每次都會通過的裝飾品』，完全喪失攔截意外變更的能力。這也是業界常見對 snapshot 測試的批評：適合用在小範圍、內容穩定的輸出，大量套用在整個元件樹上很容易走向這個結局。",
+      "verify": {
+        "checks": [],
+        "manual": "Jest snapshot 機制未安裝於本專案，且這是團隊習慣與流程層面的推理題，無可執行程式碼。"
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-30-misc-state-alternatives-internals.json b/packages/core/src/data/questions/ri-30-misc-state-alternatives-internals.json
new file mode 100644
index 0000000..7c548ae
--- /dev/null
+++ b/packages/core/src/data/questions/ri-30-misc-state-alternatives-internals.json
@@ -0,0 +1,418 @@
+{
+  "id": "ri-30",
+  "title": "React 進階探索：狀態管理替代方案與底層機制",
+  "questions": [
+    {
+      "id": "ri-30-q1",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "MobX：用「可觀察物件」自動追蹤依賴，跟 Redux 的顯式 dispatch 是不同哲學",
+      "docs": "",
+      "story": "",
+      "prompt": "MobX 是另一套常見的狀態管理方案，跟 Redux 相比，核心設計哲學有什麼根本差異？",
+      "code": "// MobX：直接修改可觀察物件，UI 自動反應\nclass CartStore {\n  items = [];\n  addItem(item) {\n    this.items.push(item); // 看起來像直接修改，但物件是「可觀察」的\n  }\n}\n\n// Redux：透過 dispatch 一個 action，reducer 算出新 state\nstore.dispatch({ type: \"ADD_ITEM\", item });",
+      "options": [
+        {
+          "id": "a",
+          "text": "MobX 用『可觀察物件（observable）』自動追蹤『誰讀取了這份資料』，資料一變，所有讀取過它的地方自動重新計算／重繪，寫法上看起來像直接修改物件（底層靠 Proxy 或類似機制攔截讀寫）；Redux 走的是前面 ri-4 章節談過的明確路徑——所有變更都要透過 dispatch 一個 action、由純函式 reducer 算出全新的不可變 state，變更軌跡明確、可預測、方便時間旅行除錯，但樣板程式碼相對較多。兩者是『自動化程度 vs 明確可預測性』這組取捨的不同選擇"
+        },
+        {
+          "id": "b",
+          "text": "MobX 與 Redux 在設計理念與底層實作上完全相同，只是套件名稱不同"
+        },
+        {
+          "id": "c",
+          "text": "MobX 只能用於 Vue 專案，無法搭配 React 使用"
+        },
+        {
+          "id": "d",
+          "text": "Redux 底層其實是用可觀察物件實作的，跟 MobX 的機制一模一樣"
+        }
+      ],
+      "answer": "a",
+      "explanation": "MobX 的自動依賴追蹤讓程式碼寫起來更接近直覺的物件導向風格，樣板程式碼少；Redux 的顯式 action/reducer 流程犧牲了一些簡潔，換取變更路徑完全可追蹤、可預測、方便像 Redux DevTools 那樣做時間旅行除錯。這組取捨沒有絕對優劣，是團隊在『開發便利性』與『可預測性、除錯工具支援』之間的選擇。",
+      "verify": {
+        "checks": [],
+        "manual": "MobX 未安裝於本專案，可觀察物件的自動追蹤機制需要真實套件執行才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-30-q2",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "diffing 演算法的兩條核心捷徑：不同型別直接重建、同型別用 key 比對子元素",
+      "docs": "",
+      "story": "",
+      "prompt": "完整、精確地比較兩棵樹的最小差異，是電腦科學裡一個計算量很高的問題（理論上是 O(n³) 等級）。React 的 diffing 演算法為了實用，刻意採用了哪些簡化捷徑，把複雜度降到接近 O(n)？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "①不同型別的元素，直接假設整棵子樹完全不同、砍掉重建，不嘗試比對內部細節（前面 ri-11 章節已驗證這個行為）；②同一層的子元素列表，透過 key 屬性明確標記『這是同一個』，不用進行昂貴的全域最佳比對演算法，直接依 key 對應找出增刪移動——這兩條捷徑犧牲了『理論上最精確的最小差異』，換取『實務上大多數 UI 更新場景都夠用、而且執行速度快得多』的結果"
+        },
+        {
+          "id": "b",
+          "text": "React 的 diffing 演算法完全不做任何簡化，每次都執行理論上最精確、複雜度最高的完整比對"
+        },
+        {
+          "id": "c",
+          "text": "React 的 diffing 演算法只比較元素的文字內容，完全忽略元素的型別與屬性"
+        },
+        {
+          "id": "d",
+          "text": "diffing 演算法的複雜度與樹的大小完全無關，任何規模的更新耗時都相同"
+        }
+      ],
+      "answer": "a",
+      "explanation": "React 官方文件明確承認這套演算法是「啟發式（heuristic）」的，不追求理論上最精確的最小差異，而是根據「大多數真實 UI 場景符合的假設」（同型別元素通常結構相似、清單元素通常有穩定身份）簡化計算，把複雜度從理論上限的 O(n³) 降到接近 O(n)，這是效能與精確度之間刻意的工程取捨。",
+      "verify": {
+        "checks": [],
+        "manual": "diffing 演算法複雜度屬理論分析與內部實作細節，需要原始碼層級理解，無法用可執行片段驗證。"
+      }
+    },
+    {
+      "id": "ri-30-q3",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "diffing 演算法遵守的具體規則：兩條捷徑各自對應到什麼開發者可觀察的行為",
+      "docs": "",
+      "story": "",
+      "prompt": "把上一題談的兩條 diffing 捷徑，翻譯成開發者實際會觀察到的行為，下列哪個描述正確？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "①同一位置前後兩次渲染的元素型別不同 → 整個子樹（包含其中的 state）被砍掉重建，這正是前面 ri-11 章節實測過的行為；②陣列渲染時，React 依 key 判斷哪些元素是『同一個』（對應到 state 是否保留）、哪些是新增或刪除的，而不是單純依陣列索引位置比對——這也是為什麼前面 ri-13 章節談過『用索引當 key』在清單插入項目時會造成 state 錯位的根本原因"
+        },
+        {
+          "id": "b",
+          "text": "diffing 演算法只在使用者手動點擊『重新整理』按鈕時才會執行一次"
+        },
+        {
+          "id": "c",
+          "text": "diffing 演算法的比對結果永遠跟開發者寫的程式碼順序無關，純粹依渲染時間先後決定"
+        },
+        {
+          "id": "d",
+          "text": "型別不同的元素，diffing 演算法會嘗試盡可能重用舊節點的屬性，只更新真正不同的部分"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這題把抽象的演算法描述，跟本次多個章節已經用真實程式碼驗證過的具體現象串起來：型別比對捷徑對應到 ri-11 章節驗證過的『同位置換型別就整個重建』；key 比對捷徑對應到 ri-13 章節談過的『index-as-key 導致 state 錯位』。理解演算法背後的簡化假設，能幫助解釋這些表面上看似「規則細節」的現象，其實都源自同一套底層設計。",
+      "verify": {
+        "checks": [],
+        "manual": "diffing 具體規則的可觀察行為已在其他章節以真實程式碼驗證，此處為概念串接說明，無需重複驗證。"
+      }
+    },
+    {
+      "id": "ri-30-q4",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "render props 不一定要叫做 render，這只是社群慣例名稱，不是語法要求",
+      "docs": "",
+      "story": "",
+      "prompt": "render props 模式（元件接收一個函式當 prop，由呼叫端決定怎麼渲染）裡，那個函式型別的 prop 是不是一定要命名成 render？",
+      "code": "// 不叫 render，叫 children，一樣是 render props 模式\nfunction MouseTracker({ children }) {\n  const [pos] = useState({ x: 0, y: 0 });\n  return children(pos);\n}\n\n<MouseTracker>\n  {(pos) => <p>{pos.x}, {pos.y}</p>}\n</MouseTracker>",
+      "options": [
+        {
+          "id": "a",
+          "text": "不需要：render props 這個模式的本質是『把一個回傳 JSX 的函式當成 prop 傳入』，至於這個 prop 叫什麼名字（render、children、renderItem...）純粹是命名選擇，不影響這個模式本身是否成立；用 children 這個特殊 prop 承載這個函式（如範例所示）也是很常見的變形寫法，稱作『function as children』"
+        },
+        {
+          "id": "b",
+          "text": "必須命名成 render，這是 React 語法層級強制要求的保留字，命名成其他名稱會導致元件無法正常運作"
+        },
+        {
+          "id": "c",
+          "text": "只有命名成 render 的版本才算 render props，命名成 children 的屬於完全不同、不相關的模式"
+        },
+        {
+          "id": "d",
+          "text": "這個函式型 prop 只能命名成小寫開頭，大寫開頭會被誤判成元件"
+        }
+      ],
+      "answer": "a",
+      "explanation": "「render props」這個名字本身，某種程度上是歷史命名慣例（早期範例常用一個叫 render 的 prop 示範這個模式）留下的稱呼，不是語法上的強制要求。這個模式的核心特徵——把一個回傳 JSX 的函式當 prop 傳入，由呼叫端掌控渲染邏輯——不因為 prop 叫什麼名字而改變，用 children 這個特殊 prop 傳遞同樣的函式，一樣是同一個模式的變形應用。",
+      "verify": {
+        "checks": [],
+        "manual": "屬命名慣例與模式定義的釐清題，無可執行程式碼佐證。"
+      }
+    },
+    {
+      "id": "ri-30-q5",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "render props 搭配 React.memo 的子元件時，常見的效能陷阱：每次渲染都是新的函式參考",
+      "docs": "",
+      "story": "",
+      "prompt": "MouseTracker 這個用 render props 模式設計的元件，外面包了 React.memo，理論上希望呼叫端傳入同樣的內容時能跳過重繪。但呼叫端每次渲染都直接寫一個行內箭頭函式當 children，會發生什麼事？",
+      "code": "const MouseTracker = React.memo(function MouseTracker({ children }) {\n  const [pos] = useState({ x: 0, y: 0 });\n  return children(pos);\n});\n\nfunction App() {\n  const [tick, setTick] = useState(0);\n  return (\n    <MouseTracker>\n      {(pos) => <p>{pos.x}, {pos.y}</p>} {/* 每次渲染都是新的函式參考 */}\n    </MouseTracker>\n  );\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "memo 的效果完全發揮不出來：這個行內箭頭函式在每次 App 重繪時都會重新建立，等於每次都是一個全新的函式參考，React.memo 淺層比較 children 這個 prop 時，永遠判定『變了』——這是本次章節反覆出現的『memo 淺層比較 + 參考型別每次都是新的』這個根本陷阱，在 render props 模式下的又一個具體案例，跟前面 ri-14 章節談的行內物件 style prop 是同一個問題，只是這裡換成了行內函式"
+        },
+        {
+          "id": "b",
+          "text": "memo 會自動忽略函式型別的 props，只比較其餘的 props，因此完全不受影響"
+        },
+        {
+          "id": "c",
+          "text": "這種情境下 memo 反而能正確跳過重繪，因為函式的『內容』（實作邏輯）沒有改變"
+        },
+        {
+          "id": "d",
+          "text": "程式會拋出例外，render props 不能跟 React.memo 一起使用"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這是「render props 加上 pure component（memo）的典型問題」：render props 模式天生依賴『每次渲染傳入一個函式』，如果這個函式是行內建立的，就會踩到跟前面章節反覆出現的同一個陷阱——memo 的淺層比較看的是參考，不是內容或行為是否相同。解法一樣是用 useCallback 包住這個函式，讓它在依賴不變時保持穩定參考，memo 才能真正判斷『沒變、可以跳過』。",
+      "verify": {
+        "checks": [],
+        "manual": "render props 搭配 memo 的重繪陷阱需要多輪真實渲染搭配渲染次數計數才能觀察，無法用單次 node 執行驗證。"
+      }
+    },
+    {
+      "id": "ri-30-q6",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "什麼時候真正需要用 ref：跳脫宣告式資料流、直接命令式操作 DOM 或外部系統",
+      "docs": "",
+      "story": "",
+      "prompt": "把本次多個章節談過的 ref 使用情境收斂成一條判斷準則：什麼時候該考慮用 ref，而不是繼續用 props/state 這套宣告式的資料流解決？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "當需求本質上是『命令式』操作，沒辦法自然地表達成『state 對應到某種畫面』時：例如聚焦某個輸入框、捲動到某個位置、量測 DOM 元素的實際尺寸、控制一段媒體播放（play/pause）、整合不是用 React 寫的第三方函式庫或 Web Components（前面 ri-29 章節談過）。這些情境的共通點是『需要直接、命令式地對一個具體的 DOM 節點或外部系統下指令』，而不是『畫面該顯示成什麼樣子』這種宣告式的問題，用 state／props 硬套反而彆扭，ref 是這類需求的正確工具"
+        },
+        {
+          "id": "b",
+          "text": "任何情境都應該優先使用 ref，state 與 props 只是備用方案"
+        },
+        {
+          "id": "c",
+          "text": "只有畫面上會顯示出來的資料才適合用 ref 儲存"
+        },
+        {
+          "id": "d",
+          "text": "ref 只能用在 class component，函式元件的任何情境都不需要使用 ref"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這是把本次章節裡多次出現的 ref 使用案例（聚焦輸入框、量測尺寸、Web Components 整合、useImperativeHandle 暴露方法）收斂出的一條通用判斷準則：ref 適合『跳出宣告式資料流、需要直接對某個東西下命令』的情境，這跟 state／props 描述『畫面該長什麼樣』的宣告式思維是互補、而非互斥的兩種工具，官方文件明確建議只有在真的需要『跳脫 React 的渲染資料流』時才使用 ref。",
+      "verify": {
+        "checks": [],
+        "manual": "屬判斷準則的綜合說明題，具體案例已在其他章節分別驗證，此處為原則性收斂，無需重複可執行驗證。"
+      }
+    },
+    {
+      "id": "ri-30-q7",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "Concurrent Rendering：讓渲染工作可以被中斷、依優先權排程，不是「同時執行多個渲染」",
+      "docs": "",
+      "story": "",
+      "prompt": "「並行渲染（Concurrent Rendering）」這個名字容易讓人誤會成「React 可以同時渲染多棵樹」。它實際指的是什麼？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "並行渲染指的是 React（依賴前面 ri-11 章節談過的 Fiber 架構）有能力『開始』渲染一次更新、但在渲染過程中如果有更緊急的更新插進來（例如使用者輸入），可以先暫停手上這次渲染、優先處理緊急的更新，稍後再繼續或捨棄先前那次未完成的渲染——重點是『可中斷、可依優先權插隊』，不是真的有多個渲染同時平行執行；useTransition／useDeferredValue（前面 ri-8、ri-25 章節談過）都是建立在這個能力之上的具體 API"
+        },
+        {
+          "id": "b",
+          "text": "並行渲染指的是 React 真的用多執行緒同時渲染多棵獨立的元件樹，JavaScript 單執行緒的限制已經被完全突破"
+        },
+        {
+          "id": "c",
+          "text": "並行渲染只是一個行銷用詞，React 18 的渲染機制跟之前的版本完全沒有任何差異"
+        },
+        {
+          "id": "d",
+          "text": "並行渲染指的是可以同時連接多個不同的資料庫來源渲染同一個元件"
+        }
+      ],
+      "answer": "a",
+      "explanation": "「並行（concurrent）」在這裡強調的是「可中斷、可被打斷插隊」的能力，不是傳統意義上的多執行緒平行運算——JavaScript 依然是單執行緒，React 做的是把渲染工作拆成小單位（Fiber），讓排程器能在單位之間插入更緊急的工作，這正是 useTransition、useDeferredValue 這些 API 得以存在的底層基礎。",
+      "verify": {
+        "checks": [],
+        "manual": "並行渲染的排程與插隊機制屬 React 內部架構，需要原始碼層級理解，無法用可執行片段驗證。"
+      }
+    },
+    {
+      "id": "ri-30-q8",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "async mode（實驗性舊稱）跟後來正式定名的 concurrent mode／並行特性，是同一個能力演進過程中的不同階段稱呼",
+      "docs": "",
+      "story": "",
+      "prompt": "React 團隊在正式定名「並行渲染（Concurrent Rendering）」之前，這個功能曾經有一個實驗性階段被稱為「async mode」。這兩個名稱之間是什麼關係？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "是同一組底層能力（可中斷、依優先權排程的渲染）在不同開發階段的稱呼：早期實驗性版本用 async mode 這個名字，強調『非同步、不阻塞』這個特性；後來 React 團隊發現『async』這個詞容易讓開發者誤以為跟 async/await、Promise 這些非同步 JavaScript 概念直接相關，於是正式定名時改用『concurrent（並行）』這個更精確反映『可中斷、可插隊排程』本質的名稱——這不是兩個獨立的功能，是同一個能力隨著開發與命名逐漸成熟的過程"
+        },
+        {
+          "id": "b",
+          "text": "async mode 與 concurrent mode 是兩個完全獨立、互不相關的功能，各自解決不同的問題"
+        },
+        {
+          "id": "c",
+          "text": "async mode 至今仍是官方現行名稱，concurrent mode 才是已經被棄用的舊稱呼"
+        },
+        {
+          "id": "d",
+          "text": "两者的差異在於 async mode 只能用於伺服器端，concurrent mode 只能用於瀏覽器端"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這是 React 官方重新命名的一個具體案例：技術能力（可中斷渲染、優先權排程）在開發過程中保持一致，命名則隨著團隊對『怎麼稱呼才不會誤導開發者』的思考而調整。「async」容易被誤解成非同步 I/O 相關的概念，「concurrent」更貼近『多個優先權不同的工作互相插隊』這個實際機制，不是功能本身有什麼根本改變。",
+      "verify": {
+        "checks": [],
+        "manual": "屬命名歷史脈絡的說明題，無可執行程式碼佐證。"
+      }
+    },
+    {
+      "id": "ri-30-q9",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "整合第三方 UI 函式庫（如 Bootstrap）到 React：透過對應的 React 封裝套件，或手動引入 CSS＋自行管理互動邏輯",
+      "docs": "",
+      "story": "",
+      "prompt": "想在 React 專案裡使用 Bootstrap 的元件（如 Modal、Dropdown），Bootstrap 原生是用 jQuery／原生 JS 操作 DOM 實作互動邏輯的。直接照搬 Bootstrap 官方文件的 HTML＋JS 寫法到 React 專案，會有什麼問題？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "Bootstrap 原生的互動邏輯（如 Modal 開關）習慣直接操作 DOM（新增/移除 class、監聽原生事件），這跟 React『畫面內容該由 state 決定，不該被外部直接改動 DOM』的心智模型（前面 ri-28 章節談過）互相衝突，容易讓 React 內部認知與真實 DOM 產生分歧；更穩妥的做法是改用 react-bootstrap 或 reactstrap 這類專門把 Bootstrap 元件重新包裝成『state 驅動』React 元件的套件，或者只引入 Bootstrap 的 CSS 樣式、互動邏輯完全交給 React state 自己管理，不使用 Bootstrap 原生的 JS 部分"
+        },
+        {
+          "id": "b",
+          "text": "完全沒有任何問題，Bootstrap 的 JS 互動邏輯與 React 的渲染機制完全相容，可以直接照搬使用"
+        },
+        {
+          "id": "c",
+          "text": "Bootstrap 從技術上無法在任何 React 專案裡使用，兩者互不相容"
+        },
+        {
+          "id": "d",
+          "text": "只需要引入 Bootstrap 的 JavaScript 檔案，完全不需要考慮 React 的渲染機制"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這題把前面 ri-28 章節談過『不要繞過 React 直接操作 DOM』的原則，應用到「整合原生操作 DOM 的第三方 UI 函式庫」這個常見的實務情境：直接混用兩種對 DOM『所有權』的假設不同的系統，容易造成狀態不同步；React 生態系普遍的解法是使用專門的 React 封裝套件，讓元件的顯示與互動邏輯統一交由 React state 驅動，只借用原始函式庫的樣式（CSS）。",
+      "verify": {
+        "checks": [],
+        "manual": "第三方 UI 函式庫整合行為需要真實瀏覽器環境觀察 DOM 操作衝突，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-30-q10",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "使用者重新整理頁面後，Context 裡的登入狀態預設會消失，需要額外的持久化機制才能恢復",
+      "docs": "https://react.dev/learn/passing-data-deeply-with-context",
+      "story": "",
+      "prompt": "認證資訊用 Context 管理，初始值直接寫死 isLoggedIn: false。使用者登入後，重新整理整個瀏覽器頁面（不是單純 SPA 內的畫面切換），Context 裡的狀態會發生什麼事？",
+      "code": "const AuthContext = createContext({ isLoggedIn: false });\n\nfunction AuthProvider({ children }) {\n  const [auth, setAuth] = useState({ isLoggedIn: false }); // 每次都是全新初始值\n  return <AuthContext.Provider value={auth}>{children}</AuthContext.Provider>;\n}",
+      "options": [
+        {
+          "id": "a",
+          "text": "登入狀態會消失、回到 isLoggedIn: false：整頁重新整理，代表整個 JavaScript 執行環境（包含所有 React 元件與它們的 state、Context）都會被完全重新初始化，Context 本身不具備任何跨越『頁面重新載入』的持久化能力；想讓使用者重新整理頁面後依然維持登入狀態，得額外把認證資訊存進 localStorage／cookie 這類真正能跨頁面重新整理存活的儲存機制，AuthProvider 初始化時再從那裡讀回來，而不是單純依賴 useState 的初始值"
+        },
+        {
+          "id": "b",
+          "text": "登入狀態會自動保留，Context 本身內建跨頁面重新整理的持久化能力"
+        },
+        {
+          "id": "c",
+          "text": "登入狀態會保留，但只在使用者使用同一個瀏覽器分頁時才有效"
+        },
+        {
+          "id": "d",
+          "text": "程式會拋出例外，Context 不支援儲存跟認證相關的資料"
+        }
+      ],
+      "answer": "a",
+      "explanation": "Context（跟 useState／useReducer 一樣）只是「這次 JavaScript 執行環境存活期間」的記憶體狀態，整頁重新整理等同於整個應用程式重新啟動一次，這份記憶體會完全消失。要讓登入狀態撐過重新整理，一定要额外仰賴瀏覽器提供的、真正能跨越頁面重載的儲存機制（localStorage、cookie、sessionStorage），這是 Context 完全不涉及、需要開發者自己補上的一層。",
+      "verify": {
+        "checks": [
+          {
+            "jsx": "import { createContext, useState, useContext } from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nconst AuthContext = createContext({ isLoggedIn: false });\nfunction AuthProvider({ children }) {\n  const [auth] = useState({ isLoggedIn: false });\n  return <AuthContext.Provider value={auth}>{children}</AuthContext.Provider>;\n}\nfunction Status() {\n  const auth = useContext(AuthContext);\n  return <p>{String(auth.isLoggedIn)}</p>;\n}\nconsole.log(renderToStaticMarkup(<AuthProvider><Status /></AuthProvider>));",
+            "expected": "<p>false</p>"
+          }
+        ]
+      }
+    },
+    {
+      "id": "ri-30-q11",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "新版 JSX transform：不用再手動 import React 才能使用 JSX",
+      "docs": "",
+      "story": "",
+      "prompt": "舊版 JSX transform 要求每個用到 JSX 語法的檔案，都必須手動 import React from \"react\"（即使程式碼裡完全沒有直接寫 React.xxx），否則會報錯。新版 JSX transform 帶來了什麼改變？",
+      "code": "// 舊版 transform：JSX 被轉譯成 React.createElement(...)，所以檔案裡必須有 React 這個變數\nimport React from \"react\";\nfunction Greeting() { return <h1>Hi</h1>; }\n\n// 新版 transform：JSX 被轉譯成從 react/jsx-runtime 匯入的 jsx(...) 函式呼叫\n// 不再需要手動 import React\nfunction Greeting() { return <h1>Hi</h1>; }",
+      "options": [
+        {
+          "id": "a",
+          "text": "新版 transform 把 JSX 轉譯成呼叫一個從 react/jsx-runtime 這個模組自動匯入的 jsx()／jsxs() 函式，這個匯入是建置工具自動加上的，不需要開發者手動在每個檔案頂部寫 import React；這消除了『明明沒有直接用到 React 這個變數名稱，卻被要求一定要 import 它』這種容易讓新手困惑的樣板要求，同時新版 transform 產生的程式碼在某些情境下體積也略小、效能略好"
+        },
+        {
+          "id": "b",
+          "text": "新版 transform 完全移除了建置階段的轉譯步驟，JSX 語法變成瀏覽器原生支援"
+        },
+        {
+          "id": "c",
+          "text": "新版 transform 要求所有元件都必須改寫成 class component，函式元件不再受支援"
+        },
+        {
+          "id": "d",
+          "text": "新版與舊版 transform 產生的最終程式碼完全相同，只是改變了原始碼裡 import 語句的寫法"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這是 React 17 引入的一項建置工具層面的改進：轉譯目標從『必須存在一個叫 React 的變數』（因為轉譯結果直接呼叫 React.createElement）改成『自動從 react/jsx-runtime 匯入專用的轉譯函式』，開發者不再需要為了滿足這個技術限制、手動加上看似多餘的 import。這個改變純粹發生在建置工具層級，JSX 本身依然需要轉譯，不是瀏覽器原生支援。",
+      "verify": {
+        "checks": [],
+        "manual": "新舊 JSX transform 的差異屬建置工具轉譯機制，需要比對實際轉譯輸出才能驗證，無法用單一執行片段完整展示。"
+      }
+    },
+    {
+      "id": "ri-30-q12",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "新舊 JSX transform 是建置工具層級的內部差異，一般業務程式碼寫法完全不受影響",
+      "docs": "",
+      "story": "",
+      "prompt": "專案從舊版 JSX transform 切換到新版，除了可以拿掉不必要的 import React 語句，日常撰寫元件、Hooks、props 傳遞的程式碼寫法本身，需要跟著改變嗎？",
+      "code": "",
+      "options": [
+        {
+          "id": "a",
+          "text": "不需要：新舊 transform 的差異純粹發生在『JSX 語法轉譯成什麼樣的底層函式呼叫』這個建置工具層級，元件怎麼寫、Hooks 怎麼呼叫、props 怎麼傳遞，這些日常撰寫程式碼會用到的語法完全不受影響；唯一實際的改變只有『不再需要手動 import React 才能使用 JSX』這一點，其餘程式碼可以維持原樣，這也是為什麼這項改動能以相對平滑的方式推廣到既有專案"
+        },
+        {
+          "id": "b",
+          "text": "需要，切換到新版 transform 之後，所有的 Hooks 呼叫方式都必須重新改寫"
+        },
+        {
+          "id": "c",
+          "text": "需要，新版 transform 要求把所有函式元件改寫成 class component"
+        },
+        {
+          "id": "d",
+          "text": "需要，新版 transform 底下 props 的傳遞方式從物件改成陣列"
+        }
+      ],
+      "answer": "a",
+      "explanation": "這題強調新版 JSX transform 是一個「建置工具內部實作」層級的改動，刻意設計成對開發者日常撰寫程式碼的方式影響降到最低——這也是它能被順利、廣泛採用而不需要大規模重構既有程式碼的原因，跟 Hooks 怎麼呼叫、元件怎麼定義、props 怎麼傳遞完全無關。",
+      "verify": {
+        "checks": [],
+        "manual": "屬建置工具轉譯機制與應用程式碼撰寫方式的釐清題，無可執行程式碼佐證。"
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-4-redux.json b/packages/core/src/data/questions/ri-4-redux.json
new file mode 100644
index 0000000..dd9a1d3
--- /dev/null
+++ b/packages/core/src/data/questions/ri-4-redux.json
@@ -0,0 +1,691 @@
+{
+  "id": "ri-4",
+  "title": "Redux 狀態管理",
+  "questions": [
+    {
+      "id": "ri-4-q1",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "createSlice 看似直接改 state，其實底層靠 Immer 維持不可變性",
+      "docs": "",
+      "story": "",
+      "prompt": "用 Redux Toolkit 的 createSlice 寫 reducer，程式碼看起來直接改了 state.count。這樣真的違反 Redux「state 是唯讀、只能靠回傳新物件來更新」的核心原則嗎？",
+      "code": "const counterSlice = createSlice({\n  name: \"counter\",\n  initialState: { count: 0 },\n  reducers: {\n    increment(state) {\n      state.count += 1; // 看起來像直接修改\n    },\n  },\n});",
+      "options": [
+        { "id": "a", "text": "沒有違反：createSlice 內部用 Immer 這個函式庫包裝了 reducer，你寫的『看似直接修改』程式碼，其實是在一份可追蹤的草稿（draft）上操作，Immer 會依這些修改記錄，自動產生一份全新的、真正不可變的 state 物件回傳；表面寫法變簡潔了，Redux 的不可變性原則在底層依然被遵守" },
+        { "id": "b", "text": "違反了，Redux Toolkit 已經放棄不可變性這個原則，允許直接修改 state" },
+        { "id": "c", "text": "沒有違反，因為 JavaScript 的物件本來就是傳值、不是傳參考" },
+        { "id": "d", "text": "違反了，這段程式碼在執行期會直接拋出錯誤" }
+      ],
+      "answer": "a",
+      "explanation": "傳統 Redux 要求手動用展開運算子等方式複製 state 再回傳，寫起來容易漏掉某個巢狀層級，也容易一時失手直接改了原物件。Redux Toolkit 讓 createSlice 內建 Immer，讓你可以寫出「看起來像直接改」的直覺程式碼，Immer 在背後追蹤所有修改、最後生出一份全新物件——不可變性依然被遵守，只是你不用再手動處理複製邏輯。",
+      "verify": {
+        "checks": [],
+        "manual": "Redux Toolkit（含 Immer）未安裝於本專案，草稿（draft）機制需要實際套件執行才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-4-q2",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "reducer 裡不該再觸發另一個 dispatch",
+      "docs": "",
+      "story": "",
+      "prompt": "下面這個 reducer 錯在哪？",
+      "code": "function todosReducer(state, action) {\n  switch (action.type) {\n    case \"ADD_TODO\": {\n      const newState = [...state, action.payload];\n      store.dispatch({ type: \"LOG_TODO_ADDED\" }); // 錯誤\n      return newState;\n    }\n    default:\n      return state;\n  }\n}",
+      "options": [
+        { "id": "a", "text": "reducer 裡呼叫 store.dispatch() 是明確的反模式：reducer 必須是純函式（同樣的 state 與 action 輸入，永遠得到同樣的輸出，且不能有副作用）；在 reducer 內觸發另一個 dispatch，等於在『計算下一個 state』的過程中夾帶一個會啟動連鎖反應的副作用，容易引發難以追蹤的連鎖 dispatch，甚至無窮迴圈" },
+        { "id": "b", "text": "沒有任何問題，reducer 本來就可以自由呼叫 dispatch" },
+        { "id": "c", "text": "問題只在拼字，action.type 的字串應該全部改成小寫" },
+        { "id": "d", "text": "問題在陣列展開語法 [...state, action.payload] 用錯了" }
+      ],
+      "answer": "a",
+      "explanation": "Redux 對 reducer 的要求很單純：純函式、無副作用、只負責「算出下一個 state」。想記錄「新增了一筆 todo」這種副作用（記錄 log、發 API），應該放在 middleware（如 redux-thunk 的 action creator、或 store.subscribe 的監聽者）裡處理，不該塞進 reducer 本體。",
+      "verify": {
+        "checks": [],
+        "manual": "Redux 未安裝於本專案，dispatch 觸發的連鎖行為需要真實 store 執行才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-4-q3",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "useSelector／useDispatch 取代舊版 connect()",
+      "docs": "",
+      "story": "",
+      "prompt": "舊版用 connect(mapStateToProps, mapDispatchToProps) 高階元件把 state 和 dispatch 接進元件。現代 Redux Toolkit + react-redux 的 Hooks 風格，該怎麼在函式元件裡達到同樣效果？",
+      "code": "// 舊寫法\nconst mapStateToProps = (state) => ({ count: state.counter.count });\nconst mapDispatchToProps = { increment };\nexport default connect(mapStateToProps, mapDispatchToProps)(Counter);",
+      "options": [
+        { "id": "a", "text": "用 useSelector 讀取 state、useDispatch 拿到 dispatch 函式", "code": "function Counter() {\n  const count = useSelector((state) => state.counter.count);\n  const dispatch = useDispatch();\n  return <button onClick={() => dispatch(increment())}>{count}</button>;\n}" },
+        { "id": "b", "text": "直接 import store 這個全域變數，手動呼叫 store.getState()", "code": "function Counter() {\n  const count = store.getState().counter.count;\n  const dispatch = store.dispatch;\n  return <button onClick={() => dispatch(increment())}>{count}</button>;\n}" },
+        { "id": "c", "text": "用 useContext 手動讀取一個自訂的 Redux context", "code": "function Counter() {\n  const { count } = useContext(ReduxContext);\n  return <button>{count}</button>;\n}" },
+        { "id": "d", "text": "用 useState 搭配一個模組層級的全域變數手動同步", "code": "let globalCount = 0;\nfunction Counter() {\n  const [count, setCount] = useState(globalCount);\n  return <button>{count}</button>;\n}" }
+      ],
+      "answer": "a",
+      "explanation": "useSelector 與 useDispatch 是 react-redux 提供的 Hooks，效果等同 connect() 高階元件，但不需要額外包一層、也不用手寫 mapStateToProps/mapDispatchToProps。useSelector 內部還會自動比對選出來的值，只有真的變動時才觸發這個元件重繪；選項 b 手動呼叫 store.getState() 拿不到「state 變了自動重新渲染」這個能力，UI 不會跟著 store 更新。",
+      "verify": {
+        "checks": [],
+        "manual": "react-redux 未安裝於本專案，useSelector 的訂閱與自動重繪機制需要真實 store 與元件掛載才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-4-q4",
+      "type": "fill-in",
+      "difficulty": 2,
+      "topic": "為什麼 Redux 的核心函式叫做「reducer」",
+      "docs": "https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/reduce",
+      "story": "",
+      "prompt": "Redux 的核心函式取名叫「reducer」不是巧合——概念上跟 JavaScript 原生的 Array.prototype.reduce 是同一件事：把一連串的 action，依序『摺疊』成最終的 state。用原生陣列方法重現這個概念，把空格填起來",
+      "code": "const actions = [\n  { type: \"INCREMENT\" },\n  { type: \"INCREMENT\" },\n  { type: \"DECREMENT\" },\n];\n\nfunction counterReducer(state, action) {\n  switch (action.type) {\n    case \"INCREMENT\": return state + 1;\n    case \"DECREMENT\": return state - 1;\n    default: return state;\n  }\n}\n\nconst finalCount = actions.____(counterReducer, 0);\nconsole.log(finalCount);",
+      "options": [
+        { "id": "a", "text": "reduce" },
+        { "id": "b", "text": "map" },
+        { "id": "c", "text": "forEach" },
+        { "id": "d", "text": "fold" }
+      ],
+      "answer": "a",
+      "explanation": "Array.prototype.reduce(callback, initialValue) 依序把陣列裡每個元素跟目前的累積值丟進 callback，得到新的累積值——這正是 Redux store 內部真正在做的事：把 action 陣列（歷史上每一次 dispatch）依序丟進 reducer、從 initialState 開始不斷累積出最終的 state。map 是一對一轉換、不會累積；forEach 沒有回傳值；fold 是其他語言（如 Haskell）對同個概念的稱呼，JavaScript 原生方法就叫 reduce。",
+      "verify": {
+        "checks": [
+          { "code": "const actions = [\n  { type: \"INCREMENT\" },\n  { type: \"INCREMENT\" },\n  { type: \"DECREMENT\" },\n];\n\nfunction counterReducer(state, action) {\n  switch (action.type) {\n    case \"INCREMENT\": return state + 1;\n    case \"DECREMENT\": return state - 1;\n    default: return state;\n  }\n}\n\nconst finalCount = actions.reduce(counterReducer, 0);\nconsole.log(finalCount);", "expected": "1" }
+        ]
+      }
+    },
+    {
+      "id": "ri-4-q5",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "createAsyncThunk 取代手刻 thunk 管理三種非同步狀態",
+      "docs": "",
+      "story": "",
+      "prompt": "要發送一個非同步 API 請求，並依結果 dispatch 不同的 action（pending / fulfilled / rejected）。Redux Toolkit 建議的標準寫法是什麼？",
+      "code": "// 手刻 thunk（舊寫法，仍然合法，但要自己管三種狀態）\nfunction fetchUserLegacy(id) {\n  return async (dispatch) => {\n    dispatch({ type: \"user/pending\" });\n    try {\n      const res = await fetch(`/api/user/${id}`);\n      const data = await res.json();\n      dispatch({ type: \"user/fulfilled\", payload: data });\n    } catch (err) {\n      dispatch({ type: \"user/rejected\", error: err.message });\n    }\n  };\n}\n\n// Redux Toolkit 建議的寫法？\nconst fetchUser = createAsyncThunk(\"user/fetch\", async (id) => {\n  const res = await fetch(`/api/user/${id}`);\n  return res.json();\n});",
+      "options": [
+        { "id": "a", "text": "createAsyncThunk 會依你傳入的非同步函式回傳的 Promise 狀態，自動 dispatch 對應的 pending/fulfilled/rejected action（action type 自動用你傳入的字首加上固定後綴）；不需要像手刻 thunk 那樣自己手動管理三種狀態、自己組三個 action type 字串，樣板程式碼少很多，也比較不容易漏掉某個狀態" },
+        { "id": "b", "text": "兩者完全等價，createAsyncThunk 只是換個名字，行為上沒有任何簡化" },
+        { "id": "c", "text": "createAsyncThunk 只能處理同步的 action，非同步請求還是得手刻 thunk" },
+        { "id": "d", "text": "createAsyncThunk 已經被 Redux 官方棄用，建議一律手刻 thunk" }
+      ],
+      "answer": "a",
+      "explanation": "手刻 thunk 要自己想三個 action type 字串、自己在每個分支手動 dispatch，容易漏掉某個狀態或字串打錯字不會被檢查出來。createAsyncThunk 把「非同步呼叫的三種狀態」這個重複出現的樣板抽象掉：只要傳入一個回傳 Promise 的函式，Toolkit 就自動幫你 dispatch 對應的 pending/fulfilled/rejected，剩下的工作只是在對應的 slice 裡用 extraReducers 監聽這三種狀態、更新 state。",
+      "verify": {
+        "checks": [],
+        "manual": "Redux Toolkit 未安裝於本專案，createAsyncThunk 的自動 dispatch 機制需要真實套件執行才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-4-q6",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "Redux 跟 Context 不是二選一，依狀態複雜度分別選擇",
+      "docs": "",
+      "story": "",
+      "prompt": "專案的認證資訊（目前登入者）原本用 Context 存放，運作得很好。後來需求變複雜：多個獨立的資料實體彼此有關聯查詢，需要在 DevTools 裡追蹤『這個 state 是被哪個 action 改的』，也常需要在使用者操作後復原到之前某個時間點的狀態。這時候該怎麼選？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "把『需要複雜追蹤、除錯、甚至要能時間旅行復原』的這部分狀態遷移到 Redux（搭配 Redux DevTools 的 action 記錄與時間旅行除錯）；單純、不常變動的資料傳遞（像認證資訊）繼續留在 Context 就好——兩者不是二選一的關係，可以依狀態的複雜度與除錯需求分別選擇" },
+        { "id": "b", "text": "既然已經用了 Context，就應該永遠只用 Context，避免引入 Redux 這個『不必要的複雜度』" },
+        { "id": "c", "text": "應該把所有 Context 都刪除，改成把所有狀態塞進單一個巨大的全域變數" },
+        { "id": "d", "text": "Redux 和 Context 功能完全重複，選哪一個都一樣，沒有任何取捨" }
+      ],
+      "answer": "a",
+      "explanation": "Context 設計初衷是解決「跨層級傳遞資料」這個問題，本身不提供 action 記錄、時間旅行除錯、中介軟體這些工具；Redux（尤其是 Redux DevTools）的價值恰好在「狀態變化的可觀測性、可除錯性」隨應用複雜度上升而變得重要時展現出來。實務上常見的做法就是共存：簡單、局部、不太需要除錯工具的狀態留在 Context，跨模組共享、變化複雜、需要被追蹤的狀態遷到 Redux，依需求分工而不是全有全無。",
+      "verify": {
+        "checks": [],
+        "manual": "屬架構選型的情境推理題，取決於團隊需求與工具鏈評估，無可執行程式碼。"
+      }
+    },
+    {
+      "id": "ri-4-q7",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "Flux 是架構理念，Redux 是它的一種具體實作",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊提到「Flux」跟「Redux」，有人以為兩者是同一套東西，只是換個名字。這樣理解正確嗎？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "不完全正確：Flux 是 Facebook 提出的一種『單向資料流』架構理念（Action → Dispatcher → Store → View），本身不是一個具體的函式庫，允許有多個 Store 各自管理一部分狀態；Redux 是受 Flux 啟發、但做了關鍵簡化的具體實作——把多個 Store 合併成一個唯一的 store、把 dispatcher 的角色簡化成純函式 reducer，兩者理念相近但不是同一份東西" },
+        { "id": "b", "text": "正確，Flux 與 Redux 是完全相同的技術，只是命名不同" },
+        { "id": "c", "text": "不正確，Flux 是比 Redux 晚出現的技術，是 Redux 的下一代版本" },
+        { "id": "d", "text": "不正確，Flux 專門用於行動裝置開發，Redux 專門用於網頁開發" }
+      ],
+      "answer": "a",
+      "explanation": "把 Flux 想成一套「設計理念」、Redux 想成「一種具體、經過簡化的實作」，會比較容易分清楚兩者關係。Flux 原始設計允許多個 Store、多個 Dispatcher 監聽者；Redux 刻意把這些簡化成單一 store、純函式 reducer，讓整個資料流變得更容易預測與除錯，也因此成為 Flux 理念下最廣為採用的實作之一。",
+      "verify": {
+        "checks": [],
+        "manual": "屬架構理念與具體實作的比較推理題，無可執行程式碼。"
+      }
+    },
+    {
+      "id": "ri-4-q8",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "Redux 相對 Flux 的隱性成本：強制不可變性的紀律要求",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊評估要不要把既有的 Flux 架構換成 Redux，有人提出「Redux 比 Flux 多了一項隱性成本」。下列哪個描述最準確？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "Redux 嚴格要求 state 更新必須維持不可變（每次都回傳全新物件），這比 Flux 相對寬鬆的做法多了一層紀律要求；團隊需要養成『絕不直接修改 state』的習慣，或引入像 Immer 這類工具協助，否則容易寫出『看起來更新了、其實還是同一個參考』的 bug" },
+        { "id": "b", "text": "Redux 完全不支援非同步操作，這是它跟 Flux 相比最大的缺點" },
+        { "id": "c", "text": "Redux 的套件大小遠比 Flux 笨重，是兩者最大的差異" },
+        { "id": "d", "text": "Redux 只能搭配 class component 使用，Flux 才能搭配函式元件" }
+      ],
+      "answer": "a",
+      "explanation": "Redux 的可預測性有很大一部分建立在「state 永遠不可變、每次都是全新物件」這個假設上（例如 UI 框架靠參考比對判斷要不要重繪，就仰賴這個假設）；這代表團隊得放棄「直接修改物件比較直覺」的寫法，改用展開運算子或 Immer 這類工具維護不可變性，是導入 Redux 需要額外付出、但 Flux 原始設計沒有強制要求的紀律成本。",
+      "verify": {
+        "checks": [],
+        "manual": "屬架構取捨的推理題，無可執行程式碼。"
+      }
+    },
+    {
+      "id": "ri-4-q9",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "在元件之外讀取 Redux store 目前的狀態",
+      "docs": "",
+      "story": "",
+      "prompt": "想在一個一般的工具函式（不是 React 元件）裡讀取 Redux store 目前的狀態，該怎麼做最直接？",
+      "code": "// store.js\nexport const store = createStore(rootReducer);\n\n// utils/logger.js\nimport { store } from \"../store\";\n\nfunction logCurrentUser() {\n  console.log(store.getState().user);\n}",
+      "options": [
+        { "id": "a", "text": "直接把 createStore() 建立出來的 store 實例匯出，其他模組（不管是不是 React 元件）都能 import 這個模組、呼叫 store.getState() 讀取當下狀態，這是最直接的做法；缺點是這種寫法把 store 變成一個可以被任意模組直接存取的全域物件，濫用容易讓資料流向變得不透明，官方建議盡量把這種存取集中在少數幾個明確的地方" },
+        { "id": "b", "text": "不可能做到，Redux store 只能在 React 元件內用 useSelector 讀取" },
+        { "id": "c", "text": "必須把 store 掛到 window 全域變數上才能在元件外部讀取" },
+        { "id": "d", "text": "只能透過 Redux DevTools 擴充功能才能讀到 store 的內容" }
+      ],
+      "answer": "a",
+      "explanation": "store 本質上就是一個包含 getState()／dispatch()／subscribe() 方法的普通物件，只要模組系統能匯出匯入它，任何檔案都能直接呼叫這些方法，不限於 React 元件。這在攔截器、工具函式這類非元件情境很常見，但也正因為太方便，官方提醒不要濫用——大部分情境下，元件內用 useSelector／useDispatch 才是建議的主要存取方式。",
+      "verify": {
+        "checks": [],
+        "manual": "Redux 未安裝於本專案，store 實例的匯出與存取需要真實套件執行才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-4-q10",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "MVW 雙向綁定的除錯困境：資料被誰改的難以追蹤",
+      "docs": "",
+      "story": "",
+      "prompt": "在 Flux/Redux 這類單向資料流架構流行之前，許多前端框架採用 MVW（Model-View-Whatever，例如雙向綁定的模式）。這種模式在大型協作應用裡，容易遇到什麼典型問題？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "雙向資料綁定讓『資料被誰改的』難以追蹤：一個 Model 可能同時被多個 View 綁定，任何一個 View 都能直接改動 Model，資料一多、綁定關係一複雜，除錯時很難回答『這個值是被哪裡的哪段程式碼改成現在這樣的』；單向資料流架構的出現，很大一部分正是為了解決這種『到處都能改、卻沒有一個清楚脈絡』的除錯困境" },
+        { "id": "b", "text": "MVW 模式完全沒有任何缺點，是效能最佳的架構模式" },
+        { "id": "c", "text": "MVW 模式的問題只在於命名太長，跟資料流向沒有任何關係" },
+        { "id": "d", "text": "MVW 模式的唯一問題是不支援任何測試框架" }
+      ],
+      "answer": "a",
+      "explanation": "雙向綁定的吸引力在於「改資料、畫面自動跟著變，改畫面、資料也自動跟著變」，寫小範例很方便；但這也代表任何一處都能直接寫入 Model，隨著協作規模、綁定關係增加，追蹤『這個欄位到底被誰改的』會變得非常困難。單向資料流（Action → 唯一入口 → 可預測的更新）正是為了讓這條追蹤路徑保持清楚、有限，才被提出來取代這種模式。",
+      "verify": {
+        "checks": [],
+        "manual": "屬架構歷史演進與除錯困境的推理題，無可執行程式碼。"
+      }
+    },
+    {
+      "id": "ri-4-q11",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "Redux 跟 RxJS 解決的是不同層次的問題，常常搭配使用",
+      "docs": "",
+      "story": "",
+      "prompt": "有人搞混 Redux 跟 RxJS，覺得兩者是互相替代的競爭方案。這個理解準確嗎？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "不太準確：Redux 是應用程式的『狀態管理架構』，回答『整個應用程式的資料該怎麼組織、怎麼更新』；RxJS 是『反應式程式設計函式庫』，核心是 Observable 這種處理非同步事件流的通用工具，回答的是『如何優雅地組合、轉換一連串隨時間發生的事件』——兩者解決的問題本來就不同，實務上也常常搭配使用（例如用 RxJS 處理 Redux 裡複雜的非同步副作用，這正是 redux-observable 這個中介軟體存在的原因）" },
+        { "id": "b", "text": "完全準確，Redux 與 RxJS 是同一類工具，只能二選一" },
+        { "id": "c", "text": "不準確，因為 RxJS 只能用在 Angular 專案，React 專案不能使用" },
+        { "id": "d", "text": "不準確，因為 Redux 已經被官方棄用，全面由 RxJS 取代" }
+      ],
+      "answer": "a",
+      "explanation": "Redux 關心「state 長什麼樣、怎麼被更新」，RxJS 關心「一連串隨時間發生的事件，怎麼被組合、過濾、轉換」。兩者的抽象層級不同，甚至可以疊加使用：redux-observable 這個 middleware，就是拿 RxJS 的 Observable 來描述 Redux 裡的非同步副作用流程，是兩者互補而非互斥的實際案例。",
+      "verify": {
+        "checks": [],
+        "manual": "屬工具定位與適用場景的比較推理題，無可執行程式碼。"
+      }
+    },
+    {
+      "id": "ri-4-q12",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "reset state：root reducer 攔截特定 action、強制重建整個 state",
+      "docs": "",
+      "story": "",
+      "prompt": "使用者登出時，想讓整個 store 的狀態全部重置回初始值，而不是保留舊資料。下面這個 rootReducer 的寫法，依序執行完兩次 INCREMENT、再 dispatch 一次 USER_LOGOUT 之後，counter 分別會顯示什麼？",
+      "code": "function counterReducer(state = 0, action) {\n  switch (action.type) {\n    case \"INCREMENT\": return state + 1;\n    default: return state;\n  }\n}\n\nfunction appReducer(state, action) {\n  return { counter: counterReducer(state?.counter, action) };\n}\n\nfunction rootReducer(state, action) {\n  if (action.type === \"USER_LOGOUT\") {\n    state = undefined;\n  }\n  return appReducer(state, action);\n}\n\nlet state = rootReducer(undefined, { type: \"@@INIT\" });\nstate = rootReducer(state, { type: \"INCREMENT\" });\nstate = rootReducer(state, { type: \"INCREMENT\" });\nconsole.log(state.counter); // 登出前\n\nstate = rootReducer(state, { type: \"USER_LOGOUT\" });\nconsole.log(state.counter); // 登出後",
+      "options": [
+        { "id": "a", "text": "登出前印出 2，登出後印出 0：rootReducer 攔截到 USER_LOGOUT 這個特定 action 時，故意把傳入 appReducer 的 state 覆寫成 undefined；而每個 reducer（包含 counterReducer）在收到 undefined 當作 state 時，都會退回自己宣告的預設值（這裡是 0），等於強制讓整棵 state 樹重新初始化一次，不需要手動一一清空每個欄位" },
+        { "id": "b", "text": "登出前印出 2，登出後仍然印出 2，USER_LOGOUT 這個判斷式完全不會生效" },
+        { "id": "c", "text": "登出前跟登出後都印出 0，INCREMENT 完全沒有作用" },
+        { "id": "d", "text": "程式會直接拋出例外，reducer 不能把 state 手動設成 undefined" }
+      ],
+      "answer": "a",
+      "explanation": "這是 Redux 官方推薦的「重置 state」手法：不用在每個 reducer 裡各自寫『收到 LOGOUT 就清空』的邏輯，而是在最外層的 rootReducer 統一攔截這個 action、把要傳給底下 appReducer 的 state 蓄意設成 undefined。每個 reducer 的參數預設值語法（state = 初始值）在收到 undefined 時就會自動生效，整棵狀態樹因此在一次攔截裡被優雅地重新初始化，不需要逐一清空每個 reducer 管理的欄位。",
+      "verify": {
+        "checks": [
+          { "code": "function counterReducer(state = 0, action) {\n  switch (action.type) {\n    case \"INCREMENT\": return state + 1;\n    default: return state;\n  }\n}\n\nfunction appReducer(state, action) {\n  return { counter: counterReducer(state?.counter, action) };\n}\n\nfunction rootReducer(state, action) {\n  if (action.type === \"USER_LOGOUT\") {\n    state = undefined;\n  }\n  return appReducer(state, action);\n}\n\nlet state = rootReducer(undefined, { type: \"@@INIT\" });\nstate = rootReducer(state, { type: \"INCREMENT\" });\nstate = rootReducer(state, { type: \"INCREMENT\" });\nconsole.log(state.counter);\n\nstate = rootReducer(state, { type: \"USER_LOGOUT\" });\nconsole.log(state.counter);", "expected": "2\n0" }
+        ]
+      }
+    },
+    {
+      "id": "ri-4-q13",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "純本地的 UI 互動狀態不需要放進 Redux",
+      "docs": "",
+      "story": "",
+      "prompt": "一個表單元件裡「這個欄位目前有沒有被 focus」這種純粹跟畫面互動有關、其他元件完全不關心的暫時性資料，需要放進 Redux store 嗎？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "不需要：Redux 官方建議只把『多個元件需要共享、或需要在應用程式生命週期中持續存在』的資料放進 store；像是否 focus 這類純粹侷限在單一元件內、沒有其他元件關心的 UI 狀態，留在元件本地的 useState 就好，硬塞進 Redux 只會讓 store 變得臃腫，每個小互動都要走一次 dispatch，反而失去在地狀態管理的簡便性" },
+        { "id": "b", "text": "需要，所有狀態不管有沒有共享需求都應該放進 Redux，這樣才算『集中管理』" },
+        { "id": "c", "text": "不需要，因為 Redux 技術上完全不支援儲存布林值" },
+        { "id": "d", "text": "需要，但只能放在 Redux 而不能同時搭配 useState 使用" }
+      ],
+      "answer": "a",
+      "explanation": "判斷一份資料該不該放進 Redux，關鍵問題是「這份資料需不需要被多個元件共享、或者需要在應用程式的生命週期裡持續存在」。單一元件內部的暫時性 UI 狀態（focus、hover、輸入框草稿）不符合這個條件，留在本地 state 反而更簡單直接；Redux 和 useState 完全可以在同一個應用程式裡並存，分別處理各自適合的那一類狀態。",
+      "verify": {
+        "checks": [],
+        "manual": "屬狀態放置位置的架構判斷題，無可執行程式碼。"
+      }
+    },
+    {
+      "id": "ri-4-q14",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "components／containers 資料夾切分：呈現邏輯跟資料來源邏輯分開",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊的資料夾裡有 components/ 跟 containers/ 兩個目錄，新人問這兩者的差異。下列哪個說法正確？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "components/ 放『呈現用』的元件，只負責『資料傳進來、畫面畫出來』，不知道 Redux 的存在；containers/ 放『連接 Redux』的元件，負責用 useSelector/useDispatch（或舊版 connect()）從 store 拿資料、組出 dispatch 函式，再把這些結果當 props 傳給底下對應的呈現元件——這是一種關注點分離：畫面邏輯跟『資料從哪來』的邏輯分開放" },
+        { "id": "b", "text": "兩者完全一樣，只是分別放在不同資料夾，沒有任何職責上的差異" },
+        { "id": "c", "text": "components/ 放測試檔案，containers/ 放正式程式碼" },
+        { "id": "d", "text": "containers/ 只能放 CSS 樣式檔案，不能放任何 JavaScript 邏輯" }
+      ],
+      "answer": "a",
+      "explanation": "這個切法背後的動機是關注點分離：呈現元件（components）只在乎「拿到什麼 props、畫出什麼畫面」，可以脫離 Redux 單獨測試、單獨重複使用；容器元件（containers）專心處理「怎麼從 store 拿資料、怎麼組 dispatch」，把結果交給呈現元件。這種切法在 Hooks 普及後不再是唯一慣例（很多團隊改成在元件內直接呼叫 useSelector），但作為理解「資料來源」與「畫面呈現」分離的概念仍然有參考價值。",
+      "verify": {
+        "checks": [],
+        "manual": "屬程式碼組織慣例的說明題，無可執行程式碼。"
+      }
+    },
+    {
+      "id": "ri-4-q15",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "action type 常數化：讓拼字錯誤能被工具抓出來",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊的 actions.js 跟 reducer.js 都各自手寫字串 \"ADD_TODO\"，有一次 reducer 裡不小心打成 \"ADD_TODOS\"（多了個 s），這個 bug 完全沒有跳出任何錯誤，只是 reducer 悄悄地『沒反應』。把這些字串統一抽成常數（兩邊都 import 同一個常數）能預防這類問題嗎？",
+      "code": "// actionTypes.js\nexport const ADD_TODO = \"ADD_TODO\";\n\n// actions.js\nimport { ADD_TODO } from \"./actionTypes\";\nexport function addTodo(text) {\n  return { type: ADD_TODO, text };\n}\n\n// reducer.js\nimport { ADD_TODO } from \"./actionTypes\";\n// switch (action.type) { case ADD_TODO: ... }",
+      "options": [
+        { "id": "a", "text": "能：把字串抽成一個常數並讓 actions.js 與 reducer.js 都從同一份檔案 import，只要其中一邊手誤打錯了常數的『變數名稱』（不是字串內容），編譯器或 IDE 就能立刻抓到『找不到這個匯出成員』的錯誤；相較之下，兩邊各自手打一模一樣的字串字面值，任何一邊拼錯都不會有任何工具自動抓出來，只能靠肉眼檢查或執行期偵錯" },
+        { "id": "b", "text": "不能，常數化只是美觀考量，跟能不能抓到拼字錯誤沒有任何關係" },
+        { "id": "c", "text": "能，但只有搭配 TypeScript 才有效，純 JavaScript 專案完全沒用" },
+        { "id": "d", "text": "不能，因為 JavaScript 常數在執行期會被自動轉成字串，效果跟直接寫字串一樣" }
+      ],
+      "answer": "a",
+      "explanation": "字串字面值本身沒有任何拼字檢查機制，兩處各自手打完全一樣的字串，編譯器完全看不出差異；但把字串包成一個具名的匯出常數之後，「打錯常數名稱」變成一個「引用了不存在的變數」的錯誤，這種錯誤在純 JavaScript 下執行期就會拋出 ReferenceError／undefined 匯出，搭配 IDE 或 linter 甚至能在寫程式碼的當下就標紅，不需要等到 TypeScript 才生效。",
+      "verify": {
+        "checks": [],
+        "manual": "屬程式碼組織與型別安全的推理題，無可執行程式碼。"
+      }
+    },
+    {
+      "id": "ri-4-q16",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "mapDispatchToProps 的物件簡寫等價於手動包 dispatch",
+      "docs": "",
+      "story": "",
+      "prompt": "mapDispatchToProps 有好幾種等價的寫法。下面兩種寫法，最終效果一樣嗎？",
+      "code": "// 寫法一\nconst mapDispatchToProps = (dispatch) => ({\n  addTodo: (text) => dispatch(addTodo(text)),\n});\n\n// 寫法二（物件簡寫）\nconst mapDispatchToProps = { addTodo };",
+      "options": [
+        { "id": "a", "text": "效果一樣：寫法二是官方提供的『物件簡寫』，connect() 內部看到 mapDispatchToProps 傳進來的是一個『action creator 組成的物件』而不是函式時，會自動幫每一個 action creator 包一層 (...args) => dispatch(actionCreator(...args))，效果等同寫法一手動包的那層 dispatch 呼叫，只是省去了重複的樣板程式碼" },
+        { "id": "b", "text": "效果不一樣，寫法二完全不會呼叫 dispatch，addTodo 只會被當成一般函式呼叫" },
+        { "id": "c", "text": "效果不一樣，寫法一才是合法寫法，寫法二會在執行期直接拋出例外" },
+        { "id": "d", "text": "效果一樣，但寫法二只能用在 TypeScript 專案" }
+      ],
+      "answer": "a",
+      "explanation": "connect() 對 mapDispatchToProps 這個參數做了型別判斷：傳函式就照函式的邏輯處理；傳一個『純粹由 action creator 組成的物件』，就自動幫每一個成員包上呼叫 dispatch 的那層包裝。兩種寫法最終呼叫端拿到的 props（addTodo）行為完全相同，物件簡寫只是省去重複樣板的語法糖。",
+      "verify": {
+        "checks": [],
+        "manual": "react-redux 未安裝於本專案，connect() 的內部型別判斷需要真實套件執行才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-4-q17",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "mapStateToProps 的 ownProps：依呼叫端 props 決定該挑哪份資料",
+      "docs": "",
+      "story": "",
+      "prompt": "mapStateToProps 的第二個參數 ownProps，什麼時候會用到？",
+      "code": "const mapStateToProps = (state, ownProps) => ({\n  active: ownProps.filter === state.visibilityFilter,\n});",
+      "options": [
+        { "id": "a", "text": "當『從 store 裡該挑哪一份資料』需要依賴這個元件自己收到的 props 才能決定時（例如這裡要判斷『目前這顆 FilterLink 對應的 filter，是不是恰好等於 store 裡目前選中的 visibilityFilter』，答案因每個 FilterLink 實例的 filter prop 而異），就需要透過 ownProps 讀到呼叫端傳入的 props，單靠 state 本身無法算出這個結果" },
+        { "id": "b", "text": "ownProps 是保留參數，任何情況下都不會真的有值" },
+        { "id": "c", "text": "ownProps 只在 class component 裡才有效，函式元件永遠拿到 undefined" },
+        { "id": "d", "text": "ownProps 會自動覆蓋 mapStateToProps 回傳的所有欄位" }
+      ],
+      "answer": "a",
+      "explanation": "大多數 mapStateToProps 只需要 state 這個參數；但當『該回傳什麼資料』本身跟呼叫端傳入的 props 有關（同一個元件的不同實例，因為 filter prop 不同，該回傳的 active 值也不同）時，就需要第二個參數 ownProps 讀到那些外部傳入的 props，兩者結合才能算出正確答案。",
+      "verify": {
+        "checks": [],
+        "manual": "react-redux 未安裝於本專案，connect() 的 ownProps 傳遞需要真實套件執行才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-4-q18",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "依職責種類切資料夾 vs 依功能模組切資料夾",
+      "docs": "",
+      "story": "",
+      "prompt": "一個中小型 Redux 專案，常見的頂層資料夾規劃是 components/、containers/、actions/、reducers/、store/。這種切法背後的組織原則是什麼，隨專案變大會遇到什麼取捨？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "依『職責種類』切割，而不是依『功能模組』切割：所有呈現元件放一起、所有連接 Redux 的容器放一起、所有 action creator 放一起、所有 reducer 放一起——這對小型專案容易維護（跟 Redux 有關的東西都各自集中），但當專案變大、模組數量變多時，常常會遇到『改一個功能要在五個不同資料夾各自找一個檔案』的不便，這也是後來 Redux Toolkit 推薦『依功能切割（feature folders，每個功能自帶自己的 slice、元件）』興起的背景" },
+        { "id": "b", "text": "這種切法只適用於後端專案，前端 React 專案不應該這樣規劃" },
+        { "id": "c", "text": "components/、containers/、actions/、reducers/ 這幾個資料夾名稱是 Redux 強制規定、不能自訂的" },
+        { "id": "d", "text": "這種切法完全不會隨專案規模產生任何維護上的差異" }
+      ],
+      "answer": "a",
+      "explanation": "依職責種類切割（也叫 rails-style/type-based 結構）在專案還小時很直覺，但隨著功能數量增加，同一個功能的相關程式碼會散落在好幾個平行資料夾裡，改一個功能要在多處跳來跳去。這正是 Redux Toolkit 官方文件明確建議改用「feature folders」（依功能模組切割，每個功能資料夾內包含自己的 slice、元件、測試）的原因——兩種切法沒有絕對優劣，是專案規模帶來的取捨。",
+      "verify": {
+        "checks": [],
+        "manual": "屬專案架構規劃的推理題，無可執行程式碼。"
+      }
+    },
+    {
+      "id": "ri-4-q19",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "redux-saga：用 Generator 描述非同步流程與副作用",
+      "docs": "",
+      "story": "",
+      "prompt": "redux-saga 是什麼，主要用來解決什麼問題？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "redux-saga 是 Redux 的中介軟體，讓開發者可以用 JavaScript 的 Generator 函式（function*）描述複雜的非同步流程與副作用（例如 API 呼叫、需要被取消的長時間任務、多個非同步動作間的協調），比起 redux-thunk 用 Promise 處理非同步，Generator 讓這些流程更容易被『暫停、恢復、測試』" },
+        { "id": "b", "text": "redux-saga 是取代 React Router 的路由函式庫" },
+        { "id": "c", "text": "redux-saga 是一種 CSS-in-JS 方案，用來取代 styled-components" },
+        { "id": "d", "text": "redux-saga 是 Redux 官方內建的功能，不需要額外安裝套件" }
+      ],
+      "answer": "a",
+      "explanation": "redux-saga 的核心賣點是用 Generator 函式描述非同步邏輯：yield 出去的每一步都是「描述要做什麼」，而不是直接執行，這讓整個流程可以被 middleware 控制節奏（暫停、恢復、取消），也讓測試變得容易——斷言「這一步 yield 出了什麼描述物件」，不需要真的觸發網路請求。",
+      "verify": {
+        "checks": [],
+        "manual": "redux-saga 未安裝於本專案，Generator 驅動的非同步流程需要真實套件執行才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-4-q20",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "Saga 像一條能被外部控制的獨立執行緒",
+      "docs": "",
+      "story": "",
+      "prompt": "「Saga 就像應用程式裡一個獨立的背景執行緒」這個常見比喻，具體指的是什麼？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "saga 是用 Generator 函式描述的一段長時間執行流程，可以被 redux-saga 這個 middleware 用一般的 Redux action 啟動、暫停、或取消，過程中它能讀取完整的 Redux state、也能 dispatch action 回 store——這種『能被外部訊號控制生命週期、又能跟主應用程式雙向溝通』的特性，很像作業系統裡一個可以被啟動/終止的獨立執行緒，而不是一次性、跑完就結束的函式呼叫" },
+        { "id": "b", "text": "saga 真的會建立一個作業系統層級的執行緒，跟 JavaScript 單執行緒的限制無關" },
+        { "id": "c", "text": "saga 只是 reducer 的另一種稱呼，沒有任何額外能力" },
+        { "id": "d", "text": "saga 只能執行一次，執行完之後就無法再次被啟動" }
+      ],
+      "answer": "a",
+      "explanation": "這個比喻強調的是「生命週期可被外部控制」這個特性，而不是真的涉及作業系統層級的多執行緒（JavaScript 仍然是單執行緒）。redux-saga 提供 takeEvery/takeLatest/cancel 這類機制，讓一段 Generator 流程能被『像管理一個背景任務一樣』啟動、取消，這是它跟一次性 Promise 鏈最大的行為差異。",
+      "verify": {
+        "checks": [],
+        "manual": "redux-saga 未安裝於本專案，Generator 生命週期的控制機制需要真實套件執行才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-4-q21",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "call() 與 put()：描述副作用，而不是立即執行",
+      "docs": "",
+      "story": "",
+      "prompt": "redux-saga 裡 call() 跟 put() 這兩個 effect creator，各自負責什麼？",
+      "code": "function* fetchUserSaga(action) {\n  const userData = yield call(api.fetchUser, action.userId);\n  yield put({ type: \"FETCH_USER_SUCCESS\", userData });\n}",
+      "options": [
+        { "id": "a", "text": "call(fn, ...args) 產生一個『指示 middleware 去呼叫某個函式（通常是回傳 Promise 的 API 呼叫）』的描述物件，middleware 收到後才真正執行並把結果餵回 yield 的位置；put(action) 產生一個『指示 middleware 去 dispatch 這個 action』的描述物件。兩者都只是『描述要做什麼』，不是立即執行，這讓 saga 的邏輯本身可以脫離真實的 side effect 被單獨測試（斷言『這段程式碼有沒有產生正確的描述物件』，不用真的發送網路請求）" },
+        { "id": "b", "text": "call() 用來呼叫 reducer，put() 用來呼叫 selector，兩者都跟非同步無關" },
+        { "id": "c", "text": "call() 和 put() 是同一個 effect 的兩種別名，沒有任何差異" },
+        { "id": "d", "text": "call() 只能呼叫同步函式，put() 只能呼叫非同步函式" }
+      ],
+      "answer": "a",
+      "explanation": "redux-saga 的一大特色是「effect 描述物件」：call()／put() 產生的都只是純資料物件，描述『middleware 該做什麼』，真正的執行交給 middleware 負責。這種「描述而非執行」的設計，讓 saga 的核心邏輯（該呼叫哪個 API、該 dispatch 哪個 action）可以在完全不碰真實網路的情況下被單元測試，只需要斷言 yield 出來的物件內容是否符合預期。",
+      "verify": {
+        "checks": [],
+        "manual": "redux-saga 未安裝於本專案，effect 描述物件的產生與執行需要真實套件執行才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-4-q22",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "何時該從 thunk 升級到 saga：非同步流程複雜度是關鍵",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊已經用 redux-thunk 處理大部分非同步邏輯，運作良好。什麼情境會讓團隊認真考慮改導入或補上 redux-saga？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "當非同步流程變得比『發一個請求、等結果』複雜很多時——例如需要『使用者打字時 debounce、只保留最後一次請求的結果』『長時間輪詢、且要能被使用者主動取消』『多個非同步動作需要嚴謹地依序協調、其中任何一步失敗要能整組復原』——這類流程用 Generator 描述、搭配 redux-saga 內建的取消、race、debounce 等 effect，通常比疊一堆巢狀 Promise/thunk 更容易維護與測試" },
+        { "id": "b", "text": "只要專案有任何一個 API 呼叫，就必須用 redux-saga，thunk 完全不能處理非同步" },
+        { "id": "c", "text": "改用 redux-saga 純粹是效能考量，thunk 在執行速度上一定比 saga 慢" },
+        { "id": "d", "text": "兩者無法在同一個專案裡共存，選了 thunk 就永遠不能再加入 saga" }
+      ],
+      "answer": "a",
+      "explanation": "thunk 用 Promise 處理『發請求、等結果』這種直線流程已經很夠用，也是多數團隊的預設選擇；saga 的優勢展現在流程本身變複雜的時候——debounce、可取消的長任務、多步驟協調復原，這些需求用 Generator 加上 redux-saga 內建的 effect 描述起來比手刻巢狀 Promise 更清楚。兩者也可以在同一個 store 裡共存，不是互斥的二選一。",
+      "verify": {
+        "checks": [],
+        "manual": "屬非同步架構選型的情境推理題，取決於實際流程複雜度，無可執行程式碼。"
+      }
+    },
+    {
+      "id": "ri-4-q23",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "Redux DevTools 關注 state 如何隨 action 演變",
+      "docs": "",
+      "story": "",
+      "prompt": "Redux DevTools 是什麼，它跟 React DevTools 的 Profiler 有什麼不同的關注焦點？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "Redux DevTools 專注在『state 怎麼隨著 action 一步步變化』：它記錄每一次 dispatch 的 action 內容與對應的 state 快照，讓開發者能『時間旅行』回到任意一步驟重新檢視、甚至重播；React DevTools 的 Profiler 關注的是『元件渲染效能』（誰重繪了、花多久），兩者分別對應 Redux 應用程式裡『資料如何演變』跟『畫面如何渲染』這兩個不同的關注層面" },
+        { "id": "b", "text": "兩者完全是同一個工具，只是安裝的擴充功能名稱不同" },
+        { "id": "c", "text": "Redux DevTools 只能在正式環境（production）使用，開發環境無法啟用" },
+        { "id": "d", "text": "Redux DevTools 專門用來偵錯 CSS 樣式問題，跟 state 管理無關" }
+      ],
+      "answer": "a",
+      "explanation": "兩套 DevTools 分別對應應用程式的兩個不同層面：資料怎麼變（Redux DevTools）跟畫面怎麼畫（React DevTools Profiler），實務上除錯一個效能或邏輯問題時常常需要交叉參照兩者——先用 Redux DevTools 確認 state 有沒有依預期變化，再用 Profiler 確認畫面重繪是否正常。",
+      "verify": {
+        "checks": [],
+        "manual": "Redux DevTools 為瀏覽器擴充功能，需要真實瀏覽器環境才能操作，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-4-q24",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "時間旅行除錯：取消某個 action、重新套用剩下的歷史",
+      "docs": "",
+      "story": "",
+      "prompt": "Redux DevTools 的「時間旅行除錯」具體能做到什麼？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "可以在錄製下來的一連串 action 裡『取消』掉中間某一個 action，讓 DevTools 從初始狀態開始，重新依序套用剩下的 action、算出一份『假設那個 action 沒發生過』的新 state；也能重新編輯某個 reducer 的程式碼後，讓已經記錄的 action 全部重新套用一次，立刻看到修正後的邏輯對歷史操作的影響，不需要重新操作一次應用程式" },
+        { "id": "b", "text": "只能讓應用程式回到重新整理頁面前的畫面，跟 state 內容無關" },
+        { "id": "c", "text": "只能顯示目前這一刻的 state，看不到任何歷史紀錄" },
+        { "id": "d", "text": "時間旅行除錯需要連上真實的伺服器時鐘同步功能才能運作" }
+      ],
+      "answer": "a",
+      "explanation": "「時間旅行」這個名稱形容的正是：因為每個 state 都是前一個 state 加上一個 action 純函式運算出來的新物件（reducer 的不可變特性），DevTools 才能『從頭重新播放』整段歷史、甚至跳過某一步驟，算出假設性的另一種結果——這種除錯能力完全建立在 Redux「state 更新是純函式、可重複執行」這個核心設計之上。",
+      "verify": {
+        "checks": [],
+        "manual": "Redux DevTools 為瀏覽器擴充功能，時間旅行除錯需要真實瀏覽器環境才能操作，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-4-q25",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "Selector：把 state 的形狀跟元件的使用方式解耦",
+      "docs": "",
+      "story": "",
+      "prompt": "元件想讀取 state.user.profile.displayName 這一層很深的資料。與其在元件裡直接寫這串很長的路徑，改成呼叫一個 getDisplayName = (state) => state.user.profile.displayName 的 selector 函式，有什麼好處？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "把『state 的形狀（shape）』跟『元件怎麼使用這份資料』這兩件事解耦：之後如果重構 state 的結構（例如把 profile 移到別的位置），只需要修改這一個 selector 函式內部的路徑，所有呼叫這個 selector 的元件完全不用改；如果元件各自直接寫死很長的路徑，state 結構一改就要滿專案搜尋、逐一修改" },
+        { "id": "b", "text": "selector 唯一的好處是讓程式碼變短，跟未來的可維護性完全無關" },
+        { "id": "c", "text": "selector 只能讀取頂層的 state，不能讀取巢狀很深的資料" },
+        { "id": "d", "text": "使用 selector 之後，state 的結構就永遠不能再改變" }
+      ],
+      "answer": "a",
+      "explanation": "Selector 最根本的價值是一層間接層：元件只依賴 selector 這個「介面」，不直接依賴 state 內部的具體結構。這讓 state 的形狀可以隨著應用程式演進而調整，只要對應更新 selector 內部的邏輯，呼叫端的元件完全不受影響——這跟前面提到的記憶化（reselect／createSelector）是 selector 的兩個不同但可疊加的好處。",
+      "verify": {
+        "checks": [],
+        "manual": "屬程式碼組織與解耦設計的推理題，無可執行程式碼。"
+      }
+    },
+    {
+      "id": "ri-4-q26",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "Redux Form 把高頻率本地狀態塞進全域 store 的代價",
+      "docs": "",
+      "story": "",
+      "prompt": "早期常見的 Redux Form 函式庫，把表單欄位的值也存進 Redux store 管理，每次按鍵都會 dispatch 一次 action。這種做法後來為什麼逐漸被 Formik、react-hook-form 這類「表單狀態留在元件本地」的方案取代？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "表單欄位值（例如使用者打字打到一半的內容）通常只有這個表單自己關心，不需要被其他元件共享，也不需要在整個應用程式生命週期持續存在；把每個按鍵都 dispatch 進 Redux store，等於讓一個高頻率變動、範圍侷限的本地狀態，繞了一大圈跑進全域狀態管理，多了不必要的效能開銷與樣板程式碼，這正好違反『只有真正需要共享的資料才放進 Redux』這個原則" },
+        { "id": "b", "text": "Redux Form 被取代純粹是因為授權條款出了問題，跟技術設計無關" },
+        { "id": "c", "text": "Formik、react-hook-form 其實內部還是用 Redux 實作，只是換了名字" },
+        { "id": "d", "text": "Redux Form 從技術上已經無法在任何現代瀏覽器執行" }
+      ],
+      "answer": "a",
+      "explanation": "這是「該不該放進 Redux」這條判斷原則（ri-4-q13 談過）在表單場景的具體案例：輸入框每一次按鍵都是高頻率、純粹侷限在表單內部的變動，讓它們都走一趟 dispatch → reducer → 訂閱通知的完整流程，是不必要的開銷。react-hook-form 這類方案改用 ref 搭配非受控元件、把重繪頻率降到最低，正是針對這個痛點的設計。",
+      "verify": {
+        "checks": [],
+        "manual": "屬表單狀態管理方案演進的推理題，無可執行程式碼。"
+      }
+    },
+    {
+      "id": "ri-4-q27",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "Redux Form 內建的驗證與格式化能省下重複樣板",
+      "docs": "",
+      "story": "",
+      "prompt": "Redux Form 除了把欄位值存進 Redux，還內建了哪些跟表單相關的功能，讓開發者不用自己刻？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "同步／非同步驗證與提交狀態管理、欄位值的格式化與正規化（例如把使用者輸入的『1,234』轉成數字 1234 再存進 state）——這些是表單開發裡重複出現的樣板需求，Redux Form 把它們內建成宣告式的設定，減少每個表單都要手刻同一套驗證/格式化邏輯" },
+        { "id": "b", "text": "Redux Form 只負責畫面上的 CSS 樣式，不處理任何驗證或格式化邏輯" },
+        { "id": "c", "text": "Redux Form 只能搭配特定後端語言撰寫的專案使用" },
+        { "id": "d", "text": "Redux Form 內建了完整的路由功能，可以取代 React Router" }
+      ],
+      "answer": "a",
+      "explanation": "驗證（這欄位是不是必填、格式對不對）與格式化（顯示成什麼樣子、存進 state 時轉成什麼型別）是幾乎每個表單都會重複遇到的需求，Redux Form 把這些收斂成宣告式的設定選項，讓開發者不用每個表單都重寫一套類似的邏輯，這是它當年受歡迎的核心賣點，即使後來被更輕量的方案取代。",
+      "verify": {
+        "checks": [],
+        "manual": "Redux Form 未安裝於本專案，驗證與格式化行為需要真實套件執行才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-4-q28",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "applyMiddleware 依序組成處理鏈，多個 middleware 可以並存",
+      "docs": "",
+      "story": "",
+      "prompt": "專案同時想用 redux-thunk 處理非同步、也想用 logger middleware 印出每次 dispatch 的內容方便除錯。這兩個 middleware 該怎麼一起套用到 store 上？",
+      "code": "import { createStore, applyMiddleware } from \"redux\";\n\nconst store = createStore(\n  rootReducer,\n  applyMiddleware(thunkMiddleware, loggerMiddleware)\n);",
+      "options": [
+        { "id": "a", "text": "applyMiddleware() 可以接收多個 middleware 當參數，依傳入順序組成一條處理鏈——每個 dispatch 出去的 action，會依序流過這條鏈上的每個 middleware（先流過 thunkMiddleware 判斷是不是函式型態的 thunk，再流過 loggerMiddleware 記錄），最後才真正送到 reducer；順序通常有意義，例如 logger 放在鏈的較後段才能記錄到『thunk 展開後』真正送進 reducer 的 action" },
+        { "id": "b", "text": "applyMiddleware() 一次只能接收一個 middleware，想用多個必須呼叫 createStore() 好幾次" },
+        { "id": "c", "text": "多個 middleware 之間互相衝突，同一個 store 不能同時使用兩個以上的 middleware" },
+        { "id": "d", "text": "middleware 的套用順序完全不重要，任何順序效果都一樣" }
+      ],
+      "answer": "a",
+      "explanation": "applyMiddleware() 的設計本來就支援組合多個 middleware，依參數順序串成一條處理鏈，每個 dispatch 都會依序流經。順序在某些情境下確實會影響行為——例如想讓 logger 印出「thunk 已經展開成真正 action」之後的內容，就得把 logger 排在 thunk 之後，這是實際串接多個 middleware 時需要留意的細節。",
+      "verify": {
+        "checks": [],
+        "manual": "Redux 未安裝於本專案，middleware 鏈的執行順序需要真實套件執行才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-4-q29",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "createStore 的第二個參數：設定 preloaded 初始狀態",
+      "docs": "",
+      "story": "",
+      "prompt": "想讓 Redux store 一開始就帶有預設的 todos 清單（例如伺服器端渲染時已經準備好的資料），該怎麼設定？",
+      "code": "const initialState = {\n  todos: [{ id: 123, name: \"example\", completed: false }],\n};\n\nconst store = createStore(rootReducer, initialState);",
+      "options": [
+        { "id": "a", "text": "createStore(reducer, preloadedState) 的第二個參數就是用來設定初始狀態的；store 建立時會用這份 preloadedState 取代各個 reducer 自己宣告的預設值（reducer 參數列表裡 state = 預設值 那一段），常見情境是 SSR 把伺服器端已經準備好的資料，透過這個參數『餵』給用戶端剛建立的 store，避免用戶端重新抓一次資料" },
+        { "id": "b", "text": "初始狀態只能寫死在每個 reducer 的預設參數裡，createStore() 不能接收任何初始狀態" },
+        { "id": "c", "text": "createStore() 的第二個參數是用來指定 middleware 的，不能拿來設定初始狀態" },
+        { "id": "d", "text": "設定初始狀態需要額外安裝一個獨立的第三方套件" }
+      ],
+      "answer": "a",
+      "explanation": "createStore 的第二個參數（preloadedState）正是為了讓 store 一開始就帶有指定的初始資料，跟每個 reducer 各自宣告的預設值是兩層不同的機制——preloadedState 有值時會蓋過 reducer 自己的預設值。這在 SSR 場景特別關鍵：伺服器渲染時已經抓好的資料，透過這個參數傳給用戶端 hydrate 時建立的 store，用戶端不用重新請求一次同樣的資料。",
+      "verify": {
+        "checks": [],
+        "manual": "Redux 未安裝於本專案，preloadedState 的實際套用需要真實套件執行才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-4-q30",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "Relay 專注伺服器 GraphQL 資料，Redux 是通用狀態容器",
+      "docs": "",
+      "story": "",
+      "prompt": "Relay 跟 Redux 都用「單一資料來源」的概念管理狀態，兩者最核心的差異是什麼？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "Relay 專門管理『源自伺服器、透過 GraphQL 查詢取得』的資料，資料的讀取（query）與寫入（mutation）都通過 GraphQL、由 Relay 自動處理快取與正規化；Redux 是一個通用的狀態容器，管理的狀態不限定來源（可能是伺服器資料、也可能是純粹的 UI 互動狀態），資料怎麼進到 store（用 fetch、用 GraphQL 都行）、reducer 怎麼寫，完全由開發者自己決定" },
+        { "id": "b", "text": "兩者完全是同一種技術，只是分別由不同公司命名" },
+        { "id": "c", "text": "Relay 只能管理 UI 互動狀態，不能處理任何伺服器資料" },
+        { "id": "d", "text": "Redux 只能搭配 REST API，技術上無法搭配 GraphQL 使用" }
+      ],
+      "answer": "a",
+      "explanation": "Relay 是針對「伺服器 GraphQL 資料」這個特定場景高度最佳化的框架，資料進出的方式（GraphQL 查詢與變更）幾乎是固定的；Redux 則是通用容器，不限定資料來源，也不限定跟後端溝通的協定，代價是這些整合細節（快取、正規化）需要開發者自己決定要不要做、怎麼做。",
+      "verify": {
+        "checks": [],
+        "manual": "屬資料層框架定位的比較推理題，無可執行程式碼。"
+      }
+    },
+    {
+      "id": "ri-4-q31",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "action 本質上是一個描述「發生了什麼事」的普通物件",
+      "docs": "",
+      "story": "",
+      "prompt": "Redux 裡的「action」，本質上是什麼？",
+      "code": "const action = {\n  type: \"ADD_TODO\",\n  text: \"Buy milk\",\n};\nstore.dispatch(action);",
+      "options": [
+        { "id": "a", "text": "一個普通的 JavaScript 物件，描述『發生了什麼事』，至少要有一個 type 欄位標明這是哪一種事件，其餘欄位放這個事件附帶的資料（payload）；action 本身不會做任何事，純粹是『一則通知』，真正決定 state 該怎麼變化的邏輯寫在 reducer 裡，action 只負責把『發生了什麼』這個資訊帶給 reducer" },
+        { "id": "b", "text": "action 是一個函式，直接負責修改 state 並回傳新的畫面" },
+        { "id": "c", "text": "action 是 Redux 內建的一種特殊資料庫連線物件" },
+        { "id": "d", "text": "action 只能是字串，不能攜帶任何額外資料" }
+      ],
+      "answer": "a",
+      "explanation": "action 是 Redux 資料流裡最基礎的單位：純粹的資料（一個帶 type 欄位的物件），不含任何邏輯。「發生了什麼」（action）跟「發生之後 state 該怎麼變」（reducer）是刻意分開的兩件事，這種分離讓 action 本身可以被記錄、重播、序列化，也是 Redux DevTools 時間旅行除錯得以運作的基礎。",
+      "verify": {
+        "checks": [
+          { "code": "const action = {\n  type: \"ADD_TODO\",\n  text: \"Buy milk\",\n};\nconsole.log(typeof action, action.type);", "expected": "object ADD_TODO" }
+        ]
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-5-native.json b/packages/core/src/data/questions/ri-5-native.json
new file mode 100644
index 0000000..f76e44b
--- /dev/null
+++ b/packages/core/src/data/questions/ri-5-native.json
@@ -0,0 +1,182 @@
+{
+  "id": "ri-5",
+  "title": "React Native 基礎概念",
+  "questions": [
+    {
+      "id": "ri-5-q1",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "沒有 DOM，畫面的最基本組成單位換成 View／Text",
+      "docs": "",
+      "story": "",
+      "prompt": "網頁版 React 用 <div>、<span> 這些 HTML 標籤當容器與文字載體。React Native 沒有瀏覽器、沒有 DOM，該怎麼改寫同一個卡片元件？",
+      "code": "// Web\nfunction Card() {\n  return (\n    <div className=\"card\">\n      <span>Hello</span>\n    </div>\n  );\n}",
+      "options": [
+        { "id": "a", "text": "用 View 當容器、Text 包住文字內容", "code": "function Card() {\n  return (\n    <View style={styles.card}>\n      <Text>Hello</Text>\n    </View>\n  );\n}" },
+        { "id": "b", "text": "直接沿用 div、span，RN 底層會自動轉譯成原生元件", "code": "function Card() {\n  return (\n    <div>\n      <span>Hello</span>\n    </div>\n  );\n}" },
+        { "id": "c", "text": "用 Container 和 Label 這兩個內建元件", "code": "function Card() {\n  return (\n    <Container>\n      <Label>Hello</Label>\n    </Container>\n  );\n}" },
+        { "id": "d", "text": "文字可以直接寫在最外層元件裡，不需要額外包一層", "code": "function Card() {\n  return <View style={styles.card}>Hello</View>;\n}" }
+      ],
+      "answer": "a",
+      "explanation": "React Native 沒有瀏覽器 DOM，View/Text/Image 這些是 RN 提供、實際對應到 iOS/Android 原生 UI 元件的「host components」，跟 Web 版的 div/span/img 是完全不同的底層實作。特別容易搞混的一點是：RN 裡任何文字內容都「必須」包在 <Text> 裡才能顯示，不像 HTML 允許文字節點直接飄在容器裡；選項 d 這種寫法在 RN 會直接報錯或無法正確渲染文字。",
+      "verify": {
+        "checks": [],
+        "manual": "React Native 未安裝於本專案，host components 的渲染行為需要真實 RN 執行環境才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-5-q2",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "沒有 CSS 檔案，樣式用 JavaScript 物件描述",
+      "docs": "",
+      "story": "",
+      "prompt": "React Native 沒有 CSS 檔案、沒有 className，元件的樣式該怎麼寫？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "用 JavaScript 物件描述樣式屬性（駝峰式命名，例如 backgroundColor 而不是 background-color），通常搭配 StyleSheet.create() 包裝、再透過 style prop 套用到元件上" },
+        { "id": "b", "text": "用 className 對應到一份獨立的 .css 檔案，跟 Web 開發完全一樣" },
+        { "id": "c", "text": "用行內字串描述樣式，語法跟 HTML 的 style=\"color: red;\" 完全相同" },
+        { "id": "d", "text": "RN 元件不能自訂樣式，只能使用作業系統預設外觀" }
+      ],
+      "answer": "a",
+      "explanation": "RN 的樣式是純 JavaScript 物件（屬性名稱採駝峰式，因為它們本質上是 JS 物件的 key，不是 CSS 語法），StyleSheet.create() 把這些物件包裝起來（好處包括：及早發現拼字錯誤的屬性名稱、效能上可以只序列化一次）。沒有真正的 CSS 檔案、也沒有 className 這個概念，跨元件共用樣式要靠匯出、匯入 JS 物件本身。",
+      "verify": {
+        "checks": [],
+        "manual": "React Native 未安裝於本專案，StyleSheet 的實際渲染效果需要真實 RN 執行環境才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-5-q3",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "flexDirection 預設值跟 Web CSS 相反",
+      "docs": "",
+      "story": "",
+      "prompt": "在網頁 CSS 裡，一個設了 display:flex 的容器，子元素預設會「水平排列」。把這個直覺原封不動帶到 React Native 的 View，會遇到什麼常見的意外？",
+      "code": "// Web：預設子元素水平排列（flex-direction 預設是 row）\n<div style={{ display: \"flex\" }}>\n  <div>A</div>\n  <div>B</div>\n</div>\n\n// React Native：View 預設也吃 flex 版面模型\n<View>\n  <Text>A</Text>\n  <Text>B</Text>\n</View>",
+      "options": [
+        { "id": "a", "text": "RN 的 View 預設 flexDirection 是 column（垂直排列），跟 Web CSS flexbox 預設的 row 正好相反；照搬 Web 的直覺、以為子元素會自動水平排成一列，實際上會看到 A 和 B 是上下疊放，需要自己顯式加上 style={{ flexDirection: 'row' }} 才能讓它們水平並排" },
+        { "id": "b", "text": "完全一樣，RN 的 flex 版面模型跟 Web CSS flexbox 的預設值完全相同" },
+        { "id": "c", "text": "RN 根本不支援 flex 版面，排版只能用絕對定位座標" },
+        { "id": "d", "text": "RN 會把子元素隨機排列，每次重新渲染的順序都不固定" }
+      ],
+      "answer": "a",
+      "explanation": "這是 Web React 開發者轉 RN 最常踩的坑之一：RN 的版面引擎（Yoga）雖然實作的是同一套 flexbox 規格，但把預設的 flexDirection 訂為 column，理由是行動裝置畫面上「一排一排往下疊」的版面遠比「並排」常見。凡是需要子元素水平排列的地方（例如一排按鈕），都得自己明確加上 flexDirection: 'row'，不能沿用 Web 的預設直覺。",
+      "verify": {
+        "checks": [],
+        "manual": "React Native 的 Yoga 版面引擎未安裝於本專案，flex 預設值的實際渲染效果需要真實 RN 執行環境才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-5-q4",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "平台專屬程式碼：.ios.js／.android.js 與 Platform.select",
+      "docs": "",
+      "story": "",
+      "prompt": "某個元件在 iOS 和 Android 需要不同的實作細節（例如陰影效果的寫法完全不同）。RN 提供哪種慣例，讓 bundler 自動依執行平台選出對應的程式碼？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "用 Platform.select({ ios: ..., android: ... }) 依平台切換某個屬性值，或者把整個檔案拆成 Button.ios.tsx / Button.android.tsx 兩份，import 時只寫 './Button'，Metro bundler 會依照實際執行的平台自動挑選對應的檔案打包進去" },
+        { "id": "b", "text": "用瀏覽器的 User-Agent 字串判斷平台，寫法跟 Web 開發完全一樣" },
+        { "id": "c", "text": "RN 不支援平台差異化，所有平台都必須共用完全相同的程式碼與樣式" },
+        { "id": "d", "text": "在 App 啟動時跳出對話框，讓使用者自己手動選擇目前是哪個平台" }
+      ],
+      "answer": "a",
+      "explanation": "RN 沒有瀏覽器、沒有 User-Agent 這回事，平台判斷是建置期（bundler）或執行期（Platform 模組）的機制：檔名帶 .ios / .android 後綴時，Metro bundler 在打包當下就只挑對應平台的那份檔案；Platform.select 則是執行期依 Platform.OS 動態切換某個值，兩種手法可以視情境搭配使用，是 RN 處理跨平台差異的標準做法。",
+      "verify": {
+        "checks": [],
+        "manual": "Metro bundler／Platform 模組未安裝於本專案，平台檔案選擇邏輯需要真實 RN 建置環境才能驗證，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-5-q5",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "Remote JS Debugging 讓 JS 跑在電腦的 V8，不是手機的引擎",
+      "docs": "",
+      "story": "",
+      "prompt": "早期 RN 常見的除錯方式是開啟「Debug JS Remotely」，讓 JS 程式碼實際上在電腦的 Chrome 分頁裡執行、透過連線把結果傳回手機顯示畫面。這種除錯方式最大的陷阱是什麼？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "JS 程式碼實際上是跑在 Chrome 的 V8 引擎，而不是手機上真正會用到的 JS engine（例如 Hermes）；某些跟效能、執行時序（timing）相關的 bug，因為兩種引擎的執行速度與行為細節不同，在 Chrome 除錯模式下可能重現不出來、或表現完全不一樣，等於在除錯一個『跟正式環境不完全一致』的執行環境" },
+        { "id": "b", "text": "完全沒有陷阱，Chrome 除錯模式下的行為保證跟手機上執行時一模一樣" },
+        { "id": "c", "text": "這種除錯方式只能檢查樣式問題，完全無法除錯任何 JavaScript 邏輯" },
+        { "id": "d", "text": "這種除錯方式會讓正式上架後的 App 持續連著 Chrome，造成資安漏洞" }
+      ],
+      "answer": "a",
+      "explanation": "「在哪裡執行」跟「在哪裡除錯」如果不是同一個引擎，觀察到的行為就可能失真——這正是 Remote JS Debugging 最為人詬病的地方，也是後來 RN 社群逐漸轉向 Flipper、Hermes debugger 這類「直接連進手機上實際執行的引擎」除錯工具的原因，避免因為除錯環境跟正式執行環境不一致而追錯方向。",
+      "verify": {
+        "checks": [],
+        "manual": "React Native 除錯工具鏈未安裝於本專案，不同 JS 引擎間的行為差異需要真實裝置與除錯環境才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-5-q6",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "RN 元件測試：核心哲學跟 Web 版共通，只是換一套查詢對象",
+      "docs": "",
+      "story": "",
+      "prompt": "想測試一個 RN 元件「按下按鈕後畫面文字改變」，該怎麼做，跟 Web React 的測試方式有什麼共通或不同？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "概念上跟 Web 版 React Testing Library 完全一致（render 元件、查詢畫面元素、模擬使用者互動、斷言渲染結果），只是改用對應 RN host components（View/Text/TouchableOpacity 等）的版本，並搭配 Jest 的 RN 專用設定處理原生模組的 mock；『測行為、不測實作細節』這個核心哲學完全共通" },
+        { "id": "b", "text": "RN 元件完全無法用自動化測試，只能靠人工在實機上反覆點擊確認" },
+        { "id": "c", "text": "RN 測試必須連接一台實體 iOS/Android 裝置才能執行，CI 環境上完全跑不起來" },
+        { "id": "d", "text": "RN 沒有對應的測試工具，只能直接呼叫元件方法、手動比對回傳的物件內容" }
+      ],
+      "answer": "a",
+      "explanation": "「像使用者一樣測試」這個原則不因平台是 Web 還是 RN 而改變，差別只在於查詢的目標元件不同（Web 找 button/input，RN 找 TouchableOpacity/TextInput 這類觸控元件），以及需要額外設定去 mock 原生模組（相機、定位等），核心的渲染、互動、斷言流程是共通的方法論，也都能在 CI（無實體裝置）上執行。",
+      "verify": {
+        "checks": [],
+        "manual": "React Native Testing Library 未安裝於本專案，且需要真實測試環境才能觀察渲染與互動行為，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-5-q7",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "console.log 輸出位置：Metro 終端機是預設查看處",
+      "docs": "",
+      "story": "",
+      "prompt": "在 RN 元件裡呼叫 console.log('debug')，這段輸出預設會顯示在哪裡？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "預設會顯示在 Metro bundler 啟動時開啟的終端機視窗（Metro 的日誌輸出），這是 RN 開發時最常見的 log 查看位置；如果連上了 Chrome/Flipper 這類除錯工具，也可以在對應的 Console 面板看到同樣的訊息，但『原生層級』的日誌（如 Xcode 的 Console、Android 的 Logcat）預設不會直接顯示 JS 端的 console.log，除非額外設定橋接" },
+        { "id": "b", "text": "只會出現在 Xcode 的原生 Console，Metro 終端機完全不會顯示任何 JS 端的 log" },
+        { "id": "c", "text": "RN 完全不支援 console.log，必須改用 alert() 才能除錯" },
+        { "id": "d", "text": "只有連上實體裝置才會印出 log，模擬器上呼叫 console.log 完全沒有反應" }
+      ],
+      "answer": "a",
+      "explanation": "Metro（RN 的 JS bundler）在開發模式下會保持一個 WebSocket 連線，把 JS 端的 console 輸出即時轉送到啟動它的終端機視窗，這是最直接、不需要額外工具的查看方式。想要更完整的除錯體驗（互動式 console、網路請求檢查）才需要額外連上 Flipper 或瀏覽器除錯工具，跟原生層級的系統日誌（Logcat／Xcode Console）是彼此獨立的兩層。",
+      "verify": {
+        "checks": [],
+        "manual": "Metro bundler 的日誌輸出行為需要真實 RN 開發環境才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-5-q8",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "React、React DOM、React Native 共用 reconciler，渲染器不同",
+      "docs": "",
+      "story": "",
+      "prompt": "有人說「React Native 就是把 React 的元件語法拿來、換一套渲染引擎」，這句話精確嗎？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "大致精確：React、React DOM、React Native 共用同一套「reconciler」核心演算法（決定要更新哪些節點、怎麼比對前後兩棵樹），差異在於『渲染器（renderer）』——React DOM 把最終結果畫成瀏覽器的 DOM 節點，React Native 則是畫成 iOS/Android 的原生 UI 元件；寫法上共用 JSX、元件、Hooks 這套語言層級的東西，但最終『畫到哪裡去』完全是不同的渲染目標" },
+        { "id": "b", "text": "不精確，React Native 內部完全是另一套獨立語言，跟 React 的 JSX 語法只是長得像" },
+        { "id": "c", "text": "不精確，React Native 其實是把手機瀏覽器內嵌進 App 裡執行網頁版 React" },
+        { "id": "d", "text": "精確，但這代表 React Native 寫出來的 App 效能跟網頁完全一樣，沒有任何原生優勢" }
+      ],
+      "answer": "a",
+      "explanation": "React 的架構刻意把「決定什麼該變」（reconciler）跟「怎麼把變化畫出來」（renderer）分開，這正是 React、React DOM、React Native 能共用同一套心智模型（元件、props、state、Hooks）的原因。React DOM 的 renderer 操作瀏覽器 DOM API；React Native 的 renderer 透過橋接呼叫原生 UI 元件的建立與更新——渲染目標從瀏覽器換成手機系統原生元件，效能特性跟操作的是真正的原生 UI（不是內嵌瀏覽器），跟網頁版有本質上的不同。",
+      "verify": {
+        "checks": [],
+        "manual": "reconciler／renderer 分層架構屬 React 內部設計，需要原始碼層級的理解，無法用 node 直接驗證。"
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-6-ecosystem.json b/packages/core/src/data/questions/ri-6-ecosystem.json
new file mode 100644
index 0000000..b213796
--- /dev/null
+++ b/packages/core/src/data/questions/ri-6-ecosystem.json
@@ -0,0 +1,270 @@
+{
+  "id": "ri-6",
+  "title": "React 生態系與工具鏈",
+  "questions": [
+    {
+      "id": "ri-6-q1",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "PropTypes 是執行期檢查，TypeScript 是編譯期檢查",
+      "docs": "",
+      "story": "",
+      "prompt": "一個元件同時用 PropTypes 宣告 props 型別、專案也已經導入 TypeScript。呼叫端不小心傳錯型別時，這兩種機制分別在什麼時間點讓你發現問題？",
+      "code": "MyButton.propTypes = {\n  label: PropTypes.string.isRequired,\n};\n\nfunction MyButton({ label }: { label: string }) {\n  return <button>{label}</button>;\n}\n\n// 呼叫端誤傳了數字\n<MyButton label={42} />",
+      "options": [
+        { "id": "a", "text": "TypeScript 在『編譯期』（寫程式碼、型別檢查或 build 的當下）就會標紅報錯，讓問題在型別檢查或 build 階段就被攔截、開發者當下就看得到；PropTypes 是『執行期』檢查，只有這段程式碼真的被執行、元件真的渲染時，才會在 console 印出警告——如果剛好沒有使用者走到會觸發這個元件的路徑，PropTypes 的警告根本不會出現，問題可能一路帶到正式環境才被回報" },
+        { "id": "b", "text": "兩者完全一樣，都只在執行期才會被發現" },
+        { "id": "c", "text": "PropTypes 是編譯期檢查，TypeScript 只在執行期生效" },
+        { "id": "d", "text": "只要用了 TypeScript，PropTypes 的宣告就會被自動忽略，不會有任何效果" }
+      ],
+      "answer": "a",
+      "explanation": "這是兩種型別檢查機制最本質的差異：TypeScript 的檢查發生在你寫程式碼、執行 tsc 或 build 的那一刻，錯誤在程式碼真正跑起來之前就被攔下；PropTypes 沒有編譯步驟，它是包在元件裡的一段執行期程式碼，只有等到瀏覽器真的渲染這個元件、傳入的 props 真的不符合宣告時，才會透過 console.warn 印出警告——覆蓋率完全取決於使用者的操作路徑有沒有剛好經過。",
+      "verify": {
+        "checks": [],
+        "manual": "PropTypes 執行期警告需要真實渲染流程才能觀察，TypeScript 的編譯期檢查則需要建置工具鏈，兩者皆無法用 node 直接執行驗證。"
+      }
+    },
+    {
+      "id": "ri-6-q2",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "SVG 當 React 元件匯入，才能用 props 動態改色",
+      "docs": "",
+      "story": "",
+      "prompt": "想在一個 icon 上動態改變顏色（跟隨目前的 theme 色）。下面兩種引入 SVG 檔案的方式，哪一種辦得到？",
+      "code": "// 方式一\nimport logo from \"./logo.svg\";\n<img src={logo} alt=\"logo\" />\n\n// 方式二（透過建置工具把 svg 轉成元件）\nimport { ReactComponent as Logo } from \"./logo.svg\";\n<Logo fill=\"currentColor\" />",
+      "options": [
+        { "id": "a", "text": "方式二：把 SVG 當成 React 元件匯入，等於把 SVG 檔案內部的 <path> 等節點直接變成 JSX 的一部分，可以用 props（如 fill、stroke）動態控制顏色，甚至加上 onClick 事件；方式一的 <img src=...> 只是把 SVG 當成一張『圖片檔案』整包載入，圖片內部的顏色已經定型，外部沒辦法用 props 或 CSS 去改動裡面線條的顏色" },
+        { "id": "b", "text": "兩種方式效果完全一樣，img 標籤本來就能用 fill 屬性改變 SVG 內部顏色" },
+        { "id": "c", "text": "方式一才能動態改顏色，因為 img 標籤原生支援 CSS filter 直接改變圖片內部顏色" },
+        { "id": "d", "text": "SVG 檔案本來就不能用在 React 專案裡，只能使用點陣圖格式如 PNG" }
+      ],
+      "answer": "a",
+      "explanation": "<img> 標籤永遠是把 src 指向的檔案當成一張不透明的圖片載入，瀏覽器不會把圖片內部的向量節點暴露給外部 CSS 或 props 操作。把 SVG 轉譯成 React 元件（常見工具如 SVGR，許多建置工具鏈內建支援），本質上是把 SVG 檔案的 XML 結構轉成一段 JSX，內部的顏色、線條粗細都變成可以用 props 覆寫的屬性，這才具備「跟隨 theme 動態變色」的能力。",
+      "verify": {
+        "checks": [],
+        "manual": "SVGR／建置工具的 SVG 轉元件流程未安裝於本專案，無法用 node 直接執行驗證，需人工審核。"
+      }
+    },
+    {
+      "id": "ri-6-q3",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "styled-components 的取捨：開發彈性 vs 執行期成本",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊在討論要不要引入 styled-components。下列哪個描述，最準確反映它的取捨？",
+      "code": "const Button = styled.button`\n  background: ${(props) => (props.primary ? \"navy\" : \"white\")};\n  color: ${(props) => (props.primary ? \"white\" : \"navy\")};\n`;",
+      "options": [
+        { "id": "a", "text": "styled-components 讓樣式跟元件邏輯定義在同一個檔案，甚至能直接依 props 動態插值運算出 CSS（如範例），對「樣式需要根據互動狀態頻繁變化」的元件很方便；代價是每個樣式化元件在執行期都要額外計算並注入一段 CSS-in-JS，對效能較敏感、或已經有一套穩定 design system 的專案，靜態的 CSS Modules／Tailwind 這類『建置期就決定好樣式』的方案通常有更小的執行期負擔" },
+        { "id": "b", "text": "styled-components 完全沒有任何取捨，效能與開發體驗都優於其他所有 CSS 方案" },
+        { "id": "c", "text": "styled-components 只能用在 class component，函式元件無法使用" },
+        { "id": "d", "text": "使用 styled-components 之後，專案就完全不能再使用任何一般的 CSS 檔案" }
+      ],
+      "answer": "a",
+      "explanation": "任何工具的選型都該看取捨，不是單方面的優劣：styled-components 把「樣式跟著 props 動態變化」這件事做得很自然，代價是執行期需要額外的 CSS-in-JS 運算與注入；CSS Modules、Tailwind 這類方案把樣式決定在建置期完成，執行期幾乎零額外成本，但動態插值的彈性不如 CSS-in-JS 直覺。兩者可以在同一個專案裡因地制宜地並存，不是互斥的二選一。",
+      "verify": {
+        "checks": [],
+        "manual": "styled-components 未安裝於本專案，CSS-in-JS 的執行期效能特性需要實際效能量測工具才能驗證，無法用 node 直接執行驗證。"
+      }
+    },
+    {
+      "id": "ri-6-q4",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "用 React DevTools Profiler 找出不必要的重繪",
+      "docs": "",
+      "story": "",
+      "prompt": "一個列表元件效能不好，懷疑是「某個子元件明明 props 沒變卻一直重繪」。React DevTools 的 Profiler 分頁，怎麼幫你找到這個問題？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "開啟 Profiler 分頁的錄製功能、操作一輪畫面互動後停止，它會畫出這段期間每個元件『實際渲染了幾次、每次渲染花多少時間』的火焰圖，並且可以勾選『Highlight updates when components render』直接在畫面上用色塊標出正在重繪的元件；找到那個『props 沒變卻頻繁亮起』的元件，就是效能問題的候選對象，接下來才是判斷該不該用 React.memo 包起來" },
+        { "id": "b", "text": "Profiler 只能顯示元件樹的巢狀結構，沒辦法看出渲染次數或耗費時間" },
+        { "id": "c", "text": "必須手動在每個元件加上 console.log 才能觀察渲染次數，Profiler 完全幫不上忙" },
+        { "id": "d", "text": "Profiler 只在正式環境（production build）才能使用，開發模式下無法錄製" }
+      ],
+      "answer": "a",
+      "explanation": "React DevTools 的 Profiler 分頁正是為了「找出不必要的重繪」設計的工具：錄製一段互動、看火焰圖裡哪些元件被重複渲染、每次渲染耗時多少；搭配「Highlight updates」選項可以更直觀地在畫面上即時看到誰在重繪。找到候選元件之後，才進一步分析是不是因為 props 參考（reference）每次都變成新物件、或者真的需要用 memo／useMemo 優化。",
+      "verify": {
+        "checks": [],
+        "manual": "React DevTools 為瀏覽器擴充功能，Profiler 的錄製與火焰圖顯示需要真實瀏覽器環境才能操作，無法用 node 直接執行驗證。"
+      }
+    },
+    {
+      "id": "ri-6-q5",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "為什麼多數新專案選 TypeScript 而非 Flow",
+      "docs": "",
+      "story": "",
+      "prompt": "大多數近幾年啟動的新 React 專案，靜態型別選擇幾乎都是 TypeScript，而不是曾經流行的 Flow。下列哪個說法最貼近這個現象背後的原因？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "TypeScript 不僅限於 React／JavaScript 前端生態，而是從前端到 Node.js 後端、建置工具、第三方套件的社群型別定義都廣泛支援，形成的生態規模與工具鏈成熟度遠超過主要專注在 React 生態的 Flow；兩者本質上都做靜態型別檢查，差異主要在生態系網路效應與長期維護動能，不是語法能力的本質差距" },
+        { "id": "b", "text": "因為 Flow 完全沒有能力做靜態型別檢查，只能檢查執行期錯誤" },
+        { "id": "c", "text": "因為 TypeScript 是 React 官方唯一認可的型別系統，Flow 技術上已經無法搭配 React 使用" },
+        { "id": "d", "text": "因為 Flow 的語法比 TypeScript 複雜非常多，導致學習曲線過於陡峭" }
+      ],
+      "answer": "a",
+      "explanation": "Flow 和 TypeScript 在能力上高度重疊，都能做靜態型別檢查、型別推斷、泛型等。真正拉開差距的是生態系規模：TypeScript 覆蓋前後端整條工具鏈，社群維護的型別定義庫（DefinitelyTyped）數量龐大，IDE 支援也更成熟；這種網路效應讓新專案傾向選擇能拿到最完整型別支援的那一個，不是因為 Flow 技術上有什麼缺陷。",
+      "verify": {
+        "checks": [],
+        "manual": "屬生態系與工具鏈成熟度的比較推理題，無可執行程式碼。"
+      }
+    },
+    {
+      "id": "ri-6-q6",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "回答框架選型比較題的成熟心態",
+      "docs": "",
+      "story": "",
+      "prompt": "面試被問「React 和 Vue／Angular 比起來有什麼優勢」，下列哪種回答方式最能反映對前端框架選型的成熟理解？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "誠實列出 React 相對突出的特性（例如龐大生態系、Hooks 的組合彈性、React Native 讓 Web/Mobile 團隊共用部分知識），同時承認這些優勢是『取捨後』的結果而非無條件的絕對優越——例如 Vue 的模板語法對新手更直覺、Angular 內建更完整的一套慣例（路由、表單、依賴注入）；選型最終要看團隊背景、專案規模、長期維護需求，而不是宣稱某個框架全面碾壓其他框架" },
+        { "id": "b", "text": "斬釘截鐵地說 React 在任何情境下都是唯一正確答案，其他框架都是錯誤選擇" },
+        { "id": "c", "text": "說框架之間沒有任何差異，選哪一個都一樣，不需要進行任何比較" },
+        { "id": "d", "text": "避而不答，主張『框架比較』這種問題本來就不應該被拿出來討論" }
+      ],
+      "answer": "a",
+      "explanation": "成熟的技術判斷從來不是「哪個框架絕對最好」，而是「在什麼條件下，哪個選擇的取捨最划算」。誠實列出優勢、同時承認代價與情境限制，反映的是對技術選型有完整的成本效益思考，而不是無條件的信仰宣示——這種回答方式在面試裡通常也更能展現資深工程師的判斷力。",
+      "verify": {
+        "checks": [],
+        "manual": "屬技術溝通與職涯情境推理題，無可執行程式碼。"
+      }
+    },
+    {
+      "id": "ri-6-q7",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "reselect／createSelector：記憶化 selector 避免重複運算",
+      "docs": "",
+      "story": "",
+      "prompt": "一個 selector 每次都重新從 state 裡篩選、排序一份大清單，即使 state 根本沒變，元件依然每次重繪都重新算一次，效能有浪費。reselect（或 Redux Toolkit 內建的 createSelector）想解決的是什麼問題？",
+      "code": "// 沒有記憶化：每次呼叫都重新篩選＋排序\nconst getVisibleTodosWithoutMemo = (state) =>\n  state.todos.filter((t) => !t.completed).sort((a, b) => a.priority - b.priority);\n\n// 用 createSelector 記憶化\nconst getVisibleTodos = createSelector(\n  (state) => state.todos,\n  (todos) => todos.filter((t) => !t.completed).sort((a, b) => a.priority - b.priority)\n);",
+      "options": [
+        { "id": "a", "text": "createSelector 會記住『輸入值（這裡是 state.todos）』跟『上一次算出的結果』，只有當輸入值真的變了（用參考相等比較）才會重新執行篩選＋排序這段運算，輸入沒變就直接回傳快取的舊結果；這樣即使元件因為其他不相干的 state 變化而重繪，也不會浪費算力重複做同一份昂貴運算" },
+        { "id": "b", "text": "createSelector 只是把函式包一層 try/catch，跟效能沒有任何關係" },
+        { "id": "c", "text": "createSelector 會讓篩選結果自動存進 localStorage，跨頁面重新整理都不用重算" },
+        { "id": "d", "text": "createSelector 讓這段程式碼可以在 reducer 裡直接呼叫 dispatch" }
+      ],
+      "answer": "a",
+      "explanation": "reselect 的核心是「記憶化」：把一個 selector 拆成『輸入 selectors』與『計算函式』，只有輸入值改變時才重新執行計算函式，其餘時候直接回傳快取結果。這對「篩選、排序、彙整大量資料」這類昂貴的衍生計算特別有價值，避免每次任何 state 變動都觸發重新運算，即使變動的其實是完全不相干的另一塊 state。",
+      "verify": {
+        "checks": [],
+        "manual": "reselect／Redux Toolkit 未安裝於本專案，記憶化的參考比對機制需要真實套件執行才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-6-q8",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "圖示庫元件化：Font Awesome 用 React 元件取代 CSS class",
+      "docs": "",
+      "story": "",
+      "prompt": "想在專案裡用 Font Awesome 圖示庫，其中一種官方支援的做法是安裝對應的 React 套件，把圖示當成一個 React 元件使用，而不是像傳統網頁那樣載入一份 CSS、再用 class name 標記圖示。這種「元件化」的做法對 React 專案有什麼好處？",
+      "code": "// 傳統網頁寫法\n<i className=\"fa fa-home\"></i>\n\n// React 元件化寫法\nimport { FontAwesomeIcon } from \"@fortawesome/react-fontawesome\";\nimport { faHome } from \"@fortawesome/free-solid-svg-icons\";\n\n<FontAwesomeIcon icon={faHome} />",
+      "options": [
+        { "id": "a", "text": "元件化寫法讓圖示變成一個可以吃 props（例如 size、color、旋轉角度）的正常 React 元件，也能透過打包工具做 tree-shaking——只打包真正用到的圖示，不用整包字型檔案全部載入；傳統的 className=\"fa fa-home\" 依賴一份全域 CSS／字型檔定義所有圖示的樣式，不管用到幾個圖示都得載入整包資源" },
+        { "id": "b", "text": "兩種寫法在打包體積、可調整性上完全沒有差異，純粹是寫法偏好問題" },
+        { "id": "c", "text": "元件化寫法只能在 TypeScript 專案使用，一般 JavaScript 專案必須用傳統寫法" },
+        { "id": "d", "text": "使用元件化寫法之後，圖示就不能再透過 CSS 調整大小或顏色" }
+      ],
+      "answer": "a",
+      "explanation": "把圖示變成 React 元件之後，每個圖示就是一個獨立的可匯入模組，打包工具能分析出「這個專案實際用到哪些圖示」，只把用到的打進最終產物；傳統的字型檔＋className 方案沒有這種細粒度，通常得整包字型一起載入。元件化也讓圖示能像其他 React 元件一樣接收 props，寫法上更貼近 React 的慣例。",
+      "verify": {
+        "checks": [],
+        "manual": "@fortawesome/react-fontawesome 未安裝於本專案，打包體積與 tree-shaking 效果需要實際建置流程才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-6-q9",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "React DevTools 抓不到 file:// 開頭的本機頁面",
+      "docs": "",
+      "story": "",
+      "prompt": "React DevTools 瀏覽器擴充功能，在大部分網站上都能正常抓到 React 元件樹，唯獨直接用 file:// 開啟本機 HTML 檔案測試時卻完全抓不到、Components 分頁整個是空的。最可能的原因是什麼？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "瀏覽器擴充功能預設不會被授權存取 file:// 開頭的本機檔案（這是瀏覽器對擴充功能的安全限制，不是 React DevTools 本身的 bug）；需要到瀏覽器的擴充功能管理頁面，針對 React DevTools 額外打開『允許存取檔案網址』這個選項，才能讓它在 file:// 頁面上運作" },
+        { "id": "b", "text": "React DevTools 從來沒有支援過本機檔案，這是設計上的硬限制，沒有任何解法" },
+        { "id": "c", "text": "本機檔案需要先安裝 Node.js 才能被 React DevTools 偵測到" },
+        { "id": "d", "text": "問題出在 React 版本太舊，升級到最新版就能自動解決" }
+      ],
+      "answer": "a",
+      "explanation": "瀏覽器對擴充功能存取 file:// 協定有額外的安全限制，預設是關閉的，這跟擴充功能本身寫得好不好無關。這也是很多瀏覽器擴充功能（不只 React DevTools）在本機檔案上「看起來完全沒作用」的常見成因，排查時第一步該檢查的是擴充功能的權限設定，而不是懷疑套件版本或程式碼本身。",
+      "verify": {
+        "checks": [],
+        "manual": "瀏覽器擴充功能的權限設定需要真實瀏覽器操作才能驗證，無法用 node 直接執行驗證。"
+      }
+    },
+    {
+      "id": "ri-6-q10",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "React 與 Web Components（如 Polymer）混用的限制",
+      "docs": "",
+      "story": "",
+      "prompt": "專案裡想沿用一批既有的 Polymer（Web Components 標準）元件，跟 React 元件混用。下列哪個描述最貼近兩者互通時常見的限制？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "Web Components（包含用 Polymer 寫的）可以直接當成一般 HTML 標籤放進 JSX 裡渲染，但 React 對它的屬性傳遞主要走『字串型別的 HTML attribute』，複雜資料型別（物件、陣列、函式）通常沒辦法直接當 prop 傳進去，得改用 ref 抓到真實 DOM 節點、手動賦值屬性或呼叫其方法／監聽自訂事件，才能傳遞複雜資料或處理事件" },
+        { "id": "b", "text": "React 完全無法與任何 Web Components 共存，必須把所有 Polymer 元件都改寫成 React 元件才能使用" },
+        { "id": "c", "text": "Web Components 與 React 元件之間可以無縫傳遞任何型別的 props，包括函式與物件，沒有任何限制" },
+        { "id": "d", "text": "混用 Polymer 元件會導致 React 應用程式完全無法啟動" }
+      ],
+      "answer": "a",
+      "explanation": "React 對待 Web Components（自訂元素）基本上是把它們當成一般 HTML 標籤處理，屬性傳遞走的是瀏覽器原生的 attribute 機制（字串為主），不像傳給 React 元件的 props 可以直接傳任意 JavaScript 值。想傳物件、陣列給 Web Component，或監聽它觸發的自訂事件，通常需要透過 ref 拿到底層 DOM 節點後手動操作，不能直接當成一般 React 元件的 props 傳遞。",
+      "verify": {
+        "checks": [],
+        "manual": "Polymer／Web Components 的互通行為需要真實瀏覽器與自訂元素定義才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-6-q11",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "React DevTools 的分頁消失不見",
+      "docs": "",
+      "story": "",
+      "prompt": "打開瀏覽器開發者工具，React DevTools 應該要出現「Components」「Profiler」這兩個分頁，但整個消失不見，只剩瀏覽器原生的 Elements、Console 等分頁。最常見的原因是什麼？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "目前這個頁面沒有被偵測到使用 React（例如頁面實際上是純靜態 HTML、或整個頁面還沒載入完成），React DevTools 只有在偵測到頁面確實載入了 React 執行環境時，才會顯示這兩個專屬分頁；也可能是分頁需要重新整理頁面後才會被重新偵測到，或擴充功能需要重新啟用" },
+        { "id": "b", "text": "這是瀏覽器的 bug，跟頁面有沒有使用 React 完全無關" },
+        { "id": "c", "text": "只有付費版的 React DevTools 才會顯示這兩個分頁" },
+        { "id": "d", "text": "必須先在該網域上登入 GitHub 帳號才能解鎖這兩個分頁" }
+      ],
+      "answer": "a",
+      "explanation": "React DevTools 的運作方式是在頁面載入時偵測是否存在 React 的執行時期標記，只有偵測到才會啟用對應的分頁。最常見的「分頁不見了」原因就是頁面本身沒有使用 React、頁面還在載入中、或者擴充功能因為某些原因未被啟用；這跟付費與否、登入帳號都無關，是免費且不需要登入即可使用的工具。",
+      "verify": {
+        "checks": [],
+        "manual": "瀏覽器擴充功能的偵測時機需要真實瀏覽器操作才能驗證，無法用 node 直接執行驗證。"
+      }
+    },
+    {
+      "id": "ri-6-q12",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "Relay：把資料需求宣告跟元件綁在一起",
+      "docs": "",
+      "story": "",
+      "prompt": "Relay 是 Facebook 官方維護、專門搭配 GraphQL 使用的資料層框架。跟直接用 fetch 手動呼叫 GraphQL API 相比，Relay 提供的核心價值是什麼？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "Relay 把『元件需要哪些資料欄位』跟『元件本身』綁定在一起宣告（每個元件宣告自己的 GraphQL fragment），框架會在建置階段把整棵元件樹用到的 fragment 自動組合成一個最終查詢，並且處理快取、資料正規化、只重新抓取真正變動的部分；手動 fetch 得自己維護一份龐大又容易跟畫面脫節的查詢字串，也得自己刻快取與資料正規化邏輯" },
+        { "id": "b", "text": "Relay 只是 fetch 的別名，兩者功能完全一樣" },
+        { "id": "c", "text": "Relay 只能用來取代 CSS-in-JS 方案，跟資料抓取無關" },
+        { "id": "d", "text": "Relay 要求後端必須改用 REST API，不能搭配 GraphQL" }
+      ],
+      "answer": "a",
+      "explanation": "Relay 的設計哲學是「資料需求跟著元件走」：每個元件透過 GraphQL fragment 宣告自己需要哪些欄位，不用關心其他元件需要什麼，框架在建置與執行階段把整棵樹的 fragment 組合、去重、快取，並且能精準判斷『哪些資料真的變了、只重新抓那一部分』。這一整套快取與正規化機制是手動 fetch 很難自己重新實作到同樣完整度的。",
+      "verify": {
+        "checks": [],
+        "manual": "Relay 未安裝於本專案，且需要 GraphQL 後端與建置階段的查詢組合機制才能觀察，無法用 node 直接驗證。"
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-7-misc.json b/packages/core/src/data/questions/ri-7-misc.json
new file mode 100644
index 0000000..deaf65d
--- /dev/null
+++ b/packages/core/src/data/questions/ri-7-misc.json
@@ -0,0 +1,144 @@
+{
+  "id": "ri-7",
+  "title": "React 進階探索：SSR 與渲染陷阱",
+  "questions": [
+    {
+      "id": "ri-7-q1",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "JSX 自動逃逸文字內容，防止注入攻擊",
+      "docs": "https://react.dev/learn/writing-markup-with-jsx",
+      "story": "",
+      "prompt": "留言區把使用者輸入的文字直接放進 JSX 裡顯示。如果使用者刻意輸入一段像是 <img src=x onerror=alert(1)> 的內容想觸發 XSS，這段程式碼渲染出的 HTML 實際上會是什麼？",
+      "code": "function Comment({ text }) {\n  return <p>{text}</p>;\n}\n\nconsole.log(renderToStaticMarkup(<Comment text={\"<img src=x onerror=alert(1)>\"} />));",
+      "options": [
+        { "id": "a", "text": "<p>&lt;img src=x onerror=alert(1)&gt;</p> —— JSX 把 {text} 這種放進大括號的內容一律當成純文字處理，渲染前會把 <、> 這類會被瀏覽器解讀成標籤的字元自動轉成 HTML 實體，瀏覽器收到的是『看起來像標籤，其實是一串逃脫過的純文字』，不會真的建立一個 img 節點，onerror 也就沒有機會被觸發" },
+        { "id": "b", "text": "<p><img src=x onerror=alert(1)></p> —— JSX 會把字串內容直接當成 HTML 解析並插入，這段程式碼確實有 XSS 風險" },
+        { "id": "c", "text": "程式會直接拋出例外，JSX 不允許在大括號裡放置任何包含尖括號的字串" },
+        { "id": "d", "text": "畫面上什麼都不會顯示，JSX 會靜默丟棄含有特殊字元的內容" }
+      ],
+      "answer": "a",
+      "explanation": "React 對「放進 JSX 大括號的值」預設一律當成文字內容處理，渲染前會逃逸掉 <、>、& 這些對 HTML 有特殊意義的字元。這正是 React 天生對抗 XSS 的機制：除非你刻意繞過這層保護（例如使用 dangerouslySetInnerHTML，光是名字就在提醒你這麼做很危險），否則使用者輸入的內容永遠只會被當成文字顯示，不會被瀏覽器誤判成真正的標籤去執行。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Comment({ text }) {\n  return <p>{text}</p>;\n}\nconsole.log(renderToStaticMarkup(<Comment text={\"<img src=x onerror=alert(1)>\"} />));", "expected": "<p>&lt;img src=x onerror=alert(1)&gt;</p>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-7-q2",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "Keyed Fragment：不必多包一層 div 也能帶 key",
+      "docs": "https://react.dev/reference/react/Fragment",
+      "story": "",
+      "prompt": "在陣列渲染裡，每個項目除了自己的內容外還想帶一個 key，但不想多包一層沒有語意的 div（會破壞 dl/dt/dd 這種必須緊鄰的語意結構）。下面這樣寫，最終渲染出的 HTML 裡會不會出現額外的包裝節點？",
+      "code": "function Glossary({ items }) {\n  return (\n    <dl>\n      {items.map((item) => (\n        <React.Fragment key={item.id}>\n          <dt>{item.term}</dt>\n          <dd>{item.description}</dd>\n        </React.Fragment>\n      ))}\n    </dl>\n  );\n}\n\nconsole.log(renderToStaticMarkup(<Glossary items={[{ id: 1, term: \"A\", description: \"Apple\" }]} />));",
+      "options": [
+        { "id": "a", "text": "不會：<React.Fragment key={...}> 是唯一支援帶 key 屬性的 Fragment 寫法（簡寫的 <>...</> 語法不能傳任何屬性，包括 key），渲染結果完全不會多出一層包裝元素，dt/dd 會直接變成 dl 的子節點，同時 React 也拿到了必要的 key 來追蹤陣列裡的每一項" },
+        { "id": "b", "text": "會，React.Fragment 渲染出來還是會變成一個 div 節點" },
+        { "id": "c", "text": "不會多包裝元素，但因為沒有真正的 DOM 節點，React 也就沒辦法讀到 key，等於白寫了" },
+        { "id": "d", "text": "會多一層 <React.Fragment> 標籤直接出現在最終的 HTML 裡" }
+      ],
+      "answer": "a",
+      "explanation": "Fragment（不管是完整寫法 <React.Fragment> 還是簡寫 <>）在渲染結果裡完全不會產生任何 DOM 節點，純粹是「幫子元素分組」用的邏輯容器；但簡寫語法犧牲了傳遞屬性的能力，需要帶 key（陣列渲染的必要條件）時，必須改回完整的 <React.Fragment key={...}> 寫法。key 是 React 內部用來追蹤元素身份的機制，跟這個節點會不會出現在最終 HTML 裡是兩件事，即使 Fragment 本身「消失」，key 依然對 React 的協調（reconciliation）演算法生效。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Glossary({ items }) {\n  return (\n    <dl>\n      {items.map((item) => (\n        <React.Fragment key={item.id}>\n          <dt>{item.term}</dt>\n          <dd>{item.description}</dd>\n        </React.Fragment>\n      ))}\n    </dl>\n  );\n}\nimport React from 'react'\nconsole.log(renderToStaticMarkup(<Glossary items={[{ id: 1, term: \"A\", description: \"Apple\" }]} />));", "expected": "<dl><dt>A</dt><dd>Apple</dd></dl>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-7-q3",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "伺服器端渲染階段不會執行任何 Effect",
+      "docs": "https://react.dev/reference/react/useLayoutEffect",
+      "story": "",
+      "prompt": "這個元件同時用了 useEffect 跟 useLayoutEffect，各自都會印出一段文字。用 renderToStaticMarkup 在伺服器端渲染它，這兩行 log 會被印出來嗎？",
+      "code": "function Widget() {\n  useEffect(() => { console.log(\"useEffect ran\"); });\n  useLayoutEffect(() => { console.log(\"useLayoutEffect ran\"); });\n  return <p>hi</p>;\n}\n\nconsole.log(renderToStaticMarkup(<Widget />));\nconsole.log(\"done\");",
+      "options": [
+        { "id": "a", "text": "都不會印出來：伺服器端渲染只負責把元件『渲染成一段靜態 HTML 字串』，完全沒有真實的 DOM、沒有瀏覽器的繪製流程；useEffect 與 useLayoutEffect 本質上都是綁在『瀏覽器完成繪製之後（或之前）』這個時間點觸發的，SSR 階段連這個時間點都不存在，所以兩者都不會執行，只有 renderToStaticMarkup 回傳的 HTML 字串與 \"done\" 會被印出來" },
+        { "id": "b", "text": "只有 useLayoutEffect 會印出來，因為它是同步執行的，不需要等待瀏覽器繪製" },
+        { "id": "c", "text": "只有 useEffect 會印出來，因為它是非同步、不會阻塞渲染" },
+        { "id": "d", "text": "兩者都會印出來，只是印出的先後順序不同" }
+      ],
+      "answer": "a",
+      "explanation": "useEffect 和 useLayoutEffect 差別只在於「相對瀏覽器繪製的時機」（繪製之後 vs 之前），但兩者共同的前提都是「存在一次真正的瀏覽器繪製」。伺服器端渲染的產出只是一段字串，沒有真實 DOM、也沒有繪製這回事，這兩種 Effect 因此都不會被呼叫——這也是為什麼「拿資料」這種需要在 SSR 階段就先準備好的邏輯，不能指望寫在 useEffect 裡，要嘛在伺服器端用其他方式預先取好資料，要嘛等到用戶端 hydrate 之後才觸發。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { useEffect, useLayoutEffect } from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nfunction Widget() {\n  useEffect(() => { console.log(\"useEffect ran\"); });\n  useLayoutEffect(() => { console.log(\"useLayoutEffect ran\"); });\n  return <p>hi</p>;\n}\nconsole.log(renderToStaticMarkup(<Widget />));\nconsole.log(\"done\");", "expected": "<p>hi</p>\ndone" }
+        ]
+      }
+    },
+    {
+      "id": "ri-7-q4",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "同步 SSR 底下，Suspense 內的 lazy 元件永遠顯示 fallback",
+      "docs": "https://react.dev/reference/react/Suspense",
+      "story": "",
+      "prompt": "LazyWidget 用 React.lazy 動態載入，外層包了 Suspense、fallback 顯示 \"loading...\"。用 renderToStaticMarkup 渲染這棵樹，最後印出的是 fallback 內容，還是 lazy 元件真正要顯示的內容？",
+      "code": "const LazyWidget = lazy(() => Promise.resolve({ default: () => <p>loaded</p> }));\n\nfunction App() {\n  return (\n    <Suspense fallback={<p>loading...</p>}>\n      <LazyWidget />\n    </Suspense>\n  );\n}\n\nconsole.log(renderToStaticMarkup(<App />));",
+      "options": [
+        { "id": "a", "text": "印出 <p>loading...</p>：renderToStaticMarkup 是同步、一次性把整棵樹渲染完成的舊版 API，沒辦法『暫停』等待 lazy 元件背後的 Promise resolve；只要 Suspense 底下還有尚未 resolve 的非同步資源，這種同步渲染永遠只能拿到 fallback 內容，真正的內容要等到瀏覽器端 hydrate、Promise 真正 resolve 之後才會顯示出來" },
+        { "id": "b", "text": "印出 <p>loaded</p>：因為這裡的 Promise.resolve() 沒有非同步延遲，會立刻同步完成" },
+        { "id": "c", "text": "程式會直接拋出例外，Suspense 不能跟 renderToStaticMarkup 一起使用" },
+        { "id": "d", "text": "兩者都會印出，先顯示 loading... 過一小段時間後自動替換成 loaded" }
+      ],
+      "answer": "a",
+      "explanation": "即使 Promise 本身「立刻」resolve，JavaScript 的 Promise 一定是非同步微任務（microtask），不會在呼叫的當下同步拿到結果；而 renderToStaticMarkup 是一次性、同步跑完的舊版 API，不會等待任何微任務完成。這正是為什麼 React 官方後來推出串流式的 SSR API（如 renderToPipeableStream）取代這種舊版同步 API——只有串流版本才有能力『先送出 fallback，等資料真的到位後再補上真正的內容』。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { Suspense, lazy } from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nconst LazyWidget = lazy(() => Promise.resolve({ default: () => <p>loaded</p> }));\nfunction App() {\n  return (\n    <Suspense fallback={<p>loading...</p>}>\n      <LazyWidget />\n    </Suspense>\n  );\n}\nconsole.log(renderToStaticMarkup(<App />));", "expected": "<p>loading...</p>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-7-q5",
+      "type": "find-bug",
+      "difficulty": 3,
+      "topic": "Error Boundary 攔截不到同步 SSR 階段的錯誤",
+      "docs": "https://react.dev/reference/react/Component",
+      "story": "",
+      "prompt": "這個 ErrorBoundary 在瀏覽器裡執行完全正常——Bomb 拋出的錯誤會被接住，畫面顯示「發生錯誤了」。但如果改用 renderToStaticMarkup 在伺服器端渲染同一棵樹，會發生什麼事？",
+      "code": "class ErrorBoundary extends React.Component {\n  state = { hasError: false };\n  static getDerivedStateFromError() {\n    return { hasError: true };\n  }\n  render() {\n    if (this.state.hasError) return <p>發生錯誤了</p>;\n    return this.props.children;\n  }\n}\n\nfunction Bomb() {\n  throw new Error(\"boom\");\n}\n\nfunction App() {\n  return (\n    <ErrorBoundary>\n      <Bomb />\n    </ErrorBoundary>\n  );\n}\n\nconsole.log(renderToStaticMarkup(<App />));",
+      "options": [
+        { "id": "a", "text": "程式會直接拋出未捕捉的例外，renderToStaticMarkup 整個中斷、不會印出任何 HTML——Error Boundary 的攔截機制是設計給用戶端渲染／commit 階段使用的，並不涵蓋這種同步的伺服器端靜態渲染，Bomb 拋出的錯誤會直接往外傳，不會被 ErrorBoundary 接住" },
+        { "id": "b", "text": "伺服器端行為跟瀏覽器端一致，一樣會印出「發生錯誤了」這段 HTML" },
+        { "id": "c", "text": "伺服器端會印出空字串，不會有任何錯誤，也不會顯示任何 fallback 內容" },
+        { "id": "d", "text": "renderToStaticMarkup 遇到子元件拋出的錯誤時，會自動重試三次才真正拋出例外" }
+      ],
+      "answer": "a",
+      "explanation": "這是一個容易誤判的陷阱：Error Boundary 在瀏覽器端能攔截渲染錯誤，讓人直覺以為它在任何渲染環境都通用；但傳統同步的伺服器端渲染 API（renderToStaticMarkup／renderToString）並不會把子元件拋出的錯誤導向父層的 getDerivedStateFromError，錯誤會直接沿著呼叫堆疊往外拋，中斷整個渲染流程。想在伺服器端也優雅處理渲染錯誤，需要改用支援串流的新版 SSR API 搭配其提供的錯誤處理選項，不能只依賴 Error Boundary。",
+      "verify": {
+        "checks": [
+          { "jsx": "import React from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nclass ErrorBoundary extends React.Component {\n  state = { hasError: false };\n  static getDerivedStateFromError() {\n    return { hasError: true };\n  }\n  render() {\n    if (this.state.hasError) return <p>發生錯誤了</p>;\n    return this.props.children;\n  }\n}\nfunction Bomb() {\n  throw new Error(\"boom\");\n}\nfunction App() {\n  return (\n    <ErrorBoundary>\n      <Bomb />\n    </ErrorBoundary>\n  );\n}\nconsole.log(renderToStaticMarkup(<App />));", "expectError": "boom" }
+        ]
+      }
+    },
+    {
+      "id": "ri-7-q6",
+      "type": "predict-output",
+      "difficulty": 3,
+      "topic": "React 19：函式元件的 defaultProps 已失效",
+      "docs": "https://react.dev/blog/2024/04/25/react-19-upgrade-guide",
+      "story": "",
+      "prompt": "這段程式碼在 React 17／18 可以正常運作、沒傳 name 時會顯示預設的 Guest。換到 React 19 之後，畫面實際上會顯示什麼？",
+      "code": "function Greeting({ name }) {\n  return <p>Hello, {name}</p>;\n}\nGreeting.defaultProps = { name: \"Guest\" };\n\nconsole.log(renderToStaticMarkup(<Greeting />));",
+      "options": [
+        { "id": "a", "text": "<p>Hello, </p>（name 是空的）：React 19 移除了函式元件的 defaultProps 支援，Greeting.defaultProps 這行程式碼不會報錯、也依然可以賦值成功，但 React 已經不會再讀取它；要達到『沒傳 name 時顯示預設值』的效果，得改用 JavaScript 原生的預設參數語法 function Greeting({ name = \"Guest\" })" },
+        { "id": "b", "text": "<p>Hello, Guest</p>：defaultProps 在所有 React 版本都完全相容，行為沒有任何改變" },
+        { "id": "c", "text": "程式會直接拋出例外，因為 defaultProps 已經從 API 裡整個移除，賦值當下就會報錯" },
+        { "id": "d", "text": "<p>Hello, undefined</p>：React 19 改成顯示字面上的 undefined 文字，而不是空字串" }
+      ],
+      "answer": "a",
+      "explanation": "defaultProps 原本是 class component 時代遺留下來、後來也適用於函式元件的機制；React 19 的其中一項清理是移除函式元件對 defaultProps 的支援（class component 仍保留），但沒有把它做成報錯，只是單純不再讀取——這種『靜默失效』比直接報錯更危險，容易在升級後留下一段『看起來合法、實際上完全沒作用』的殘留程式碼。官方建議統一改用 JavaScript 原生的預設參數語法，這在函式元件裡本來就完全能表達同樣的意圖，也不受這次移除影響。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Greeting({ name }) {\n  return <p>Hello, {name}</p>;\n}\nGreeting.defaultProps = { name: \"Guest\" };\nconsole.log(renderToStaticMarkup(<Greeting />));", "expected": "<p>Hello, </p>" }
+        ]
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-8-modern.json b/packages/core/src/data/questions/ri-8-modern.json
new file mode 100644
index 0000000..0244363
--- /dev/null
+++ b/packages/core/src/data/questions/ri-8-modern.json
@@ -0,0 +1,231 @@
+{
+  "id": "ri-8",
+  "title": "Modern React：18／19 新特性",
+  "questions": [
+    {
+      "id": "ri-8-q1",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "useId：伺服器與用戶端算出同一個穩定 id，不是隨機碼",
+      "docs": "https://react.dev/reference/react/useId",
+      "story": "",
+      "prompt": "想幫 label 跟 input 建立可靠的關聯（htmlFor 屬性值要跟 id 屬性值一致）。過去常見寫法是自己手刻一個隨機字串或遞增計數器當 id，在 SSR + hydration 的情境下容易讓伺服器端跟用戶端算出的值對不上。改用 useId() 之後，下面這段程式碼裡，label 的 htmlFor 屬性值跟 input 的 id 屬性值會是同一個字串嗎？",
+      "code": "function Field() {\n  const id = useId();\n  return (\n    <div>\n      <label htmlFor={id}>姓名</label>\n      <input id={id} />\n    </div>\n  );\n}\n\nconst html = renderToStaticMarkup(<Field />);\nconst forMatch = html.match(/for=\"([^\"]+)\"/);\nconst idMatch = html.match(/id=\"([^\"]+)\"/);\nconsole.log(forMatch[1] === idMatch[1] ? \"same id\" : \"different id\");",
+      "options": [
+        { "id": "a", "text": "same id：同一次 useId() 呼叫在這個元件裡只執行一次、回傳一個穩定值，這裡把同一個結果同時用在 htmlFor 跟 id 上，兩者當然相同；useId 的關鍵設計目標正是『同一棵元件樹在伺服器端與用戶端算出的 id 保持一致』，避免用 Math.random() 或遞增計數器這種容易因為執行順序不同步而對不上、觸發 hydration mismatch 的做法" },
+        { "id": "b", "text": "different id：htmlFor 跟 id 各自對應到不同的內部呼叫，理論上會拿到不同的值" },
+        { "id": "c", "text": "程式會拋出錯誤，同一個 id 字串不能同時用在兩個不同的 HTML 屬性上" },
+        { "id": "d", "text": "只有在用戶端渲染才會相同，伺服器端渲染時兩者永遠是空字串" }
+      ],
+      "answer": "a",
+      "explanation": "useId() 在同一次呼叫裡只執行一次、回傳的值在整次渲染中固定不變，這裡的程式碼只呼叫了一次 useId 並把結果重複使用在兩個屬性上，所以 htmlFor 跟 id 必然相同。它跟手刻隨機碼最大的差異在於：useId 依「元件在樹狀結構中的位置」決定性地產生 id，不依賴 Math.random() 或執行順序，伺服器端渲染出的 HTML 跟用戶端 hydrate 時算出來的 id 保證一致，避免常見的 hydration mismatch 警告。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { useId } from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nfunction Field() {\n  const id = useId();\n  return (\n    <div>\n      <label htmlFor={id}>姓名</label>\n      <input id={id} />\n    </div>\n  );\n}\nconst html = renderToStaticMarkup(<Field />);\nconst forMatch = html.match(/for=\"([^\"]+)\"/);\nconst idMatch = html.match(/id=\"([^\"]+)\"/);\nconsole.log(forMatch[1] === idMatch[1] ? \"same id\" : \"different id\");", "expected": "same id" }
+        ]
+      }
+    },
+    {
+      "id": "ri-8-q2",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "use()：唯一可以放進條件式呼叫的 Hook",
+      "docs": "https://react.dev/reference/react/use",
+      "story": "",
+      "prompt": "React 的 Hook 有一條大家都背過的規則：不能放進 if、for 這類條件式或迴圈裡呼叫。下面這段程式碼裡，use(ThemeContext) 被包在 if 判斷式裡面才呼叫——這樣合法嗎？渲染結果是什麼？",
+      "code": "const ThemeContext = createContext(\"light\");\n\nfunction Label({ showTheme }) {\n  if (showTheme) {\n    const theme = use(ThemeContext); // 條件式呼叫\n    return <span>目前主題：{theme}</span>;\n  }\n  return <span>不顯示主題</span>;\n}\n\nfunction App() {\n  return (\n    <ThemeContext.Provider value=\"dark\">\n      <Label showTheme={true} />\n    </ThemeContext.Provider>\n  );\n}\n\nconsole.log(renderToStaticMarkup(<App />));",
+      "options": [
+        { "id": "a", "text": "合法，印出「目前主題：dark」：use() 是 React 19 引入的特殊 API，刻意設計成可以在條件式、迴圈裡呼叫——這是它跟 useContext／useState 等傳統 Hook 最大的差異，傳統 Hook『不能放進 if/for』的規則，use() 是明確的例外" },
+        { "id": "b", "text": "不合法，會直接拋出錯誤：違反了 Hook 規則裡『不能放進條件式』的限制，use() 也不例外" },
+        { "id": "c", "text": "合法，但因為是條件式呼叫，React 讀不到 Context 目前的值，結果會是 undefined" },
+        { "id": "d", "text": "合法，但 use() 只能讀取 Promise，不能讀取 Context，這段程式碼型別就用錯了" }
+      ],
+      "answer": "a",
+      "explanation": "傳統 Hook（useState、useContext、useEffect...）依賴「每次渲染呼叫順序完全相同」來對應內部狀態，這正是為什麼它們不能放進條件式。use() 不受這個限制，官方文件明確說明它可以在條件式、迴圈、甚至 early return 之後呼叫——這讓它除了讀取 Context，也很適合搭配「只有某些情境才需要讀取某個資源」的邏輯，不用被迫把整個元件拆成兩個。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { createContext, use } from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nconst ThemeContext = createContext(\"light\");\nfunction Label({ showTheme }) {\n  if (showTheme) {\n    const theme = use(ThemeContext);\n    return <span>目前主題：{theme}</span>;\n  }\n  return <span>不顯示主題</span>;\n}\nfunction App() {\n  return (\n    <ThemeContext.Provider value=\"dark\">\n      <Label showTheme={true} />\n    </ThemeContext.Provider>\n  );\n}\nconsole.log(renderToStaticMarkup(<App />));", "expected": "<span>目前主題：dark</span>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-8-q3",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "useTransition 的 isPending 初始值是 false",
+      "docs": "https://react.dev/reference/react/useTransition",
+      "story": "",
+      "prompt": "元件掛載後、還沒有任何使用者操作觸發 startTransition 之前，isPending 是什麼？",
+      "code": "function Search() {\n  const [isPending] = useTransition();\n  return <p>{isPending ? \"篩選中...\" : \"就緒\"}</p>;\n}\n\nconsole.log(renderToStaticMarkup(<Search />));",
+      "options": [
+        { "id": "a", "text": "false，顯示「就緒」：isPending 反映的是『目前是否有一個被標記為 transition 的更新正在進行中』，元件剛掛載、還沒有任何 transition 被觸發過，自然是 false；只有呼叫 startTransition(() => { ... }) 之後、在這個更新真正完成前，isPending 才會變成 true" },
+        { "id": "b", "text": "true，顯示「篩選中...」：useTransition 預設就是啟動中的狀態" },
+        { "id": "c", "text": "undefined，因為 isPending 只有搭配 Suspense 才會有值" },
+        { "id": "d", "text": "會拋出錯誤，useTransition 必須先呼叫 startTransition 才能安全渲染" }
+      ],
+      "answer": "a",
+      "explanation": "useTransition() 回傳一組 [isPending, startTransition]，isPending 單純是一個布林旗標，反映『有沒有一個被標記為低優先權（transition）的更新正在處理中』。掛載當下什麼更新都還沒發生，isPending 自然是預設的 false；它的用途通常是在使用者觸發了一個會讓畫面短暫『卡頓』的重度篩選/切換時，顯示一個載入提示，而不影響其他更緊急的互動（如輸入框本身立即回應按鍵）。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { useTransition } from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nfunction Search() {\n  const [isPending] = useTransition();\n  return <p>{isPending ? \"篩選中...\" : \"就緒\"}</p>;\n}\nconsole.log(renderToStaticMarkup(<Search />));", "expected": "<p>就緒</p>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-8-q4",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "useOptimistic 在還沒觸發樂觀更新前，顯示的就是真實值",
+      "docs": "https://react.dev/reference/react/useOptimistic",
+      "story": "",
+      "prompt": "這個讚數元件用 useOptimistic 包住 likes。畫面剛掛載、使用者都還沒按下任何「按讚」動作時，第一次渲染顯示的是什麼？",
+      "code": "function Likes({ likes }) {\n  const [optimisticLikes] = useOptimistic(likes);\n  return <p>{optimisticLikes} 個讚</p>;\n}\n\nconsole.log(renderToStaticMarkup(<Likes likes={10} />));",
+      "options": [
+        { "id": "a", "text": "10 個讚：useOptimistic(likes) 在沒有任何待處理的樂觀更新時，回傳的就是你傳入的真實狀態本身；它只有在後續某個非同步 action 執行『期間』，才會暫時顯示你另外指定的樂觀猜測值，等 action 完成後再對齊回真正的伺服器狀態——沒觸發任何更新時，行為就等同直接讀 likes" },
+        { "id": "b", "text": "0 個讚：useOptimistic 的初始值永遠固定是 0，要等第一次更新後才會顯示正確數字" },
+        { "id": "c", "text": "undefined 個讚：必須先呼叫對應的更新函式才能顯示任何內容" },
+        { "id": "d", "text": "10 個讚，但文字後面會自動附加一段「（更新中...）」的提示" }
+      ],
+      "answer": "a",
+      "explanation": "useOptimistic 的設計目的是「在等待伺服器確認的空檔，先讓使用者看到看起來已經生效的結果」，但這個機制只在你主動觸發一次樂觀更新時才啟動。沒有觸發任何更新的初始渲染，它單純把你傳入的真實值原封不動回傳，跟一般讀一個 prop 沒有兩樣——這也是為什麼它的第一個參數就叫「實際狀態」，樂觀值只是疊加在這個真實狀態之上的暫時性顯示。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { useOptimistic } from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nfunction Likes({ likes }) {\n  const [optimisticLikes] = useOptimistic(likes);\n  return <p>{optimisticLikes} 個讚</p>;\n}\nconsole.log(renderToStaticMarkup(<Likes likes={10} />));", "expected": "<p>10 個讚</p>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-8-q5",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "useActionState：初次渲染顯示初始狀態，action 還沒被呼叫過",
+      "docs": "https://react.dev/reference/react/useActionState",
+      "story": "",
+      "prompt": "表單元件用 useActionState 綁定一個非同步的 submitAction，並給了初始狀態 { message: '尚未送出' }。頁面剛渲染、使用者還沒按下送出按鈕之前，畫面顯示什麼？",
+      "code": "async function submitAction(prevState, formData) {\n  return { message: \"送出成功\" };\n}\n\nfunction Form() {\n  const [state, formAction] = useActionState(submitAction, { message: \"尚未送出\" });\n  return <p>{state.message}</p>;\n}\n\nconsole.log(renderToStaticMarkup(<Form />));",
+      "options": [
+        { "id": "a", "text": "尚未送出：useActionState(action, initialState) 的第一個回傳值，在 action 真正被觸發（也就是表單被送出）之前，就是你傳入的 initialState；submitAction 只有在使用者實際觸發表單提交時才會被呼叫，呼叫完成後 state 才會更新成 action 的回傳值" },
+        { "id": "b", "text": "送出成功：只要元件掛載，useActionState 就會立刻自動呼叫一次 action" },
+        { "id": "c", "text": "undefined：state 要等第一次呼叫 formAction 之後才會有任何值" },
+        { "id": "d", "text": "會拋出錯誤，submitAction 必須是同步函式，不能宣告成 async" }
+      ],
+      "answer": "a",
+      "explanation": "useActionState（前身是 useFormState）把「表單送出後的非同步處理結果」跟 state 綁在一起管理，但這件事本身是被動觸發的：只有真正呼叫回傳的 formAction（通常綁在 <form action={formAction}>）才會執行 submitAction；掛載當下沒有任何提交行為發生，state 自然停留在你傳入的初始值，不會提前執行 action 去『預先看一眼結果』。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { useActionState } from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nasync function submitAction(prevState, formData) {\n  return { message: \"送出成功\" };\n}\nfunction Form() {\n  const [state] = useActionState(submitAction, { message: \"尚未送出\" });\n  return <p>{state.message}</p>;\n}\nconsole.log(renderToStaticMarkup(<Form />));", "expected": "<p>尚未送出</p>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-8-q6",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "React Compiler 自動記憶化，不代表要刪掉現有的 useMemo",
+      "docs": "",
+      "story": "",
+      "prompt": "導入 React Compiler（原代號 React Forget）之後，下面這個手動加了 useMemo 的元件，跟原本比起來效益上有什麼差異？",
+      "code": "function ProductList({ products, filterText }) {\n  const filtered = useMemo(\n    () => products.filter((p) => p.name.includes(filterText)),\n    [products, filterText]\n  );\n  return <ul>{filtered.map((p) => <li key={p.id}>{p.name}</li>)}</ul>;\n}",
+      "options": [
+        { "id": "a", "text": "React Compiler 會在建置階段靜態分析元件程式碼，自動幫『沒有手動加 useMemo/useCallback/React.memo』的一般計算與函式做記憶化，讓開發者理論上不再需要手動判斷『這裡要不要包 useMemo』；已經手動寫好的 useMemo 在有 Compiler 的情況下通常不會造成傷害（頂多是多餘的樣板程式碼），Compiler 的目標是讓『沒有手動優化過的程式碼』也能拿到接近手動優化的效能，不是要求你把現有的 useMemo 全部刪掉" },
+        { "id": "b", "text": "手動寫的 useMemo 會直接讓 React Compiler 編譯失敗，兩者無法共存" },
+        { "id": "c", "text": "React Compiler 只能自動記憶化 useState，跟 useMemo 完全無關" },
+        { "id": "d", "text": "React Compiler 是純粹的執行期機制，跟建置階段的靜態分析完全無關" }
+      ],
+      "answer": "a",
+      "explanation": "React Compiler 的核心價值主張是：把「該不該手動包 useMemo/useCallback/memo」這種需要工程師自己判斷、容易判斷錯誤（漏包或包錯依賴陣列）的工作，轉移給建置階段的靜態分析自動處理。它不要求也不會破壞既有手動優化過的程式碼，實務上多半建議先在既有專案上啟用觀察效果，而不是急著大規模刪除現有的 useMemo/useCallback。",
+      "verify": {
+        "checks": [],
+        "manual": "React Compiler 屬建置期靜態分析工具，未安裝於本專案，效果需要實際的 babel 編譯管線才能觀察，無法用 node 直接驗證。"
+      }
+    },
+    {
+      "id": "ri-8-q7",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "React 18 重點特性總覽：自動批次處理、Transition、串流 SSR",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊正把專案從 React 17 升級到 18，想知道升級後能用哪些新工具解決現有痛點。下列哪一組「痛點 → 對應 React 18 特性」的配對正確？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "①在同一個 setTimeout callback 裡連續呼叫兩次 setState，React 17 會各自觸發一次重繪、React 18 的自動批次處理（automatic batching）讓這種情境也只重繪一次；②篩選一份大型清單導致輸入框卡頓 → 用 useTransition 把『重新篩選清單』標記成低優先權更新，讓輸入框本身維持流暢；③需要在伺服器渲染階段就先送出畫面骨架、資料還沒到位的部分先顯示 fallback → 改用支援串流的新版 SSR API" },
+        { "id": "b", "text": "①②③全部都是 React 17 就已經內建的功能，React 18 沒有引入任何新東西" },
+        { "id": "c", "text": "React 18 的重點只有『把 ReactDOM.render 換成 createRoot』這一個改動，其餘都只是套件版本號提升" },
+        { "id": "d", "text": "React 18 移除了 Hooks，改回全面使用 class component" }
+      ],
+      "answer": "a",
+      "explanation": "React 18 這幾項重點特性不是各自獨立的裝飾功能，而是分別解決三種真實痛點：自動批次處理讓『多次 setState 觸發多次重繪』這個效能陷阱在更多情境下（不只事件處理器內）自動消失；Transition 讓開發者可以明確標記『這個更新不急著顯示，可以被更緊急的互動打斷』；串流 SSR 則讓伺服器渲染不用『整頁等最慢的那塊資料』才能開始回應。三者共同的主軸是讓大型應用在面對『部分內容比較慢』時，使用者體驗更順暢。",
+      "verify": {
+        "checks": [],
+        "manual": "屬版本升級的特性總覽推理題，涉及跨多個 API 的綜合理解，無單一可執行程式碼片段。"
+      }
+    },
+    {
+      "id": "ri-8-q8",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "React 19 重點特性總覽：ref-as-prop、Actions、use()",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊接著把專案從 React 18 升級到 19。下列哪一組「舊寫法 → React 19 對應的新選項」配對正確？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "①函式元件想接收父層傳來的 ref，舊版一定要包一層 forwardRef → React 19 可以直接把 ref 當一般 prop 解構接收；②表單送出後要手動管理 loading／success／error 三種狀態 → 可以改用 useActionState 搭配 <form action={...}>；③讀取一個非同步資源（如 Promise、Context）想在條件式裡呼叫 → 可以用新引入的 use() API" },
+        { "id": "b", "text": "React 19 主要是內部效能調校，沒有新增任何 Hook 或 API" },
+        { "id": "c", "text": "React 19 把所有 class component 的支援整個移除，只能寫函式元件" },
+        { "id": "d", "text": "React 19 要求所有專案都必須搭配 TypeScript 才能使用" }
+      ],
+      "answer": "a",
+      "explanation": "這三項是 React 19 最常被提及的開發體驗改進：ref-as-prop 讓函式元件不必為了接一個 ref 就得包一層 forwardRef；Actions（搭配 useActionState／useFormStatus）把『表單提交 → 處理中 → 結果』這個過程原生化，不用自己手刻三個 state；use() 則是第一個明確允許在條件式、迴圈裡呼叫的 Hook，讓讀取 Promise／Context 的彈性大幅提升。三者都沒有移除 class component 的支援，也不要求 TypeScript。",
+      "verify": {
+        "checks": [],
+        "manual": "屬版本升級的特性總覽推理題，涉及跨多個 API 的綜合理解，無單一可執行程式碼片段。"
+      }
+    },
+    {
+      "id": "ri-8-q9",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "Server Actions：表單提交直接對應一段伺服器端函式",
+      "docs": "",
+      "story": "",
+      "prompt": "傳統寫法要送出表單，得自己寫一個 API route、在前端用 fetch 呼叫、處理 loading 跟 error 狀態。React 19 的 Server Actions（搭配支援它的框架，如 Next.js）想解決的是什麼問題？",
+      "code": "// Server Action：函式本體標記 \"use server\"，直接被前端當成表單的 action 呼叫\nasync function createTodo(formData) {\n  \"use server\";\n  const text = formData.get(\"text\");\n  await db.todos.create({ text });\n}\n\nfunction NewTodoForm() {\n  return (\n    <form action={createTodo}>\n      <input name=\"text\" />\n      <button type=\"submit\">新增</button>\n    </form>\n  );\n}",
+      "options": [
+        { "id": "a", "text": "讓『表單提交』直接對應到一段標記 \"use server\" 的伺服器端函式，不用自己手刻一個 API route、也不用在前端手動 fetch／處理 loading 狀態；框架會在背後把表單提交自動轉成一次對伺服器的呼叫，開發者只要專注在『收到 formData 之後要做什麼』這段邏輯，大幅減少『前後端各寫一份、手動兜接』的樣板程式碼" },
+        { "id": "b", "text": "Server Actions 只是把現有的 API route 改個檔名，行為完全沒有任何簡化" },
+        { "id": "c", "text": "Server Actions 讓所有邏輯都只能在瀏覽器端執行，伺服器端程式碼會被忽略" },
+        { "id": "d", "text": "Server Actions 是取代 Redux 的新狀態管理方案，跟表單提交無關" }
+      ],
+      "answer": "a",
+      "explanation": "Server Actions 把「前端表單 → API route → 後端處理」這條原本要手動兜接前後兩端的路徑，收斂成一個標記 \"use server\" 的函式，直接掛在 <form action={...}> 上。這需要框架層級（如 Next.js 的 App Router）的支援才能運作，本質上是把『網路請求』這個實作細節從應用程式邏輯裡抽象掉，而不是取代狀態管理或改變程式碼的執行位置本身。",
+      "verify": {
+        "checks": [],
+        "manual": "Server Actions 需要框架（如 Next.js）的建置管線與伺服器執行環境支援，無法用單純的 node 執行驗證。"
+      }
+    },
+    {
+      "id": "ri-8-q10",
+      "type": "concept",
+      "difficulty": 3,
+      "topic": "串流 SSR：先送出骨架，慢的子樹晚一點再補",
+      "docs": "",
+      "story": "",
+      "prompt": "傳統的 renderToString／renderToStaticMarkup 是「整棵樹渲染完成才回傳」的同步 API；React 18 起提供的串流式 SSR（如 renderToPipeableStream）想解決什麼問題？",
+      "code": "// 傳統：整頁資料都準備好，才能開始送出任何 HTML\nconst html = renderToString(<App />); // 要等最慢的那個子樹渲染完\n\n// 串流：可以先送出畫面骨架，慢的子樹之後再補上\nconst { pipe } = renderToPipeableStream(<App />, {\n  onShellReady() {\n    pipe(response);\n  },\n});",
+      "options": [
+        { "id": "a", "text": "串流 SSR 讓『準備好的部分先送、還沒準備好的部分（包在 Suspense 裡）晚一點再補』成為可能：使用者不用等到最慢的那個資料來源完成，就能先看到頁面骨架與已經就緒的內容，大幅改善大型頁面在『某個子樹特別慢』時的首次顯示體驗，這是傳統一次性同步渲染 API 做不到的" },
+        { "id": "b", "text": "串流 SSR 只是把 HTML 拆成好幾個檔案分開存放，跟渲染時機無關" },
+        { "id": "c", "text": "串流 SSR 會讓伺服器渲染完全消失，改成純粹的用戶端渲染" },
+        { "id": "d", "text": "串流 SSR 只能用在完全沒有任何非同步資料的靜態頁面上" }
+      ],
+      "answer": "a",
+      "explanation": "傳統同步 SSR API 的瓶頸在於「整棵樹裡最慢的那一個子樹，拖累了整份回應的送出時間」——即使頁面 90% 的內容早就準備好了，也得等最慢的那 10% 完成才能開始回傳任何 HTML。串流 SSR 把這個限制打破：先送出骨架與已就緒內容，Suspense 包住的慢速子樹用 fallback 佔位，等資料真正到位後，再透過同一個串流連線把真正內容『補』進頁面對應的位置。",
+      "verify": {
+        "checks": [],
+        "manual": "renderToPipeableStream 需要 Node.js 伺服器環境搭配串流回應機制才能實際觀察效果，超出本驗證腳本 node -e 的執行範圍，無法自動驗證。"
+      }
+    }
+  ]
+}
diff --git a/packages/core/src/data/questions/ri-9-core-basics.json b/packages/core/src/data/questions/ri-9-core-basics.json
new file mode 100644
index 0000000..78d6713
--- /dev/null
+++ b/packages/core/src/data/questions/ri-9-core-basics.json
@@ -0,0 +1,197 @@
+{
+  "id": "ri-9",
+  "title": "Core React：基礎觀念與元件",
+  "questions": [
+    {
+      "id": "ri-9-q1",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "React 解決的問題：把 UI 描述成資料的函式",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊原本用 jQuery 直接操作 DOM（找到節點、改屬性、插入子節點），改用 React 之後，最根本的心智模型轉變是什麼？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "從『命令式地一步步操作 DOM』轉成『宣告式地描述在某個 state 下畫面應該長什麼樣子』：開發者不再寫『找到這個節點、把它的文字改掉』，而是寫『state 是這樣時，畫面應該渲染成這樣』，DOM 該怎麼變化交給 React 內部去計算與執行" },
+        { "id": "b", "text": "React 只是 jQuery 的別名，兩者程式碼寫法幾乎一模一樣" },
+        { "id": "c", "text": "React 要求完全不能有任何 DOM 操作，包括 React 自己內部也不能操作 DOM" },
+        { "id": "d", "text": "React 只是把 jQuery 的 $ 符號換成 React.createElement，其餘概念完全相同" }
+      ],
+      "answer": "a",
+      "explanation": "React 的核心賣點是宣告式 UI：你描述「這個 state 對應這個畫面」，不用自己寫「怎麼從舊畫面一步步改成新畫面」的指令。React 內部（透過虛擬 DOM 與 reconciliation）負責把這份宣告轉換成實際、有效率的 DOM 操作，這是它與 jQuery 這類命令式操作 DOM 的函式庫最根本的差異。",
+      "verify": { "checks": [], "manual": "屬程式設計典範轉移的概念題，無可執行程式碼。" }
+    },
+    {
+      "id": "ri-9-q2",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "JSX 是 React.createElement 的語法糖",
+      "docs": "https://react.dev/learn/writing-markup-with-jsx",
+      "story": "",
+      "prompt": "JSX 不是瀏覽器看得懂的語法，必須先被轉譯。下面這段 JSX，轉譯後大致對應呼叫哪個函式？渲染結果會是什麼？",
+      "code": "function Greeting() {\n  return <h1 className=\"title\">Hello</h1>;\n}\n\nconsole.log(renderToStaticMarkup(<Greeting />));",
+      "options": [
+        { "id": "a", "text": "<h1 className=\"title\">Hello</h1> 會被轉譯成 React.createElement(\"h1\", { className: \"title\" }, \"Hello\")，最終渲染出 <h1 class=\"title\">Hello</h1>——JSX 只是 createElement 呼叫的語法糖，方便開發者用近似 HTML 的寫法描述元素樹，實際執行的仍然是一般的 JavaScript 函式呼叫" },
+        { "id": "b", "text": "JSX 會被瀏覽器直接當成 HTML 字串解析，不需要任何轉譯步驟" },
+        { "id": "c", "text": "className 屬性會被直接渲染成 HTML 的 className=\"title\"，而不是 class=\"title\"" },
+        { "id": "d", "text": "這段程式碼會拋出例外，JSX 不能在函式元件裡直接 return" }
+      ],
+      "answer": "a",
+      "explanation": "JSX 需要 Babel 或 esbuild 這類工具在建置階段轉譯成 React.createElement(type, props, ...children) 的呼叫，這也是為什麼 JSX 檔案裡即使沒有直接用到 React 這個變數名稱（新版 JSX transform 下），底層仍然依賴 react 套件；渲染到瀏覽器 DOM 上時，className 這個 React/JSX 專屬的屬性名稱，會被轉換回瀏覽器認得的 class 屬性。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Greeting() {\n  return <h1 className=\"title\">Hello</h1>;\n}\nconsole.log(renderToStaticMarkup(<Greeting />));", "expected": "<h1 class=\"title\">Hello</h1>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-9-q3",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "Element 是描述畫面的普通物件，Component 是產生 Element 的函式",
+      "docs": "",
+      "story": "",
+      "prompt": "<Greeting /> 這個 JSX 表達式的執行結果（一個 React Element），跟 Greeting 這個函式元件本身，是同一種東西嗎？",
+      "code": "function Greeting() {\n  return <h1>Hello</h1>;\n}\n\nconst element = <Greeting />;\nconsole.log(typeof Greeting, typeof element);",
+      "options": [
+        { "id": "a", "text": "不是同一種東西：Greeting 是一個函式（Component），描述『給定 props，該怎麼算出畫面』的邏輯；<Greeting /> 執行後產生的 element 是一個普通的、輕量的物件，只是描述『畫面上這裡該放一個 Greeting，props 是這些』，本身不含任何邏輯，也還沒有真的被渲染成 DOM——element 是資料，component 是產生資料的函式" },
+        { "id": "b", "text": "是同一種東西，element 跟 component 只是同一個概念的兩種稱呼" },
+        { "id": "c", "text": "element 是一個 DOM 節點，component 是一段 CSS 樣式" },
+        { "id": "d", "text": "typeof Greeting 會是 'object'，typeof element 會是 'function'" }
+      ],
+      "answer": "a",
+      "explanation": "Component 是函式（或 class），接收 props、回傳 element；element 是一個純資料物件（{ type, props, key... }），描述某個時間點畫面該長什麼樣。React 拿到 element 之後才會去呼叫對應的 component 函式、遞迴地算出更深層的 element，最終才映射成真正的 DOM——這整個過程就是 reconciliation。",
+      "verify": {
+        "checks": [
+          { "jsx": "function Greeting() {\n  return <h1>Hello</h1>;\n}\nconst element = <Greeting />;\nconsole.log(typeof Greeting, typeof element);", "expected": "function object" }
+        ]
+      }
+    },
+    {
+      "id": "ri-9-q4",
+      "type": "concept",
+      "difficulty": 1,
+      "topic": "什麼時候該用 class component（現在幾乎只剩一種情境）",
+      "docs": "",
+      "story": "",
+      "prompt": "團隊的程式碼風格指南要求「新元件一律用函式元件」，但保留了一個例外：只有某一種情境還是得寫 class component。是什麼情境？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "需要實作 Error Boundary（攔截子元件渲染時拋出的錯誤並顯示備援畫面）時：目前只有 class component 才能定義 static getDerivedStateFromError() 與 componentDidCatch() 這兩個生命週期方法，函式元件與 Hooks 沒有對應的錯誤攔截機制，這是少數函式元件無法完全取代 class component 的場景" },
+        { "id": "b", "text": "需要使用 useState 管理狀態時，必須用 class component" },
+        { "id": "c", "text": "需要使用 props 時，必須用 class component" },
+        { "id": "d", "text": "class component 已經被完全移除，任何情境都不能再使用" }
+      ],
+      "answer": "a",
+      "explanation": "Hooks 幾乎覆蓋了 class component 生命週期能做的所有事（狀態、副作用、context...），唯獨 Error Boundary 依賴的 getDerivedStateFromError／componentDidCatch 至今沒有對應的 Hook 版本，這也是為什麼即使是全面擁抱函式元件的專案，程式碼庫裡通常還會留著一個（或少數幾個）用來實作 Error Boundary 的 class component。",
+      "verify": { "checks": [], "manual": "屬 API 現況的事實性題目，官方文件明確說明此限制，無需執行驗證。" }
+    },
+    {
+      "id": "ri-9-q5",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "Pure Component／React.memo：props 沒變就跳過重繪",
+      "docs": "https://react.dev/reference/react/memo",
+      "story": "",
+      "prompt": "父層重繪了兩次，但傳給 Child 的 props（name=\"A\"）完全沒變。Child 外面包了 React.memo，它裡面的 console.log 會被印出幾次？",
+      "code": "let renderCount = 0;\nfunction ChildImpl({ name }) {\n  renderCount++;\n  return <p>{name}</p>;\n}\nconst Child = React.memo(ChildImpl);\n\nfunction App() {\n  const [, forceRerender] = useState(0);\n  return (\n    <>\n      <button onClick={() => forceRerender((c) => c + 1)}>重繪父層</button>\n      <Child name=\"A\" />\n    </>\n  );\n}\n\n// 模擬：父層初次渲染 + 兩次 forceRerender\nconsole.log(renderToStaticMarkup(<App />));\nconsole.log(renderCount);",
+      "options": [
+        { "id": "a", "text": "第一次渲染會呼叫一次 ChildImpl（memo 沒辦法跳過『第一次』渲染，只能跳過『props 沒變的後續重繪』）；但這裡是伺服器端一次性的 renderToStaticMarkup，只會觸發一次渲染，之後模擬的父層重繪並不會在這段程式碼裡實際發生，所以 renderCount 印出 1" },
+        { "id": "b", "text": "renderCount 永遠是 0，React.memo 包起來的元件完全不會被呼叫" },
+        { "id": "c", "text": "renderCount 會等於父層重繪的總次數，React.memo 對伺服器端渲染沒有任何效果" },
+        { "id": "d", "text": "這段程式碼會拋出例外，React.memo 不能用在函式元件上" }
+      ],
+      "answer": "a",
+      "explanation": "React.memo 的效果是「props 沒變就跳過這次重繪」，但它介入的時間點是『重繪』本身，第一次渲染一定會執行。這裡的 renderToStaticMarkup 只做了一次性的伺服器端渲染，沒有真正觸發父層重繪的迴圈，所以只會看到一次 ChildImpl 執行；要觀察 memo 真正跳過重複渲染的效果，需要瀏覽器端多次觸發重繪才看得出來。",
+      "verify": {
+        "checks": [
+          { "jsx": "import React, { useState } from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nlet renderCount = 0;\nfunction ChildImpl({ name }) {\n  renderCount++;\n  return <p>{name}</p>;\n}\nconst Child = React.memo(ChildImpl);\nfunction App() {\n  return (\n    <>\n      <Child name=\"A\" />\n    </>\n  );\n}\nconsole.log(renderToStaticMarkup(<App />));\nconsole.log(renderCount);", "expected": "<p>A</p>\n1" }
+        ]
+      }
+    },
+    {
+      "id": "ri-9-q6",
+      "type": "predict-output",
+      "difficulty": 2,
+      "topic": "state 是元件自己的記憶，props 是外部傳入的唯讀資料",
+      "docs": "https://react.dev/learn/state-a-components-memory",
+      "story": "",
+      "prompt": "Counter 元件用 useState 記錄自己的點擊次數。父層完全不知道也不管這個次數。下面這樣描述 state 跟 props 的差異，正確嗎？",
+      "code": "function Counter() {\n  const [count, setCount] = useState(0); // state：元件自己的、私有的記憶\n  return <button onClick={() => setCount(count + 1)}>{count}</button>;\n}\n\nfunction Toolbar({ title }) { // props：外部傳入，Toolbar 自己不能改\n  return <h2>{title}</h2>;\n}",
+      "options": [
+        { "id": "a", "text": "正確：state 是元件『自己』宣告、自己管理、外部無法直接讀取或修改的內部資料，只有這個元件自己能透過 setCount 改變它；props 則是由外部（父層）傳入的資料，對收到的元件而言是唯讀的，Toolbar 內部不能直接修改 title 這個 prop 的值" },
+        { "id": "b", "text": "不正確，state 跟 props 其實是同一種東西，只是命名不同" },
+        { "id": "c", "text": "不正確，props 才是元件自己的私有資料，state 才是外部傳入的" },
+        { "id": "d", "text": "不正確，父層永遠可以直接修改子層的 state" }
+      ],
+      "answer": "a",
+      "explanation": "這是 React 資料流最基礎的一組區分：state 是「這個元件自己的記憶」，只有它自己能透過對應的 setter 改變；props 是「別人傳給你的資料」，收到的一方只能讀取、不能直接修改（想改，得請求父層透過重新渲染傳入新的 props，或呼叫父層透過 props 傳來的回呼函式）。搞混這兩者最常見的症狀就是想「直接改一個 prop」結果毫無效果。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { useState } from 'react'\nimport { renderToStaticMarkup } from 'react-dom/server'\nfunction Counter() {\n  const [count] = useState(0);\n  return <button>{count}</button>;\n}\nfunction Toolbar({ title }) {\n  return <h2>{title}</h2>;\n}\nfunction App() {\n  return (\n    <div>\n      <Counter />\n      <Toolbar title=\"我的工具列\" />\n    </div>\n  );\n}\nconsole.log(renderToStaticMarkup(<App />));", "expected": "<div><button>0</button><h2>我的工具列</h2></div>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-9-q7",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "什麼時候該把資料設計成 state，而不是每次重算",
+      "docs": "",
+      "story": "",
+      "prompt": "一個元件需要顯示「篩選後的清單項目數量」，這個數字可以直接從 props.items 篩選運算得到。下列哪種設計比較恰當？",
+      "code": "// 版本一：另外用 state 存這個數字，並在每次 items 改變時手動同步\nconst [count, setCount] = useState(0);\nuseEffect(() => {\n  setCount(items.filter((i) => i.active).length);\n}, [items]);\n\n// 版本二：渲染時直接算，不額外存成 state\nconst count = items.filter((i) => i.active).length;",
+      "options": [
+        { "id": "a", "text": "版本二比較恰當：這個數字完全可以從現有的 props（items）直接算出來，屬於『衍生資料』，不需要另外用一份 state 存放並手動同步；版本一多了一次不必要的 state、一個容易漏寫依賴或造成『state 跟 props 不同步』風險的 useEffect，而且會多一次重繪（先渲染舊值，effect 跑完才更新成新值）" },
+        { "id": "b", "text": "版本一比較恰當，任何顯示在畫面上的數值都應該是獨立的 state" },
+        { "id": "c", "text": "兩者完全等價，選哪個都沒有任何差異" },
+        { "id": "d", "text": "版本二有語法錯誤，不能在渲染過程中直接呼叫 filter" }
+      ],
+      "answer": "a",
+      "explanation": "React 官方文件明確建議：如果一個值可以從既有的 props 或 state 純粹計算出來，就不要把它另外存成一份 state。額外存一份不僅冗餘，還會製造出「這份 state 跟真正的來源資料不同步」的風險（例如忘記在某個更新路徑上呼叫 setCount）；渲染時直接算，永遠保證跟來源資料一致，也少一次不必要的重繪。",
+      "verify": { "checks": [], "manual": "屬狀態設計原則的推理題，重點在避免不必要的衍生 state，無需可執行程式碼佐證。" }
+    },
+    {
+      "id": "ri-9-q8",
+      "type": "predict-output",
+      "difficulty": 1,
+      "topic": "props 有預設值時，沒傳該 prop 會用預設參數補上",
+      "docs": "https://react.dev/learn/passing-props-to-a-component",
+      "story": "",
+      "prompt": "Button 元件用預設參數宣告 variant = \"primary\"。呼叫端沒有傳 variant 這個 prop，畫面會顯示什麼？",
+      "code": "function Button({ label, variant = \"primary\" }) {\n  return <button className={variant}>{label}</button>;\n}\n\nconsole.log(renderToStaticMarkup(<Button label=\"送出\" />));",
+      "options": [
+        { "id": "a", "text": "<button class=\"primary\">送出</button>：這是 JavaScript 原生的解構預設參數語法，呼叫端沒有傳 variant 時，函式內部會用宣告時給的預設值 \"primary\" 補上；這跟舊版 Component.defaultProps 是兩種不同的機制，但效果類似，函式元件目前建議直接用這種原生語法" },
+        { "id": "b", "text": "<button class=\"undefined\">送出</button>，沒傳的 prop 會被轉成字面上的 undefined 字串" },
+        { "id": "c", "text": "程式會拋出例外，variant 是必填 prop，沒傳就會報錯" },
+        { "id": "d", "text": "<button>送出</button>，className 屬性會被完全省略" }
+      ],
+      "answer": "a",
+      "explanation": "函式元件的 props 本質上就是一個一般的 JavaScript 物件參數，解構賦值搭配預設值語法（{ variant = \"primary\" }）在這裡完全比照一般函式參數的規則運作：呼叫端沒傳這個屬性、或傳的是 undefined，就會套用預設值；只有明確傳入 null 或其他值時才不會使用預設值。",
+      "verify": {
+        "checks": [
+          { "jsx": "import { renderToStaticMarkup } from 'react-dom/server'\nfunction Button({ label, variant = \"primary\" }) {\n  return <button className={variant}>{label}</button>;\n}\nconsole.log(renderToStaticMarkup(<Button label=\"送出\" />));", "expected": "<button class=\"primary\">送出</button>" }
+        ]
+      }
+    },
+    {
+      "id": "ri-9-q9",
+      "type": "concept",
+      "difficulty": 2,
+      "topic": "何時把 Component 拆小：職責是否單一、是否需要重複使用",
+      "docs": "",
+      "story": "",
+      "prompt": "一個 UserCard 元件裡同時塞了「頭像顯示」「使用者名稱與簡介」「追蹤按鈕與其點擊邏輯」三大段完全不相關的 JSX 與邏輯，檔案長達 300 行。下列哪個判斷，是決定要不要拆成更小元件的合理依據？",
+      "code": "",
+      "options": [
+        { "id": "a", "text": "看這三段各自是否有『獨立、可以脫離彼此單獨描述』的職責，以及是否有機會在別處被重複使用（例如頭像元件在留言列表、個人頁面都可能用到）；如果某一段邏輯複雜到難以一眼理解、或明顯可能被其他畫面重用，通常就是該拆成獨立元件的訊號，而不是單純依檔案行數或個人喜好決定" },
+        { "id": "b", "text": "只要檔案超過 100 行就必須拆分，這是唯一該遵守的硬性規則" },
+        { "id": "c", "text": "永遠不應該拆分元件，所有邏輯都該塞在同一個檔案裡以方便維護" },
+        { "id": "d", "text": "只有使用 TypeScript 的專案才需要考慮拆分元件" }
+      ],
+      "answer": "a",
+      "explanation": "拆分元件的判斷依據應該是「職責是否單一」與「是否有重複使用的價值」，而不是死板的行數規則。追蹤按鈕邏輯獨立、頭像元件可能被其他地方複用，這些都是拆分的合理理由；反過來說，兩段邏輯緊密耦合、拆開反而要傳一堆 props 才能溝通，強行拆分也不見得更好維護。",
+      "verify": { "checks": [], "manual": "屬元件設計與職責劃分的推理題，無可執行程式碼。" }
+    }
+  ]
+}
diff --git a/packages/core/src/quiz.ts b/packages/core/src/quiz.ts
index 749b165..b0119c7 100644
--- a/packages/core/src/quiz.ts
+++ b/packages/core/src/quiz.ts
@@ -1,9 +1,12 @@
 import type { Question } from './types'
 
-// 進關作答整個題池：洗牌後依難度由易到難排（同難度內順序隨機）
+// 錯題重練跨關卡抽題數
 export const REVIEW_SIZE = 6
 // 首頁「隨機綜合練習」跨章節抽題數
 export const MIXED_SIZE = 10
+// 單一關卡每次作答的固定題數：關卡題庫大小不一（5~12 題不等），
+// 固定抽樣讓每次刷題的時間可預期，不會因為關卡不同而忽長忽短
+export const LEVEL_SIZE = 6
 
 export const shuffle = <T>(arr: T[]): T[] => {
   const copy = [...arr]
@@ -17,3 +20,7 @@ export const shuffle = <T>(arr: T[]): T[] => {
 export const sampleQuestions = (pool: Question[]): Question[] =>
   // sort 是穩定排序，洗牌後再排難度，同難度題目每次順序不同
   shuffle(pool).sort((a, b) => a.difficulty - b.difficulty)
+
+// 從題池洗牌後抽出固定數量（題池小於 size 就整包抽完），再依難度排序
+export const sampleFixedQuestions = (pool: Question[], size: number): Question[] =>
+  shuffle(pool).slice(0, size).sort((a, b) => a.difficulty - b.difficulty)