[設計案例] 清除Cache物件 #2. Create Custom CacheDependency

Case #1: 標籤化批次失效：以 Host 為維度的一鍵清除

Problem Statement（問題陳述）

業務場景：一個批次下載服務會抓取約 50 組外部網址並快取內容，以降低重複下載成本。當特定來源站點（例如 funp.com）內容失效或需緊急下架，需快速清除該來源在快取中的所有項目，避免提供過期資料。 技術挑戰：ASP.NET Cache 預設以 key 操作，缺乏以來源維度（Host）批次清除的能力；逐一移除需要掌握所有 key，成本高且易漏刪。 影響範圍：快取污染造成使用者取得舊資料、外部合規風險、營運回應時間拉長。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

Cache 以 key 為單位管理，無內建群組/標籤操作。
下載內容的 key 與業務語意（Host）無直接關聯，難以依語意清除。
人工作業或碼表維護所有 key 容易遺漏且耗時。

深層原因：

架構層面：缺少針對快取項目的語意化分組（群組化/標籤化）設計。
技術層面：未運用 CacheDependency 的失效傳遞能力做群組清除。
流程層面：清除流程仰賴人工或硬編碼 key 清單，無自動化。

Solution Design（解決方案設計）

解決策略：以自訂 CacheDependency 將快取項目標記為一或多個 tag（例如 Host），維護 tag→依賴實例對應表。當需清除某來源時，透過該 tag 廣播失效，讓所有相關快取項目自動失效。

實施步驟：

建立自訂依賴類別
- 實作細節：繼承 CacheDependency；以靜態 Dictionary<string, List> 維護 tag→依賴清單；於建構時註冊，透過 NotifyDependencyChanged 廣播失效。
- 所需資源：.NET Framework、System.Web、C#
- 預估時間：1-2 小時
插入快取時附加 tag
- 實作細節：HttpRuntime.Cache.Add 時以 TaggingCacheDependency(sourceURL.Host) 標記。
- 所需資源：既有下載邏輯
- 預估時間：0.5 小時
一鍵清除目標來源
- 實作細節：於運維或程式中呼叫 TaggingCacheDependency.DependencyDispose(“funp.com”)
- 所需資源：管理控制介面/觸發點
- 預估時間：0.5 小時

關鍵程式碼/設定：

public class TaggingCacheDependency : CacheDependency
{
    private static readonly Dictionary<string, List<TaggingCacheDependency>> _lists
        = new Dictionary<string, List<TaggingCacheDependency>>();

    public TaggingCacheDependency(params string[] tags)
    {
        foreach (var tag in tags)
        {
            if (!_lists.ContainsKey(tag))
                _lists.Add(tag, new List<TaggingCacheDependency>());
            _lists[tag].Add(this);
        }
        // 完成依賴初始化
        this.SetUtcLastModified(DateTime.MinValue);
        this.FinishInit();
    }

    public static void DependencyDispose(string tag)
    {
        if (_lists.ContainsKey(tag))
        {
            foreach (var tcd in _lists[tag])
                tcd.NotifyDependencyChanged(null, EventArgs.Empty);
            _lists[tag].Clear();
            _lists.Remove(tag);
        }
    }
}

// 插入快取搭配 Host 做為 tag
HttpRuntime.Cache.Add(
    sourceURL.ToString(),
    buffer,
    new TaggingCacheDependency(sourceURL.Host),
    Cache.NoAbsoluteExpiration,
    TimeSpan.FromSeconds(600), // 滑動過期 10 分鐘
    CacheItemPriority.NotRemovable,
    Info);

// 一鍵清除指定 Host
TaggingCacheDependency.DependencyDispose("funp.com");

實際案例：對 50 組網址建立快取，以 Host 設為 tag；呼叫 DependencyDispose(“funp.com”) 後，印出被移除 key，確認僅 funp.com 來源被清除。實作環境：.NET Framework（System.Web）、Visual Studio 2008 專案。實測數據：

改善前：需針對 funp.com 相關每個 key 分別 Cache.Remove，最多 50 次。
改善後：1 次呼叫 DependencyDispose(“funp.com”)。
改善幅度：移除呼叫次數降低 98%（50→1）。

Learning Points（學習要點）核心知識點：

CacheDependency 的失效傳播機制
以 tag 建立快取語意分組
NotifyDependencyChanged 的使用

技能要求：

必備技能：C#、ASP.NET Cache API
進階技能：高效資料結構設計、快取失效策略設計

延伸思考：

亦可用於分類、租戶、多語系等維度清除。
風險：需管理 tag 空間以免無界成長。
可加入並行安全與觀測性（metrics/logging）。

Practice Exercise（練習題）

基礎練習：將現有一個快取項目改為帶 Host tag，並透過 DependencyDispose 清除。
進階練習：對 50 個隨機 Host 的項目進行指定 Host 的批次清除與驗證。
專案練習：實作一個簡易管理介面，可列出/清除指定 tag 的快取。

Assessment Criteria（評估標準）

功能完整性（40%）：能以指定 Host 清除所有對應項。
程式碼品質（30%）：結構清晰、命名語意化、避免重複。
效能優化（20%）：清除為 O(k)（k 為該 tag 項數），無遍歷所有快取。
創新性（10%）：可擴展為多維度、複合條件清除。

Case #2: 多標籤關聯：以 Host + Scheme 組合做選擇性清除

Problem Statement（問題陳述）

業務場景：同一來源站點可能同時提供 http 與 https 內容，需支援「清除該站點全部」或「只清除 http」的彈性策略。 技術挑戰：單一鍵值無法表達多維標記，手動維護多組 key 清單複雜且易錯。 影響範圍：清除覆蓋過廣或過窄，導致服務不可用或舊資料殘留。 複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

快取 key 不包含 Scheme 維度。
無群組化與條件化清除機制。
人工清單維護成本高。

深層原因：

架構層面：未提供多標籤（host、scheme）映射。
技術層面：未善用可變參數標籤註冊。
流程層面：清除策略未語意化。

Solution Design（解決方案設計）

解決策略：插入快取時同時標記 Host 與 Scheme 兩個 tag；需要時可依任一 tag 清除，實現「全站」或「單 Scheme」清除。

實施步驟：

插入快取時標記多個 tag
- 實作細節：new TaggingCacheDependency(sourceURL.Host, sourceURL.Scheme)
- 所需資源：現有 Add 呼叫
- 預估時間：0.5 小時
制定清除策略
- 實作細節：DependencyDispose(“funp.com”) 或 DependencyDispose(“https”)
- 所需資源：運維控制點
- 預估時間：0.5 小時

關鍵程式碼/設定：

HttpRuntime.Cache.Add(
    sourceURL.ToString(),
    buffer,
    new TaggingCacheDependency(sourceURL.Host, sourceURL.Scheme), // 兩個 tag：Host 與 Scheme
    Cache.NoAbsoluteExpiration,
    TimeSpan.FromSeconds(600),
    CacheItemPriority.NotRemovable,
    Info);

// 清除整個 Host
TaggingCacheDependency.DependencyDispose("funp.com");

// 或只清除 http
TaggingCacheDependency.DependencyDispose("http");

實際案例：以 Host + Scheme 標記；呼叫 http/https 任一 tag，僅對應 Scheme 的項目被移除。實作環境：同 Case #1。實測數據：

改善前：需手寫兩組 key 清單（host 全站 vs 指定 scheme）。
改善後：各 1 次呼叫即可。
改善幅度：維運操作步驟由多步縮為 1 步，錯誤點減少。

Learning Points（學習要點）

多標籤策略設計
以語意維度（Host/Scheme）管理快取
清除粒度控制

技能要求：

必備：C#、ASP.NET Cache API
進階：抽象化清除策略的 API 設計

延伸思考：

支援更多維度（語言、租戶、資料版本）。
過多標籤可能增加記憶體佔用。
可封裝「複合條件清除」方法。

Practice Exercise

基礎：對同 host 的 http/https 建立快取，分別清除並驗證。
進階：新增 locale tag，實作 host+locale 或 scheme+locale 清除。
專案：設計 tag 運算（交集/聯集）的小工具。

Assessment Criteria

功能完整性：可單獨/全部清除
程式碼品質：可讀性與抽象合理
效能：清除不遍歷全表
創新性：複合條件封裝良好

Case #3: 告別逐鍵移除：降低遺漏與維護成本

Problem Statement

業務場景：變更規則或合作站異常時，需要快速撤除該來源的所有快取。若必須逐鍵清除，維護 key 清單與操作成本高。 技術挑戰：缺乏群組清除能力，逐鍵操作易漏刪。 影響範圍：殘留舊資料、用戶體驗下降、法遵風險。 複雜度評級：低

Root Cause Analysis

直接原因：以 key 為中心的 API 不支援語意清除；人工清單易錯。
深層原因：
- 架構：無群組化索引。
- 技術：未用 CacheDependency。
- 流程：無自動化清除流程。

Solution Design

解決策略：導入 tag + 依賴失效模型，以一指令廣播失效，避免人工列舉 key。

實施步驟：

為關鍵維度定義 tag（如 Host）
- 實作細節：來源屬性即標籤
- 資源：URL 解析
- 時間：0.5 小時
插入帶 tag 的依賴
- 實作細節：new TaggingCacheDependency(host)
- 時間：0.5 小時
清除：DependencyDispose(tag)
- 實作細節：管理端一鍵操作
- 時間：0.5 小時

關鍵程式碼/設定：

// 舊：多次 Cache.Remove("keyX") 改為：一次 tag 清除
TaggingCacheDependency.DependencyDispose("funp.com");

實測數據：

改善前：最多 50 次 Remove（樣本大小）。
改善後：1 次清除。
改善幅度：-98% 操作次數；漏刪風險大幅降低（由人工改為系統語意化）。

Learning Points

快取操作自動化與語意化
風險與操作面同時優化

技能要求：C#、快取 API；進階：設計可運維的 API。

延伸思考：可加入審計/權限控管；風險在於 tag 管理混亂。

Practice Exercise：將一段 for 移除迴圈改為單一 tag 清除；擴展支援多 tag 清除。

Assessment Criteria：功能正確、程式整潔、操作簡化、可維運性高。

Case #4: 自訂 CacheDependency 的正確初始化：SetUtcLastModified + FinishInit

Problem Statement

業務場景：團隊嘗試自訂 CacheDependency，但發現依賴未生效，無法觸發快取失效。 技術挑戰：不熟悉 CacheDependency 初始化與生命週期，導致依賴未註冊成功。 影響範圍：清除失效、資料不一致。 複雜度評級：中

Root Cause Analysis

直接原因：未設定 LastModified 或未呼叫 FinishInit。
深層原因：
- 架構：對依賴生命週期理解不足。
- 技術：忽略必要初始化呼叫。
- 流程：缺少單元測試驗證依賴行為。

Solution Design

解決策略：於建構函式中設定 SetUtcLastModified，並呼叫 FinishInit 完成註冊，確保 NotifyDependencyChanged 能正確生效。

實施步驟：

在建構函式中設定最後修改時間
- 實作細節：SetUtcLastModified(DateTime.MinValue)
- 時間：0.2 小時
完成初始化
- 實作細節：FinishInit()
- 時間：0.2 小時

關鍵程式碼/設定：

public TaggingCacheDependency(params string[] tags)
{
    // ...註冊至 tag 索引略
    this.SetUtcLastModified(DateTime.MinValue); // 必要：初始化變更點
    this.FinishInit();                           // 必要：完成依賴初始化
}

實測數據：

改善前：呼叫清除後快取未失效。
改善後：清除即刻生效，回呼觸發。
改善幅度：功能由不可用→可用（100% 成功率）。

Learning Points：了解 CacheDependency 初始化必要步驟與時機。技能要求：熟悉 .NET 快取生命週期。延伸思考：可封裝基底類以避免遺漏初始化。

Practice Exercise：撰寫單元測試驗證依賴生效與回呼觸發。 Assessment：測試覆蓋、初始化正確、依賴生效。

Case #5: 依賴通知：使用 NotifyDependencyChanged 強制失效

Problem Statement

業務場景：需要在特定事件發生時（如外部通知）立即使一批快取失效。 技術挑戰：如何自訂觸發點讓快取感知並失效。 影響範圍：延遲清除造成資料不一致。 複雜度評級：低

Root Cause Analysis

直接原因：未呼叫依賴的變更通知。
深層原因：
- 架構：缺少事件驅動失效機制。
- 技術：不了解 CacheDependency 通知 API。

Solution Design

解決策略：透過依賴物件呼叫 NotifyDependencyChanged，讓 Cache 主動移除綁定項目。

實施步驟：

維護 tag→依賴清單
針對目標 tag 迭代呼叫 NotifyDependencyChanged
清理索引避免殘留

關鍵程式碼/設定：

public static void DependencyDispose(string tag)
{
    if (_lists.ContainsKey(tag))
    {
        foreach (var tcd in _lists[tag])
            tcd.NotifyDependencyChanged(null, EventArgs.Empty); // 核心：廣播失效
        _lists[tag].Clear();
        _lists.Remove(tag);
    }
}

實測數據：呼叫後所有相關項目回呼被觸發並從快取移除（以主控台輸出驗證）。 Learning Points：依賴通知是主動清除的關鍵。 Practice：為另一個 tag 實作相同通知並驗證。 Assessment：通知正確、清理完整、無殘留。

Case #6: 靜態字典追蹤依賴清單：快速定位需失效的 CacheItem

Problem Statement

業務場景：需要高效率找出某 tag 對應的所有快取項目。 技術挑戰：若無索引，需掃描全部快取，成本高。 影響範圍：清除延遲、CPU 浪費。 複雜度評級：中

Root Cause Analysis

直接原因：缺少 tag→依賴的索引資料結構。
深層原因：
- 架構：未將快取分組索引化。
- 技術：未選擇合適的資料結構。

Solution Design

解決策略：以 Dictionary<string, List> 維護對應，提供 O(1) 取得清單並 O(k) 清除。

實施步驟：

初始化靜態字典並於建構註冊
依賴清除後移除索引條目
封裝查詢與清除 API

關鍵程式碼/設定：

private static readonly Dictionary<string, List<TaggingCacheDependency>> _lists
    = new Dictionary<string, List<TaggingCacheDependency>>();

_lists[tag].Add(this); // 註冊依賴到 tag

實測數據：

改善前：理論上需 O(N) 掃描全部快取。
改善後：O(1)+O(k) 清除（k 為該 tag 的項目數）。
改善幅度：大幅減少計算量（N=50 時已明顯）。

Learning Points：索引化設計對操作效率的影響。 Practice：對多 tag 情境測量 k 的清除時間。 Assessment：資料結構正確、時間複雜度合理、清除無漏。

Case #7: 清理後釋放索引：避免標籤殘留與記憶體浪費

Problem Statement

業務場景：多次清除不同 tag 後，擔心索引殘留造成記憶體浪費。 技術挑戰：如何在清除後安全釋放索引。 影響範圍：長期記憶體佔用升高，可能引發 GC 壓力。 複雜度評級：低

Root Cause Analysis

直接原因：未清空 List 或未移除字典鍵。
深層原因：缺少清理流程設計。

Solution Design

解決策略：清除後對應清單 Clear 並移除字典鍵，避免懸掛引用。

實施步驟：

清除時：遍歷通知
隨後：list.Clear() 並 _lists.Remove(tag)
檢查：不存在 tag 返回 no-op

關鍵程式碼/設定：

_lists[tag].Clear();
_lists.Remove(tag); // 移除索引鍵，避免殘留

實測數據：多次清除後，監看 _lists 不隨清除次數成長。 Learning Points：資源清理的重要性。 Practice：壓測 1000 次清除觀察記憶體曲線。 Assessment：無記憶體持續成長、功能正確。

Case #8: 移除回呼：可視化驗證與審計

Problem Statement

業務場景：需要知道哪些快取項目被移除，用於驗證與稽核。 技術挑戰：預設清除是安靜的，難以追蹤。 影響範圍：問題排查困難、合規不可追溯。 複雜度評級：低

Root Cause Analysis

直接原因：未註冊 CacheItemRemovedCallback。
深層原因：可觀測性設計缺失。

Solution Design

解決策略：在 Cache.Add 註冊回呼，移除時輸出 key 與原因。

實施步驟：

定義回呼 Info(key, value, reason)
Cache.Add 時傳入回呼
在回呼中記錄/告警

關鍵程式碼/設定：

private static void Info(string key, object value, CacheItemRemovedReason reason)
{
    Console.WriteLine($"Remove: {key}, Reason: {reason}");
}

HttpRuntime.Cache.Add(..., Info);

實測數據：清除 funp.com 後，輸出僅含該 Host 項目。 Learning Points：快取作業可觀測性/稽核。 Practice：改為寫入日誌並統計每次清除數量。 Assessment：可觀測性完整、資料準確。

Case #9: 滑動過期 + 依賴失效的並用策略

Problem Statement

業務場景：內容平時以滑動過期延長命中；遇事件需即時清除。 技術挑戰：如何同時保有 TTL 與立即失效能力。 影響範圍：無法即時撤除或命中率不足。 複雜度評級：中

Root Cause Analysis

直接原因：單用 TTL 無法即時失效；單用依賴命中率不佳。
深層原因：未組合多策略。

Solution Design

解決策略：NoAbsoluteExpiration + Sliding 600 秒 + 自訂依賴，同時達到高命中與即時清除。

實施步驟：

設定滑動過期 TimeSpan.FromSeconds(600)
設定 CacheItemPriority.NotRemovable 提升存活
發生事件時走依賴廣播清除

關鍵程式碼/設定：

HttpRuntime.Cache.Add(
    key, buffer,
    new TaggingCacheDependency(host),
    Cache.NoAbsoluteExpiration,      // 無絕對過期
    TimeSpan.FromSeconds(600),       // 滑動過期 10 分鐘
    CacheItemPriority.NotRemovable,  // 平時不被修剪
    Info
);

實測數據：平時命中維持；清除事件觸發，相關項目立即移除（回呼可見）。 Learning Points：多策略組合的快取行為設計。 Practice：比較純 TTL vs TTL+依賴在事件發生時的差異。 Assessment：策略正確、行為可預期、回呼可驗證。

Case #10: 安全空操作：處理不存在的標籤

Problem Statement

業務場景：運維可能誤輸入不存在的 tag，系統需具備安全行為。 技術挑戰：避免拋例外或影響其他快取。 影響範圍：可靠性降低、操作恐慌。 複雜度評級：低

Root Cause Analysis

直接原因：未檢查 tag 是否存在。
深層原因：缺少防禦式程式設計。

Solution Design

解決策略：清除前先 _lists.ContainsKey(tag)；不存在即 no-op。

實施步驟：

加入存在性檢查
將 no-op 行為記錄

關鍵程式碼/設定：

public static void DependencyDispose(string tag)
{
    if (!_lists.ContainsKey(tag)) return; // 防禦：不存在則不動作
    // ...清除略
}

實測數據：輸入未知 tag 時無錯誤、快取不受影響。 Learning Points：防禦式程式設計。 Practice：對連續未知 tag 呼叫並觀察行為。 Assessment：無例外、狀態不變、記錄完整。

Case #11: 用戶/管理員主動清除：API 介面設計

Problem Statement

業務場景：需要提供操作接口讓運維或自動化任務觸發清除。 技術挑戰：如何以簡潔 API 封裝動作。 影響範圍：操作成本與風險。 複雜度評級：低

Root Cause Analysis

直接原因：無公開方法。
深層原因：操作未產品化。

Solution Design

解決策略：提供靜態方法 DependencyDispose(tag) 作為唯一入口，便於權限管控與審計。

實施步驟：

定義靜態清除方法
在管理介面或作業腳本呼叫
記錄操作者與 tag

關鍵程式碼/設定：

TaggingCacheDependency.DependencyDispose("funp.com"); // 一行觸發

實測數據：操作縮短至一行呼叫；審計可記錄 tag 與時間。 Learning Points：封裝與可運維性。 Practice：包一層服務介面，可插入權限與審計。 Assessment：易用、可控、可追蹤。

Case #12: 最小侵入式接入：插入時加 Tag 即享依賴

Problem Statement

業務場景：已有大量使用 HttpRuntime.Cache.Add 的程式碼，導入新機制需最小改動。 技術挑戰：兼顧低風險與快速落地。 影響範圍：開發成本、上線風險。 複雜度評級：低

Root Cause Analysis

直接原因：API 差異可能大。
深層原因：未考量平滑過渡策略。

Solution Design

解決策略：僅調整 Add 的第三參數為 TaggingCacheDependency，其餘不動，達成最小侵入。

實施步驟：

封裝建構 tag 的小工廠方法
漸進改造現有 Add 呼叫

關鍵程式碼/設定：

// 原：new CacheDependency(...)
HttpRuntime.Cache.Add(key, value, new TaggingCacheDependency(host), ...);

實測數據：單處改動，風險低；功能立即可用。 Learning Points：漸進式重構策略。 Practice：在 3 個不同模組替換依賴參數。 Assessment：改動少、風險可控、功能達成。

Case #13: 跨資源維度的標籤策略：從 URI 抽取可重複利用的 Tag

Problem Statement

業務場景：需統一標籤策略，避免 ad-hoc 命名導致混亂。 技術挑戰：如何從資源屬性提取穩定、可重用的 tag。 影響範圍：清除精確度與維護性。 複雜度評級：低

Root Cause Analysis

直接原因：標籤命名不一致。
深層原因：缺少標準化規範。

Solution Design

解決策略：採用 Uri.Host、Uri.Scheme 作為標準 tag；未來可擴展 Path、Query 片段。

實施步驟：

訂立標籤規約（host、scheme）
封裝解析邏輯
在全專案統一套用

關鍵程式碼/設定：

var tags = new [] { uri.Host, uri.Scheme };
new TaggingCacheDependency(tags);

實測數據：觀察清除輸出與預期一致（僅命中相同 host 或 scheme）。 Learning Points：標籤治理與一致性。 Practice：加入語言參數作第三 tag。 Assessment：一致、可擴展、易理解。

Case #14: NotRemovable 項目的強制清除

Problem Statement

業務場景：關鍵資料平時設為 NotRemovable 防止修剪，但遇事件需強制移除。 技術挑戰：需確保 NotRemovable 仍可被指令性清除。 影響範圍：資料一致性。 複雜度評級：低

Root Cause Analysis

直接原因：NotRemovable 僅影響修剪，不代表不可清除。
深層原因：誤解優先級語意。

Solution Design

解決策略：將重要項目設 NotRemovable + 依賴；事件發生時透過依賴清除，繞過修剪機制限制。

實施步驟：

Add 設定 NotRemovable
綁定 TaggingCacheDependency
事件觸發清除

關鍵程式碼/設定：

HttpRuntime.Cache.Add(
  key, value, new TaggingCacheDependency(host),
  Cache.NoAbsoluteExpiration, TimeSpan.FromSeconds(600),
  CacheItemPriority.NotRemovable, Info);

實測數據：依賴清除仍順利移除 NotRemovable 項目（有回呼）。 Learning Points：理解 CacheItemPriority 與依賴的關係。 Practice：比較修剪與依賴清除的行為。 Assessment：語意正確、行為可預期。

Case #15: 最小代碼量的可用實作：<30 行完成核心功能

Problem Statement

業務場景：希望快速落地群組清除能力，研發投入有限。 技術挑戰：在短時間內交付可用方案。 影響範圍：交付節奏與成本。 複雜度評級：低

Root Cause Analysis

直接原因：功能需求集中在依賴與索引。
深層原因：可採用最小可行產品策略。

Solution Design

解決策略：以 <30 行的 TaggingCacheDependency 實作，先滿足核心需求，後續再優化。

實施步驟：

撰寫最小類別（建構註冊、FinishInit、DependencyDispose）
融入現有 Add 呼叫
驗證回呼

關鍵程式碼/設定：

// 核心類別 <30 行，見前述實作

實測數據：

核心類別低於 30 行。
清除能力立即可用。 Learning Points：MVP 思維與漸進式擴展。 Practice：在最小實作上加入基本日誌。 Assessment：功能可用、代碼精簡、易於擴展。

Case #16: 可重現驗證：批次下載示例與專案打包

Problem Statement

業務場景：需快速重現與驗證機制，供團隊學習與測試。 技術挑戰：搭建環境耗時。 影響範圍：導入速度、培訓成本。 複雜度評級：低

Root Cause Analysis

直接原因：缺少可執行樣例專案。
深層原因：學習/驗證資源不足。

Solution Design

解決策略：提供 URL 清單與 VS2008 範例專案，透過 Console.ReadLine 前後手動觸發清除並觀察輸出。

實施步驟：

載入 VS2008 專案
執行、等待首次快取
觸發 DependencyDispose(“funp.com”)，觀察輸出

關鍵程式碼/設定：

Console.ReadLine();
TaggingCacheDependency.DependencyDispose("funp.com");
Console.ReadLine();

實測數據：移除輸出僅包含 funp.com，證明清除精確。 Learning Points：以最小專案快速驗證設計。 Practice：替換 URL 清單測不同站點。 Assessment：可重現性、觀測性、教學價值高。

案例分類

1) 按難度分類

入門級（適合初學者）：
- Case #3, #7, #8, #10, #11, #12, #13, #15, #16
中級（需要一定基礎）：
- Case #1, #2, #4, #5, #6, #9, #14
高級（需要深厚經驗）：
- 無（本文範疇多為應用級；可延伸至分散式快取時成為高級議題）

2) 按技術領域分類

架構設計類：
- Case #1, #2, #3, #6, #9, #11, #12, #13, #15
效能優化類：
- Case #6, #9, #14
整合開發類：
- Case #1, #2, #11, #12, #16
除錯診斷類：
- Case #4, #5, #7, #8, #10, #16
安全防護類：
- Case #10（防禦式處理、穩定性）

3) 按學習目標分類

概念理解型：
- Case #1, #2, #3, #9, #14
技能練習型：
- Case #4, #5, #6, #7, #8, #10, #12
問題解決型：
- Case #1, #3, #11, #13, #16
創新應用型：
- Case #2, #9, #15

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

入門順序（概念→實作→驗證）： 1) 先學 Case #3（為何不用逐鍵移除）與 Case #1（tag 批次失效的核心概念）。 2) 接著 Case #4（正確初始化）、Case #5（依賴通知）、Case #6（索引資料結構）完成實作基礎。 3) 透過 Case #16（專案重現）驗證成效，搭配 Case #8（回呼可視化）觀察行為。
進階應用與操作： 4) 學習 Case #2（多標籤策略）、Case #13（標籤規範）擴充語意維度。 5) 學習 Case #12（最小侵入式導入）與 Case #11（提供運維 API）完成產品化接入。
策略優化與可靠性： 6) 深入 Case #9（TTL+依賴並用）與 Case #14（NotRemovable 強制清除）完善行為策略。 7) 學習 Case #7（索引清理）與 Case #10（未知 tag 的安全行為）提升穩定性。
完整路徑總結：概念（#3→#1）→ 實作（#4→#5→#6）→ 驗證（#16→#8）→ 應用擴展（#2→#13→#12→#11）→ 策略與可靠性（#9→#14→#7→#10）→ 精簡與推廣（#15）。透過此路徑，學習者可從理解痛點到能在專案中穩定落地，並具備持續優化能力。

[設計案例] 清除Cache物件 #2. Create Custom CacheDependency

Case #1: 標籤化批次失效：以 Host 為維度的一鍵清除

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #2: 多標籤關聯：以 Host + Scheme 組合做選擇性清除

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #3: 告別逐鍵移除：降低遺漏與維護成本

Problem Statement

Root Cause Analysis

Solution Design

Case #4: 自訂 CacheDependency 的正確初始化：SetUtcLastModified + FinishInit

Problem Statement

Root Cause Analysis

Solution Design

Case #5: 依賴通知：使用 NotifyDependencyChanged 強制失效

Problem Statement

Root Cause Analysis

Solution Design

Case #6: 靜態字典追蹤依賴清單：快速定位需失效的 CacheItem

Problem Statement

Root Cause Analysis

Solution Design

Case #7: 清理後釋放索引：避免標籤殘留與記憶體浪費

Problem Statement

Root Cause Analysis

Solution Design

Case #8: 移除回呼：可視化驗證與審計

Problem Statement

Root Cause Analysis

Solution Design

Case #9: 滑動過期 + 依賴失效的並用策略

Problem Statement

Root Cause Analysis

Solution Design

Case #10: 安全空操作：處理不存在的標籤

Problem Statement

Root Cause Analysis

Solution Design

Case #11: 用戶/管理員主動清除：API 介面設計

Problem Statement

Root Cause Analysis

Solution Design

Case #12: 最小侵入式接入：插入時加 Tag 即享依賴

Problem Statement

Root Cause Analysis

Solution Design

Case #13: 跨資源維度的標籤策略：從 URI 抽取可重複利用的 Tag

Problem Statement

Root Cause Analysis

Solution Design

Case #14: NotRemovable 項目的強制清除

Problem Statement

Root Cause Analysis

Solution Design

Case #15: 最小代碼量的可用實作：<30 行完成核心功能

Problem Statement

Root Cause Analysis

Solution Design

Case #16: 可重現驗證：批次下載示例與專案打包

Problem Statement

Root Cause Analysis

Solution Design

Facebook Pages

AI Synthesis Contents

Edit Post (Pull Request)

Post Directory