- 實際案例：將「表情」作為 FTB 自訂按鈕，按鈕出現在原生工具列，體驗一致。
- 實作環境：FTB 3.x、ASP.NET WebForms
- 實測數據（驗收目標）：
  - UI 一致性：100% 同一列呈現
  - 任務效率：插入操作時間 < 3 秒

- Learning Points：FTB 自訂命令、工具列配置、事件命名規則
- 技能要求：WebForms 控制項屬性；進階：編輯器命令模型
- 延伸思考：如何把命令改為插件化載入？如何權限控制？

- Practice：新增「插入程式碼區塊」按鈕；支持語法高亮
- 評估：命令可用；UI 一致；代碼結構清晰

---

## Case #5: 以 JavaScript 在游標處插入 HTML（跨 iframe/IE/標準）

### Problem Statement
- 業務場景：無論使用自訂按鈕或對話框，關鍵能力是「在當前游標處插入圖片/表情或 HTML 片段」，需支援 FTB 的 iframe 與舊版 IE。
- 技術挑戰：跨瀏覽器選取範圍與 execCommand 相容性。
- 影響範圍：功能可用性、資料正確性。
- 複雜度評級：中

### Root Cause Analysis
- 直接原因：FTB 使用 contentEditable iframe；不同瀏覽器選區 API 差異大。
- 深層原因：缺少通用插入封裝；對舊版 IE 未提供回退。

### Solution Design
- 解決策略：封裝 insertAtCaret，優先使用 execCommand('insertHTML')，回退 Range API/IE pasteHTML，並處理焦點切換到 iframe。

- 實施步驟：
  1. 焦點控制與 iframe 文件獲取（0.5 天）
  2. 標準 API 優先 + 回退策略（0.5 天）
  3. 單元測試：常見片段（圖片、表情、連結）（1 天）

- 關鍵程式碼/設定：
```javascript
function insertIntoFTB(frameId, html) {
  var iframe = document.getElementById(frameId);
  var win = iframe.contentWindow, doc = win.document;
  iframe.contentWindow.focus();
  if (doc.execCommand && doc.execCommand('insertHTML', false, html)) return true;
  var sel = win.getSelection && win.getSelection();
  if (sel && sel.rangeCount) {
    var range = sel.getRangeAt(0);
    var el = doc.createElement('div'); el.innerHTML = html;
    var frag = doc.createDocumentFragment();
    while (el.firstChild) frag.appendChild(el.firstChild);
    range.deleteContents(); range.insertNode(frag);
    return true;
  } else if (doc.selection && doc.selection.createRange) {
    doc.selection.createRange().pasteHTML(html); return true;
  }
  return false;
}

• 實際案例：所有插入功能（圖片、表情、連結）共用該封裝，降低重複與相容性問題。
• 實作環境：IE 8+/現代瀏覽器、FTB 3.x
• 實測數據（驗收目標）：
  • 成功插入率 ≥ 99%（跨瀏覽器）
  • 插入耗時 < 50ms（平均）
• Learning Points：選區 API、iframe 焦點管理、回退策略
• 技能要求：JS DOM/Selection；進階：跨瀏覽器測試策略

• 延伸思考：如何支援撤銷/重做？如何處理貼上純文字？

• Practice：加入「包裹選區」功能，為選中文本加
• 評估：功能正確；跨瀏覽器通過；有單元測試

Case #6: 圖片上傳服務與插入對話框整合

Problem Statement

• 業務場景：作者需要直接上傳圖片並自動插入文章；需驗證權限、限制檔案大小、生成縮圖、回傳 URL 供插入。
• 技術挑戰：安全、效能與 UX 的端到端設計。
• 影響範圍：資安風險、磁碟壓力、上傳體驗。
• 複雜度評級：中

Root Cause Analysis

• 直接原因：缺少統一上傳 API 與回填機制。
• 深層原因：未納管檔案儲存路徑與存取控制；圖片處理無標準。

Solution Design

• 解決策略：建立 /upload.ashx 上傳端點，驗證登入與 MIME/大小，儲存至使用者目錄並生成縮圖；回傳 JSON（URL、寬高）。前端對話框完成後調用 insertIntoFTB 插入 。

• 實施步驟：
  1. 上傳端點與驗證（1 天）
  2. 影像處理與縮圖（0.5 天）
  3. 前端對話框與回填（0.5 天）
• 關鍵程式碼/設定：

  // /upload.ashx
  public class UploadHandler : IHttpHandler {
  public void ProcessRequest(HttpContext ctx) {
    if (!ctx.User.Identity.IsAuthenticated) { ctx.Response.StatusCode=401; return; }
    var file = ctx.Request.Files[0];
    if (file==null || file.ContentLength==0) { ctx.Response.StatusCode=400; return; }
    if (file.ContentLength > 2*1024*1024) { ctx.Response.StatusCode=413; return; }
    // 簡單 MIME 檢查
    if (!file.ContentType.StartsWith("image/")) { ctx.Response.StatusCode=415; return; }
    var folder = $"/uploads/{ctx.User.Identity.Name}/";
    var path = ctx.Server.MapPath(folder); Directory.CreateDirectory(path);
    var fname = Path.GetFileName(file.FileName);
    var full = Path.Combine(path, fname); file.SaveAs(full);
    // TODO: 生成縮圖 thumbFull
    var url = folder + fname;
    ctx.Response.ContentType="application/json";
    ctx.Response.Write("{\"url\":\""+url+"\"}");
  }
  public bool IsReusable => false;
  }
  

• 實際案例：依本文需求讓「貼圖」一鍵完成：上傳→回填插入。
• 實作環境：ASP.NET/IIS、System.Drawing
• 實測數據（驗收目標）：
  • 上傳成功率 ≥ 99%
  • 平均上傳時間（<1MB）< 1s
  • 不合規檔案阻擋率 100%
• Learning Points：上傳安全、目錄規劃、前後端協作
• 技能要求：HTTP 處理程式、圖片處理；進階：CDN/快取策略

• 延伸思考：如何去除 EXIF？如何防止同名覆寫？版本化 URL？

• Practice：加入參數自動插入寬高/alt；生成多尺寸
• 評估：安全檢查完善；回填正確；例外處理完備

Case #7: 表情符號選單元件與佈景同步

Problem Statement

• 業務場景：提供一個表情選單面板，顯示所有可用表情，點擊即插入；隨佈景主題切換不同表情集。
• 技術挑戰：資源管理與清單維護；插入體驗順暢。
• 影響範圍：使用者滿意度與主題一致性。
• 複雜度評級：低

Root Cause Analysis

• 直接原因：表情資源散落、缺少 manifest 與動態載入。
• 深層原因：主題與功能未整合；無統一配置。

Solution Design

• 解決策略：建立 emotes.json 作為清單，依主題載入；以懶載入圖片與容器委派事件，點擊插入對應 。

• 實施步驟：
  1. 建立 Manifest 與資料夾結構（0.5 天）
  2. 前端面板渲染與事件處理（0.5 天）
  3. 主題切換載入不同清單（0.5 天）
• 關鍵程式碼/設定：

  // /themes/default/emotes.json
  { "base": "/themes/default/emotes/",
  "items": ["smile.png","sad.png","wink.png"] }
  

  fetch('/themes/default/emotes.json').then(r=>r.json()).then(cfg=>{
  const box = document.getElementById('emoteBox');
  cfg.items.forEach(f=>{
    const img = new Image(); img.loading='lazy';
    img.src = cfg.base + f; img.alt = f.replace('.png','');
    img.onclick = ()=> insertIntoFTB('FreeTextBox1___Frame','<img src="'+img.src+'" alt="'+img.alt+'">');
    box.appendChild(img);
  });
  });
  

• 實際案例：本文的「貼表情」以清單化、主題化方式維護，避免硬編碼。
• 實作環境：靜態 JSON、前端 JS
• 實測數據（驗收目標）：
  • 面板首次渲染 < 200ms
  • 圖片懶載入命中率 ≥ 90%
• Learning Points：資源清單、懶載入、主題切換
• 技能要求：基礎 JS；進階：資源組織與可配置化

• 延伸思考：可否使用 Sprite 降請求？是否需搜尋/分類？

• Practice：加入搜尋框；鍵盤導航
• 評估：操作流暢；主題切換正確；碼規一致

Case #8: 工具列 UX 統一與版位衝突解法

Problem Statement

• 業務場景：自訂工具列被迫置於頁面上方，與 FTB 工具列分離，導致 UI 不一致；需要將外部工具列整合或「視覺上」無縫拼接。
• 技術挑戰：不破壞現有 DOM 的前提下，將外部工具列併入原列或靠齊。
• 影響範圍：可用性、審美與學習成本。
• 複雜度評級：低

Root Cause Analysis

• 直接原因：Wrapper 擋住內嵌；外部工具列只能浮動。
• 深層原因：未定義 UI 對齊規範與樣式變數；缺乏彈性容器。

Solution Design

• 解決策略：尋找 FTB 工具列容器，將外部工具列節點 append 進入；若不可行，使用 CSS Flex 對齊與同樣式變數實現視覺拼接。

• 實施步驟：
  1. DOM 移位注入（0.5 天）
  2. 樣式抽象與變數統一（0.5 天）
  3. 響應式調整（0.5 天）
• 關鍵程式碼/設定：

  .ftb-toolbar, .ext-toolbar { display:flex; gap:6px; align-items:center; }
  .ext-toolbar button { background:var(--tb-bg); border:1px solid var(--tb-bd); }
  

  var tb = document.querySelector('.ftb-toolbar');
  var ext = document.getElementById('extToolbar');
  if (tb && ext) tb.appendChild(ext); // 併入原列
  

• 實際案例：把現有外掛工具列 DOM 直接移入 FTB 工具列容器，視覺與交互一致。
• 實作環境：CSS/JS
• 實測數據（驗收目標）：
  • 視覺差異 0（設計驗收）
  • 多瀏覽器呈現一致性 ≥ 99%
• Learning Points：DOM 併入、樣式系統、響應式工具列
• 技能要求：CSS/JS；進階：設計系統 tokens

• 延伸思考：溢出處理？小螢幕折疊策略？

• Practice：加入「更多」溢出菜單
• 評估：一致性、可用性、易維護

Case #9: HTML 安全與消毒：防 XSS/危險屬性

Problem Statement

• 業務場景：允許貼入 HTML（圖片/表情/連結），需防止惡意腳本、事件屬性或危險 URL 協定。
• 技術挑戰：白名單策略、效能與相容的平衡。
• 影響範圍：資安、平台信譽與法規遵循。
• 複雜度評級：中

Root Cause Analysis

• 直接原因：FTB 允許輸入 HTML；使用者可貼入惡意內容。
• 深層原因：未啟用消毒；缺少白名單與測試。

Solution Design

• 解決策略：後端保存前以 HTML Sanitizer 白名單清洗；允許基本格式與 img/src/http(s)/data:image 白名單；剝除 on* 事件、javascript:、style 中的表達式。

• 實施步驟：
  1. 選擇 Sanitizer（Microsoft AntiXSS/HtmlAgilityPack）（0.5 天）
  2. 依需求配置白名單（0.5 天）
  3. 加入單元測試與惡意樣本（1 天）
• 關鍵程式碼/設定：

  public static string Sanitize(string html) {
  var whitelist = new HashSet<string>{"b","i","u","a","img","p","br","ul","ol","li","code"};
  var doc = new HtmlAgilityPack.HtmlDocument(); doc.LoadHtml(html);
  void CleanNode(HtmlAgilityPack.HtmlNode node) {
    if (!whitelist.Contains(node.Name.ToLower())) { node.ParentNode.RemoveChild(node, true); return; }
    foreach (var a in node.Attributes.ToList()) {
      var name = a.Name.ToLower();
      if (name.StartsWith("on")) { node.Attributes.Remove(a); continue; }
      if (node.Name=="a" && name=="href" && a.Value.StartsWith("javascript:")) node.Attributes.Remove(a);
      if (node.Name=="img" && name=="src" && !(a.Value.StartsWith("http")||a.Value.StartsWith("data:image"))) node.Attributes.Remove(a);
    }
    foreach (var child in node.ChildNodes.ToList()) if (child.NodeType==HtmlAgilityPack.HtmlNodeType.Element) CleanNode(child);
  }
  foreach (var n in doc.DocumentNode.ChildNodes.ToList()) if (n.NodeType==HtmlAgilityPack.HtmlNodeType.Element) CleanNode(n);
  return doc.DocumentNode.InnerHtml;
  }
  

• 實際案例：貼圖/表情功能同時導入清洗，保障內容安全。
• 實作環境：.NET、HtmlAgilityPack
• 實測數據（驗收目標）：
  • OWASP XSS 測試樣本阻擋率 100%
  • 平均清洗耗時 < 10ms/篇
• Learning Points：白名單策略、常見 XSS 向量、效能
• 技能要求：C# 後端；進階：安全測試

• 延伸思考：如何與 CSP 搭配？是否需不同群組白名單？

• Practice：加入 CSP 標頭與 img-src 白名單
• 評估：安全通過；效能合格；配置可維護

Case #10: 瀏覽器相容性與降級策略（FTB 失效改用 textarea）

Problem Statement

• 業務場景：在某些環境或舊版瀏覽器 FTB 可能無法正確載入，需要保底的可編輯體驗與功能降級。
• 技術挑戰：偵測失敗與自動切換 UI。
• 影響範圍：可用性與支援成本。
• 複雜度評級：低

Root Cause Analysis

• 直接原因：FTB 依賴 iframe contentEditable；部分瀏覽器/企業環境阻擋。
• 深層原因：缺乏健壯的降級設計。

Solution Design

• 解決策略：載入後心跳檢查 FTB 是否可編輯；失敗則隱藏 FTB、顯示 textarea 並保留基本插入（以 BBCode 或 Markdown）與伺服器端轉換。

• 實施步驟：
  1. 可用性檢測腳本（0.5 天）
  2. 降級 UI 與提示（0.5 天）
  3. 伺服器端轉換器（1 天）
• 關鍵程式碼/設定：

  function editorHealthy(frameId) {
  try {
    var doc = document.getElementById(frameId).contentDocument;
    var editable = doc && doc.body && doc.body.isContentEditable !== false;
    return !!editable;
  } catch(e){return false;}
  }
  window.addEventListener('load', function(){
  if(!editorHealthy('FreeTextBox1___Frame')){
    document.getElementById('FTBContainer').style.display='none';
    document.getElementById('FallbackTextarea').style.display='';
  }
  });
  

• 實際案例：在客戶端阻擋腳本的環境仍可發文（降級）。
• 實作環境：JS/C#
• 實測數據（驗收目標）：
  • 降級命中時仍可完成所有必需欄位
  • 失敗回報率下降 ≥ 80%
• Learning Points：降級設計、健康檢查、回退渲染
• 技能要求：JS 基礎；進階：格式轉換

• 延伸思考：如何同步兩種模式的草稿？如何提示升級瀏覽器？

• Practice：實作 Markdown→HTML 伺服端轉換
• 評估：降級可用；提示清楚；錯誤處理完善

Case #11: 靜態資源負載優化：圖示懶載與快取

Problem Statement

• 業務場景：工具列圖示與表情資源較多，初次載入耗時與請求數過高。
• 技術挑戰：在不破壞功能的前提下降低初次成本。
• 影響範圍：LCP、互動延遲、伺服器負載。
• 複雜度評級：低

Root Cause Analysis

• 直接原因：一次載入全部圖示與表情；缺少快取策略。
• 深層原因：未做資源分割與延遲策略；缺 CDN/長快取。

Solution Design

• 解決策略：表情採懶載入；工具列圖示合併 Sprite 或 Icon Font；設定長快取與版本化；開啟 GZip/Deflate。

• 實施步驟：
  1. 懶載入與 IntersectionObserver（0.5 天）
  2. 版本化資源與 Cache-Control（0.5 天）
  3. 圖示合併與體積優化（1 天）
• 關鍵程式碼/設定： ```http

  IIS web.config 片段（靜態資源快取）

```javascript
// 懶載入回退
document.querySelectorAll('img[data-src]').forEach(img=>{
  if('IntersectionObserver' in window){
    new IntersectionObserver((es,ob)=>es.forEach(e=>{
      if(e.isIntersecting){ e.target.src=e.target.dataset.src; ob.unobserve(e.target); }
    })).observe(img);
  } else { img.src = img.dataset.src; }
});

• 實際案例：表情面板從 100+ 張圖改為視窗內懶載，首屏更快。
• 實作環境：IIS/Web.config、前端 JS
• 實測數據（驗收目標）：
  • 首屏請求數下降 ≥ 60%
  • LCP 改善 ≥ 30%
• Learning Points：快取策略、懶載入、資源版本化
• 技能要求：前端性能；進階：CDN 與壓縮

• 延伸思考：能否使用 HTTP/2 Push/Preload？是否切換成 SVG？

• Practice：將工具列圖示改為 SVG Sprite
• 評估：指標改善；相容性良好；可回退

Case #12: 升級與維護：以 ControlAdapter/HttpModule 降低侵入性

Problem Statement

• 業務場景：對編輯器的修改希望在 CS 升級時最小衝擊，避免直接改第三方檔案。
• 技術挑戰：以 ASP.NET 的 ControlAdapter 或 HttpModule 在外部注入行為。
• 影響範圍：維護成本、升級風險。
• 複雜度評級：中

Root Cause Analysis

• 直接原因：直接改動第三方程式導致升級困難。
• 深層原因：未使用框架提供的擴充管線。

Solution Design

• 解決策略：定義指定型別的 ControlAdapter，於 Render 前注入自訂腳本/工具列 DOM；或以 HttpModule 注入頁面尾段腳本。

• 實施步驟：
  1. 建立 .browser 對應與 Adapter 類（1 天）
  2. 測試多頁面注入效果（0.5 天）
  3. 升級回歸測試（0.5 天）
• 關鍵程式碼/設定： ```xml

```csharp
public class FTBAdapter : System.Web.UI.Adapters.ControlAdapter {
  protected override void Render(HtmlTextWriter writer) {
    base.Render(writer);
    // 追加自訂腳本
    writer.Write("<script>/* 注入工具列或命令 */</script>");
  }
}

• 實際案例：所有 FTB 控制項統一注入自訂功能，無需改第三方檔案。
• 實作環境：ASP.NET WebForms
• 實測數據（驗收目標）：
  • 升級衝突 0
  • 新版接入工時下降 ≥ 70%
• Learning Points：ControlAdapter、HttpModule、非侵入式注入
• 技能要求：ASP.NET 管線；進階：跨頁注入策略

• 延伸思考：如何精準篩選頁面？如何做版本檢測與降級？

• Practice：以 HttpModule 在 </form> 前注入初始化腳本
• 評估：注入穩定；升級友好；影響面可控

Case #13: 多語系與在地化資源支援工具列與對話框

Problem Statement

• 業務場景：平台面向多地區用戶，工具列按鈕與對話框需根據文化設定顯示本地化文字與日期/校驗訊息。
• 技術挑戰：資源管理、文化切換、格式化。
• 影響範圍：使用者體驗與國際化合規。
• 複雜度評級：低

Root Cause Analysis

• 直接原因：按鈕標籤與提示硬編碼。
• 深層原因：未使用 .resx 與文化設定。

Solution Design

• 解決策略：將文案遷移到 .resx；於 Page.UICulture 切換；JS 端以後端輸出字串或載入 JSON 資源。

• 實施步驟：
  1. 建立 Resources 與鍵值（0.5 天）
  2. Page 設定 UICulture/Culture（0.5 天）
  3. 對話框載入本地化字串（0.5 天）
• 關鍵程式碼/設定：

  // Page 指定文化
  protected override void InitializeCulture() {
  UICulture = Culture = Request.UserLanguages?[0] ?? "zh-TW";
  base.InitializeCulture();
  }
  // 使用資源
  btnInsert.Text = Resources.Editor.InsertImage;
  

• 實際案例：插入圖片對話框文案隨瀏覽器語言切換。
• 實作環境：.NET 資源系統、JS
• 實測數據（驗收目標）：
  • 語系覆蓋率 ≥ 95%
  • 切換延遲 ≈ 0（載入前置）
• Learning Points：.resx、文化設定、JS 國際化
• 技能要求：.NET 資源；進階：I18N 流程

• 延伸思考：是否需 RTL 支援？如何管理翻譯版本？

• Practice：為表情面板新增多語系提示
• 評估：文案可切換；無硬編碼；維護方便

Case #14: 無障礙與鍵盤操作：ARIA/快捷鍵/焦點管理

Problem Statement

• 業務場景：提升編輯器可及性，支援無障礙規範；提供鍵盤快捷鍵插入圖片/表情。
• 技術挑戰：ARIA 標註、焦點循環、快捷鍵衝突。
• 影響範圍：法規遵循與使用者覆蓋。
• 複雜度評級：中

Root Cause Analysis

• 直接原因：工具列按鈕缺 aria-label；對話框焦點陷阱未處理。
• 深層原因：無障礙未納入設計標準。

Solution Design

• 解決策略：工具列 role=”toolbar”、button aria-label；對話框加焦點陷阱；定義快捷鍵（如 Alt+I 插入圖片）並可在設定中關閉。

• 實施步驟：
  1. ARIA 與語意標記（0.5 天）
  2. 焦點管理與陷阱（0.5 天）
  3. 快捷鍵實作與提示（0.5 天）
• 關鍵程式碼/設定： ```html

- 實際案例：常用操作均有鍵盤路徑，對話框可鍵盤關閉與循環。
- 實作環境：HTML/JS
- 實測數據（驗收目標）：
  - 鍵盤可達率 100%
  - WAI-ARIA linter 無嚴重錯誤

- Learning Points：ARIA、焦點管理、快捷鍵設計
- 技能要求：前端基礎；進階：A11y 測試
- 延伸思考：衝突鍵位管理？螢幕閱讀器相容？

- Practice：為表情面板加鍵盤導航（左右上下）
- 評估：無障礙分數提升；快捷鍵清晰可配

---

## Case #15: 自動化測試與驗收腳本：Selenium 驗證編輯流程

### Problem Statement
- 業務場景：避免回歸時編輯器功能被破壞；建立自動化 UI 測試覆蓋圖片/表情插入與發佈流程。
- 技術挑戰：跨 iframe 操作、等待條件、環境資料隔離。
- 影響範圍：品質、發佈信心。
- 複雜度評級：中

### Root Cause Analysis
- 直接原因：手動回歸成本高且易遺漏。
- 深層原因：缺乏可執行的 UI 測試基礎設施。

### Solution Design
- 解決策略：以 Selenium WebDriver 建立端對端測試：登入→開啟編輯→插入圖片/表情→發佈→斷言內容包含 <img> 與 alt。

- 實施步驟：
  1. 測試環境與帳號資料（0.5 天）
  2. 測試腳本與選擇器穩定化（1 天）
  3. CI 整合（0.5 天）

- 關鍵程式碼/設定：
```csharp
[Test]
public void InsertImage_Emote_AndPublish() {
  var d = new ChromeDriver();
  d.Navigate().GoToUrl("https://cs.local/login"); // ...登入略
  d.Navigate().GoToUrl("https://cs.local/new-post");
  // 切到 FTB iframe
  d.SwitchTo().Frame("FreeTextBox1___Frame");
  d.FindElement(By.CssSelector("body")).Click();
  d.SwitchTo().DefaultContent();
  d.FindElement(By.Id("btnInsertImg")).Click();
  // 模擬上傳或輸入 URL 後插入
  // 發佈並驗證
  d.FindElement(By.Id("btnPublish")).Click();
  Assert.IsTrue(d.PageSource.Contains("<img"));
  d.Quit();
}

• 實際案例：確保每次發佈流程可插入多媒體且成功呈現。
• 實作環境：Selenium、CI（Azure DevOps/GitHub Actions）
• 實測數據（驗收目標）：
  • 測試穩定通過率 ≥ 95%
  • 單輪測試 < 2 分鐘
• Learning Points：iframe 測試、穩定選擇器、CI 一體化
• 技能要求：測試框架；進階：測試資料管理

• 延伸思考：如何 Mock 上傳？如何做視覺回歸比較？

• Practice：新增 XSS 攻擊樣本自動化測試
• 評估：覆蓋率、穩定性、報告清晰

案例分類

1) 按難度分類

• 入門級（適合初學者）
  • Case 7（表情選單）、Case 8（工具列 UX）、Case 10（降級策略）、Case 11（資源優化）、Case 13（多語系）
• 中級（需要一定基礎）
  • Case 1（工具列注入）、Case 2（尋控/反射）、Case 4（FTB 客製命令）、Case 5（插入 API）、Case 6（上傳整合）、Case 14（無障礙）、Case 15（自動化測試）
• 高級（需要深厚經驗）
  • Case 3（Adapter 替換）、Case 12（ControlAdapter/HttpModule 非侵入式架構）、Case 9（安全消毒策略）

2) 按技術領域分類

• 架構設計類：Case 3, 12
• 效能優化類：Case 11
• 整合開發類：Case 1, 4, 6, 7, 8, 10, 13, 14
• 除錯診斷類：Case 2, 5, 15
• 安全防護類：Case 9, 6（上傳驗證也涉資安）

3) 按學習目標分類

• 概念理解型：Case 10, 11, 13, 14
• 技能練習型：Case 1, 4, 5, 7, 8
• 問題解決型：Case 2, 6, 9, 12, 15
• 創新應用型：Case 3（Adapter）、Case 12（無侵入式注入）

案例關聯圖（學習路徑建議）

• 建議先學順序（由淺入深）： 1) Case 7（表情選單）→ 2) Case 8（工具列 UX）→ 3) Case 1（工具列注入） 4) Case 5（插入 API）→ 5) Case 4（FTB 客製命令）→ 6) Case 6（上傳整合） 7) Case 10（降級策略）→ 8) Case 11（資源優化）→ 9) Case 13（多語系） 10) Case 14（無障礙）→ 11) Case 2（尋控/反射）→ 12) Case 9（安全消毒） 13) Case 12（非侵入式注入）→ 14) Case 3（Adapter 替換）→ 15) Case 15（自動化測試）

• 依賴關係：
  • Case 1 依賴 Case 5（插入 API 基礎）
  • Case 4 依賴 Case 5（命令最終插入）
  • Case 6 依賴 Case 1/4/5（對話框插入）、並關聯 Case 9（安全）
  • Case 12 可受益於 Case 2（尋控策略）經驗
  • Case 3 在完成 Case 12 的非侵入式思維後再進行
  • Case 15 覆蓋前述所有功能的驗收
• 完整學習路徑建議：
  • 第一階段（基礎功能）：Case 7 → 8 → 1 → 5 → 4
  • 第二階段（端到端整合）：Case 6 → 10 → 11 → 13 → 14
  • 第三階段（穩定與安全）：Case 2 → 9 → 12
  • 第四階段（架構與品質）：Case 3 → 15

說明：以上案例均以原文的真實困境為核心（CS 使用 FTB 並被 Wrapper 阻隔，導致無法把貼圖/表情整合進原工具列），延展出可操作的解決方案與實作練習，便於實戰教學、專案練習與能力評估。