瀏覽器請求到呈現的完整流程 輸入 URL 或點擊連結 瀏覽器透過 DNS 解析 IP 發送 HTTP 請求 連線伺服器並請求內容（伺服器端處理留待後文） 瀏覽

IIS 6.0 啟用 64 位模式步驟 開啟命令提示字元（cmd）。 停用 32 位模式：cscript C:\inetpub\adminscripts\ad

兩個實用轉換方法 方法一：相對於指定頁面的虛擬路徑 /// <summary> /// 將 Web 站點下的絕對路徑轉換為相對於指定頁面的虛擬路徑

三種方案比較 1. 應用程式池設為「本地系統」 在 IIS 中建立獨立應用程式池，身分設為 LocalSystem。 優點：僅修改 IIS 設定，部署簡單。

系列緣起與多線程無處不在 身為 ASP.NET 開發者，平日較少主動寫多線程，但隨 .NET 4.0 即將釋出，並行計算將成主流，故以部落格系列總結 .NET

建立線程與核心屬性 Console.WriteLine(Process.GetCurrentProcess().Threads.Count); // 啟動初期

線程同步本質：序列化共享資源訪問 「同步」非指線程步調一致，而是強制線程「按序」訪問共享可變資源，避免競態條件。線程衝突 = 多線程同時訪問共享資源導致資料不一

同步基元分類：鎖定、通知、聯鎖 鎖定：lock（獨佔）、Semaphore（計數信號，允許 N 線程進入） 通知：AutoResetEvent（自動重置）、M

為何需要線程池？ 線程、資料庫連線等資源創建/銷毀代價高。池化技術：預先備妥資源，用時取用、閒時歸還、不足時擴充，避免頻繁分配回收。 高併發場景：每秒 100

自訂簡易線程池實現 核心需求： 池中線程數維持在最小/最大值之間 不足時創建、閒置時回收 任務排隊，無可用線程時等待 僅示範核心邏略，不考慮效能優化（如延遲

System.Threading.Timer 組件 常見需求：定時執行計劃任務、長任務進度顯示（需新線程避免阻塞 UI）。.NET 提供 System.Thre

UI 線程阻塞問題與跨線程操作異常 按鈕點擊事件中執行耗時操作（Thread.Sleep(1000) + 字串建構）會導致 UI 凍結 1 秒，無法拖動、縮放視

三種 Timer 的線程行為差異 前文介紹過兩種基於 ThreadPool 的 Timer（System.Threading.Timer、System.Time

多線程的兩大優勢：並行運算與異步操作 多線程可發揮多核心效能（並行運算），亦能讓長時間操作獨立執行不阻塞主線程（異步操作）。前者利用多核提升效能，後者避免 CP

基於 IAsyncResult 的異步編程模型（APM） 前文介紹了最原始的 Thread + 信號量 + 鎖 + Control.Invoke 組合。.NET

為何線程被視為昂貴資源？ 《CLR via C#》第三版剛出版，書中關於線程章節的見解彌補了我過去的知識盲區，因此將關鍵點整理成此系列文章。作者身為微軟顧問，不

本文整理自《CLR via C# 第三版》關於執行緒同步的核心觀念、兩種同步結構（使用者模式/核心模式）效能對比，並附上作者實測程式碼與結果分析。 執行緒同步

.NET 4.0 引入平行運算庫 (TPL, PLINQ)，封裝多執行緒複雜度，讓開發者輕鬆將迴圈平行化。但「易用」不等於「無副作用」，特別是 ASP.NET

許多 MVC 教學預設使用 Linq to SQL 或 Entity Framework，但實務上 ADO.NET、Dapper、原生 SqlClient 等同

ASP.NET MVC 移除 WebForms 的 ScriptManager 後，開發者需自行解決腳本重複引用、載入順序、衝突等問題。本文提出一個極簡的 Ht