簡介：.NET WebForm是ASP.NET框架中用於構建動態網站的技術，通常依賴.aspx頁面作為前端入口。本文介紹如何通過IIS URL重寫模塊和自定義路由機制，隱藏.aspx後綴以優化SEO和用户體驗，並提供完整可運行的源碼示例。項目基於IIS配置、Web.config規則設置、Global.asax路由註冊及頁面邏輯處理，實現偽靜態化URL訪問，幫助開發者掌握WebForm下的友好URL實踐方案。

1. .NET WebForm項目結構與原理

核心組成與頁面生命週期

ASP.NET WebForm項目以 .aspx 文件為核心，每個頁面由 前端標記（aspx） 和 後台代碼（code-behind） 構成，二者通過 partial class 機制關聯。頁面運行時經歷完整的 生命週期 ：從 Init 、 Load 到 Render ，並依賴 ViewState 維護控件狀態，實現“偽靜態”的事件驅動模型。

// 示例：Default.aspx.cs 中的 Page_Load 事件
protected void Page_Load(object sender, EventArgs e)
{
    // ViewState 保存跨回發的狀態
    if (!IsPostBack)
        ViewState["LoadedTime"] = DateTime.Now;
}

HTTP請求管道與處理機制

當IIS接收到請求後，交由ASP.NET ISAPI擴展處理，進入 HTTP Pipeline 。在此過程中， HttpModule 監聽事件（如身份驗證），而 HttpHandler 負責最終響應——每個 .aspx 頁對應一個實現了 IHttpHandler 的類，由 PageParser 動態編譯執行。

路由與重寫的技術基礎

理解 HttpContext 、 HttpRequest.Path 及 UrlMapping 機制是實現無後綴URL的前提。後續章節將基於此，利用IIS重寫模塊或ASP.NET Routing，繞過物理路徑限制，實現SEO友好的虛擬URL路由。

2. IIS URL重寫模塊安裝與配置

在現代Web開發中，URL的可讀性、語義化以及搜索引擎優化（SEO）已成為系統設計的重要考量。傳統的ASP.NET WebForm應用通常依賴 .aspx 後綴暴露頁面物理路徑，這不僅破壞了URL的簡潔性，也容易泄露技術實現細節。為解決這一問題，IIS平台提供了強大的 URL Rewrite Module （URL重寫模塊），允許開發者通過規則引擎將用户請求的“虛擬”URL映射到真實的服務器資源上，從而實現無後綴或語義化URL訪問。

本章將深入探討如何在IIS環境中正確安裝並配置URL重寫模塊，涵蓋從基礎架構理解到實際操作的完整流程。重點包括IIS與ASP.NET的集成機制、模塊的獲取與部署方式、圖形化規則配置界面的使用方法，以及調試和日誌分析技巧。掌握這些內容是構建乾淨、高效、安全URL體系的第一步，也為後續基於 web.config 或Routing機制的高級路由策略打下堅實基礎。

2.1 IIS平台與ASP.NET集成模式

Internet Information Services（IIS）作為Windows平台上主流的Web服務器軟件，承擔着接收HTTP請求、處理靜態內容、轉發動態請求至應用程序池等核心職責。而ASP.NET WebForm應用能否正常運行，關鍵在於IIS如何與.NET運行時進行集成。這種集成並非單一固定模式，而是存在兩種主要的工作模式： 經典模式（Classic Mode） 和 集成模式（Integrated Mode） 。選擇合適的模式直接影響URL重寫模塊的行為表現和功能支持。

2.1.1 IIS工作進程與Application Pool配置

每個IIS站點都運行在一個獨立的 工作進程（Worker Process, w3wp.exe） 中，該進程負責執行所有與該站點相關的代碼邏輯。多個站點可以共享同一個工作進程，也可以各自擁有獨立實例，具體取決於其所屬的應用程序池（Application Pool）設置。

應用程序池是一種隔離機制，用於分隔不同Web應用之間的運行環境。通過創建獨立的應用程序池，可以避免某一應用崩潰影響其他站點，並便於資源監控與回收管理。要啓用URL重寫功能，首先需要確保目標站點所綁定的應用程序池已正確配置為支持.NET Framework版本（如4.0或更高），且託管管道模式設置得當。

<!-- 示例：applicationHost.config 中 Application Pool 定義片段 -->
<add name="MyWebFormAppPool" managedRuntimeVersion="v4.0" managedPipelineMode="Integrated">
    <processModel identityType="ApplicationPoolIdentity" />
</add>

上述XML片段展示了在IIS主配置文件 applicationHost.config 中定義一個名為 MyWebFormAppPool 的應用程序池。其中：
- managedRuntimeVersion="v4.0" 表示使用.NET Framework 4.x運行時；
- managedPipelineMode="Integrated" 指定採用集成管道模式；
- identityType="ApplicationPoolIdentity" 設置進程運行身份為最低權限賬户，提升安全性。

⚠️ 參數説明與邏輯分析
- managedRuntimeVersion 必須與項目編譯的目標框架一致，否則會導致HTTP 503服務不可用錯誤。
- 若設置為 Classic 模式，則ASP.NET請求不會進入統一的IIS請求管道，部分模塊（如URL重寫）可能無法攔截早期階段的請求。
- 推薦始終使用 Integrated 模式以獲得最佳兼容性和性能。

可通過IIS管理器圖形界面完成此配置：打開“應用程序池” → 右鍵新建 → 命名並選擇“.NET Framework v4.0” → 管道模式設為“集成”。

2.1.2 集成模式與經典模式的區別及其影響

✅ 結論：對於任何希望使用URL重寫的WebForm項目，必須運行在集成模式下。

在經典模式下，只有當請求命中特定擴展名（如 .aspx ）時，才會激活ASP.NET ISAPI擴展（aspnet_isapi.dll），這意味着即使你設置了將 /home 重寫為 /default.aspx ，如果未先讓IIS識別該請求應交由ASP.NET處理，則重寫規則根本不會被執行——請求會被當作靜態文件查找失敗而返回404。

而在集成模式中，整個HTTP請求生命週期被統一納入IIS的模塊化處理流程。無論是 /css/style.css 還是 /about ，都會依次經過身份驗證、授權、日誌記錄、重寫等模塊處理。因此，URL重寫模塊可以在請求到達文件系統前就完成路徑轉換，完美支持無後綴URL。

2.1.3 ASP.NET請求在IIS中的處理流程

以下是集成模式下典型的ASP.NET WebForm請求處理流程，結合Mermaid繪製的流程圖展示：

graph TD
    A[客户端發起HTTP請求 /product/123] --> B{IIS接收請求}
    B --> C[檢查是否匹配靜態文件]
    C -- 是 --> D[直接返回文件內容]
    C -- 否 --> E[進入Integrated Pipeline]
    E --> F[執行PreBeginRequest階段]
    F --> G[UrlRoutingModule觸發?]
    G -- 是 --> H[Routing匹配並設置Context.Handler]
    G -- 否 --> I[繼續默認處理]
    I --> J[URL Rewrite Module介入]
    J --> K{匹配重寫規則?}
    K -- 是 --> L[修改request.Path為/default.aspx?id=123]
    K -- 否 --> M[保持原路徑]
    M --> N[調用對應HttpHandler]
    N --> O[PageHandlerFactory創建Page對象]
    O --> P[執行Page LifeCycle]
    P --> Q[生成HTML響應]
    Q --> R[通過Output Cache緩存?]
    R -- 是 --> S[存儲響應]
    R -- 否 --> T[直接發送回客户端]

📌 流程解析與關鍵技術點
1. 請求首先進入IIS核心管道，由 StaticFileModule 判斷是否為靜態資源；
2. 若不是靜態文件，則進入集成管道，此時所有註冊的 HttpModule 均可參與處理；
3. UrlRewriteModule 在此階段根據規則修改 HttpContext.Request.Path 值；
4. 修改後的路徑傳遞給後續模塊，最終由 PageHandlerFactory 定位到實際的 .aspx 頁面；
5. 整個過程對客户端透明，瀏覽器仍顯示原始友好URL。

該流程清晰地揭示了為何必須啓用集成模式：只有在這種統一管道模型中，URL重寫模塊才能在足夠早的階段介入請求，改變其目標地址，進而引導至正確的 .aspx 頁面執行。

2.2 URL Rewrite模塊的獲取與安裝

微軟官方提供的 IIS URL Rewrite Module 2.1 是目前最穩定、功能最全面的重寫工具，支持正則表達式、條件判斷、反向代理等多種高級特性。它不是一個內置組件，需手動下載並安裝。

2.2.1 Microsoft官方下載渠道與版本選擇

💡 提示：該模塊支持Windows Server系列及Windows 10/11專業版以上系統。家庭版若需測試，建議升級至Pro版或使用WSL+nginx替代方案。

安裝包分為兩個版本：
- x64 : 適用於64位Windows系統（推薦）
- x86 : 僅用於特殊場景下的32位應用池兼容

建議優先下載 .msi 格式的獨立安裝程序，避免依賴Web Platform Installer網絡環境不穩定的問題。

2.2.2 安裝過程中的權限與依賴項檢查

安裝前請確認以下條件滿足：

執行安裝命令示例（PowerShell）：

Start-Process msiexec.exe -ArgumentList '/i', 'rewrite_x64.msi', '/quiet', '/norestart' -Wait -Verb RunAs

🔍 參數説明
- /i : 安裝指定MSI包
- /quiet : 靜默安裝，無UI提示
- /norestart : 禁止自動重啓
- -Verb RunAs : 提升至管理員權限執行

安裝完成後無需重啓IIS，但建議執行一次重置以刷新模塊列表：

iisreset /noforce

2.2.3 安裝後驗證模塊是否成功加載

安裝完畢後，可通過以下三種方式驗證模塊狀態：

方法一：查看IIS管理器功能視圖

打開IIS管理器 → 選擇服務器節點 → 雙擊“模塊”圖標 → 查找是否存在 RewriteModule 。

方法二：檢查註冊表項

路徑： HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IIS Extensions\URL Rewrite\Setup
包含鍵值如 InstallPath , Version 等。

方法三：使用命令行查詢

%windir%\system32\inetsrv\appcmd list config -section:globalModules | findstr "rewrite"

預期輸出：

<add name="RewriteModule" image="%SystemRoot%\System32\inetsrv\rewrite.dll" />

若未出現結果，説明模塊未正確註冊，可能原因包括：
- 權限不足導致註冊失敗
- 系統為精簡版（如Core版Server），缺少GUI組件
- 安裝包損壞或版本不匹配

此時應重新卸載並以管理員權限重試安裝。

2.3 IIS管理器中的重寫規則配置界面

IIS管理器提供了一套直觀的圖形化工具來創建和管理URL重寫規則，極大降低了入門門檻。該界面位於“功能視圖”的“URL重寫”圖標下，支持入站規則（Inbound Rules）、出站規則（Outbound Rules）和服務器變量設置。

2.3.1 入站規則、出站規則與條件設置

入站規則是最常用類型，其結構主要包括：
- 匹配URL ：指定輸入路徑的匹配模式（通配符或正則）
- 條件集合 ：可添加多條條件，如檢查服務器變量
- 操作類型 ：重寫（Rewrite）、重定向（Redirect）、自定義響應等
- 日誌記錄 ：開啓後可在FRS日誌中追蹤匹配情況

2.3.2 使用圖形化工具創建基本重寫示例

假設我們要將 /contact 映射到 /default.aspx?page=contact ，步驟如下：

1. 在IIS管理器中選中站點 → 雙擊“URL重寫”
2. 右側點擊“添加規則” → 選擇“空白規則”
3. 填寫字段：
   - 名稱： Contact Page Rewrite - 匹配URL：

• 請求URL： 與模式匹配
• 使用： 正則表達式
• 模式： ^contact$
• 條件：點擊“添加”，輸入：
• 條件輸入： {REQUEST_FILENAME}
• 檢查是否存在文件：否
• 操作：
• 操作類型： 重寫
• 重寫URL： /default.aspx?page=contact
• 附加查詢字符串：勾選

保存後， web.config 將自動生成如下配置：

<system.webServer>
  <rewrite>
    <rules>
      <rule name="Contact Page Rewrite" stopProcessing="true">
        <match url="^contact$" />
        <conditions>
          <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
        </conditions>
        <action type="Rewrite" url="/default.aspx?page=contact" appendQueryString="true" />
      </rule>
    </rules>
  </rewrite>
</system.webServer>

🔎 代碼逐行解讀
- <match url="^contact$"> ：精確匹配路徑 /contact ， ^ 表示開始， $ 表示結束
- <conditions> ：防止真實存在的 contact.html 也被重寫
- negate="true" ：取反，即“如果不是文件則執行”
- appendQueryString="true" ：保留原有查詢參數（如有）

2.3.3 規則執行順序與優先級控制

IIS按規則列表 從上到下 依次執行。一旦某條規則命中且設置了 stopProcessing="true" ，後續規則將不再評估。

可通過拖動排序調整優先級。例如：

<rule name="Home Rule" stopProcessing="true">
  <match url="^$" />
  <action type="Rewrite" url="/default.aspx?page=home" />
</rule>
<rule name="Product Rule" stopProcessing="false">
  <match url="^products/([0-9]+)$" />
  <action type="Rewrite" url="/product.aspx?id={R:1}" />
</rule>

📊 執行邏輯説明
- 訪問 / → 匹配第一條 → 跳轉至 home 頁面 → 終止處理
- 訪問 /products/123 → 第一條不匹配 → 第二條捕獲ID為123 → 重寫但不停止
- 若後面還有規則，將繼續判斷

合理設置 stopProcessing 有助於提升性能，避免不必要的規則遍歷。

2.4 模塊行為調試與日誌記錄

即使規則編寫正確，也可能因路徑衝突、循環重定向等問題導致失敗。為此，IIS提供了強大的調試機制。

2.4.1 啓用Failed Request Tracing跟蹤重寫失敗請求

Failed Request Tracing（FRT）可記錄單個請求的詳細處理軌跡，包含每個模塊的輸入輸出。

啓用步驟：
1. IIS管理器 → 選擇站點 → “失敗請求跟蹤”
2. 點擊“啓用”
3. 添加跟蹤規則：
- 狀態碼範圍： 404
- 跟蹤模塊： RewriteModule
- 日誌位置： %SystemDrive%\inetpub\logs\FailedReqLogFiles

觸發一次 /nonexistent 請求後，查看生成的日誌文件，搜索 REWRITE_ACTION 關鍵字即可看到重寫決策過程。

2.4.2 分析IIS日誌判斷重寫是否生效

IIS默認日誌路徑： C:\inetpub\logs\LogFiles\W3SVC1\

典型日誌條目：

2025-04-05 10:23:45 192.168.1.100 GET /contact - 80 - 192.168.1.1 Mozilla/5.0 200 0 0

注意：
- cs-uri-stem : /contact （原始請求）
- sc-status : 200 （成功）
- 實際處理的是 default.aspx ，但日誌仍顯示原路徑

要確認是否真正重寫，需結合FRT或在 default.aspx.cs 中打印 Request.RawUrl 。

2.4.3 常見錯誤代碼（如404、500）排查方法

示例：防止無限循環

<conditions>
  <add input="{REQUEST_URI}" pattern="/default\.aspx" negate="true" />
</conditions>

此條件確保當前請求不是已經重寫後的目標路徑，避免遞歸調用。

綜上所述，IIS URL重寫模塊的安裝與配置是一項系統工程，涉及底層架構理解、權限管理、規則設計與調試能力。只有在正確的集成模式下安裝官方模塊，並通過科學的方法驗證和優化規則，才能確保無後綴URL系統的穩定運行。下一章將進一步深入 web.config 配置細節，講解如何通過聲明式語法實現複雜路由邏輯。

3. Web.config中定義URL重寫規則與正則表達式匹配

在現代Web開發中，用户體驗和搜索引擎優化（SEO）已成為衡量網站質量的重要指標。傳統的ASP.NET WebForm應用通常依賴於帶有 .aspx 後綴的物理文件路徑暴露在瀏覽器地址欄中，這種做法不僅影響URL的可讀性，也對SEO產生不利影響。為了解決這一問題，通過配置 web.config 文件中的 URL 重寫規則，可以實現將用户請求的“虛擬”無後綴路徑映射到真實的 .aspx 頁面上，而無需更改現有代碼結構。

本章將深入探討如何在 web.config 中使用 <rewrite> 配置節來定義靈活、高效的URL重寫策略。我們將從XML節點結構入手，逐步解析每個關鍵屬性的作用機制，並結合正則表達式進行精確匹配控制。在此基礎上，引入條件判斷邏輯以排除靜態資源干擾，避免無限循環等常見陷阱。最後通過多個實際案例演示如何構建完整的無後綴路由體系，涵蓋主頁、產品頁、用户中心等典型業務場景。

整個過程不依賴第三方組件或複雜中間件，完全基於IIS內置的URL Rewrite模塊與ASP.NET運行時協同工作，確保方案具備良好的兼容性和部署便捷性。理解這些配置原理，是掌握現代化WebForm架構轉型的核心技能之一。

3.1 web.config中rewriteRules節的結構解析

在ASP.NET WebForm項目中， web.config 是應用程序的中央配置文件，它不僅管理數據庫連接字符串、身份驗證模式、編譯選項等常規設置，還可以通過特定節點擴展功能。當啓用IIS URL Rewrite模塊後，系統會識別 <system.webServer><rewrite> 節點，並據此加載並執行用户自定義的重寫規則。該機制允許開發者在不修改代碼的前提下，動態改變HTTP請求的處理路徑。

3.1.1 節點詳解

要啓用URL重寫功能，必須在 web.config 的根級別添加如下結構：

<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <!-- 自定義規則將放在這裏 -->
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

其中：
- <system.webServer> ：這是IIS7及以上版本引入的配置區域，用於存放與IIS直接交互的指令。
- <rewrite> ：啓用URL重寫引擎，其下可包含 <rules> （入站規則）、 <outboundRules> （出站規則）、 <providers> （自定義提供者）等子節點。
- <rules> ：包含一組 <rule> 元素，每條規則獨立定義一個URL轉換邏輯。

該結構位於 web.config 的頂層，優先級高於應用程序代碼，意味着重寫發生在ASP.NET管道早期階段——甚至早於 Application_BeginRequest 事件，因此不會觸發完整頁面生命週期，性能開銷較小。

下面是一個基本的重寫規則示例：

<rule name="Home Page Rewrite" stopProcessing="true">
  <match url="^$" />
  <action type="Rewrite" url="/default.aspx?page=home" />
</rule>

此規則表示：當訪問根路徑 / （即URL為空）時，內部將其重寫為 /default.aspx?page=home ，但瀏覽器地址欄保持不變。

3.1.2 rule元素的關鍵屬性：name、stopProcessing、enabled

每條 <rule> 必須至少包含 name 屬性，其餘屬性可根據需要配置。以下是核心屬性説明：

例如：

<rule name="Product Detail Page" stopProcessing="true" enabled="true">
  <match url="^product/([0-9]+)$" ignoreCase="true" />
  <action type="Rewrite" url="/default.aspx?action=viewProduct&id={R:1}" appendQueryString="true" />
</rule>

這裏 stopProcessing="true" 表示一旦匹配成功，則不再檢查後續規則，防止被其他通配規則覆蓋。這對於高優先級規則（如首頁、登錄頁）非常關鍵。

此外， enabled="false" 可用於灰度測試或多環境切換：

<rule name="Legacy Redirect" enabled="false">
  <match url="^old-page\.html$" />
  <action type="Redirect" url="/news" redirectType="Permanent" />
</rule>

該規則雖然存在，但由於禁用狀態，不會生效，適合上線前預配置。

3.1.3 match url屬性與ignoreCase參數含義

<match> 子節點用於指定URL匹配模式，其主要屬性包括：

• url ：待匹配的URL路徑部分（不含域名和查詢字符串），支持正則表達式。
• ignoreCase ：布爾值，決定是否忽略大小寫，默認為 true 。

示例説明：

<match url="^about$" ignoreCase="true" />

這條規則能同時匹配 /about 和 /ABOUT ，因為 ignoreCase="true" 。若改為 false ，則僅匹配小寫形式。

需要注意的是， url 匹配的是 相對路徑 ，即去除了協議、主機名、端口之後的部分。例如，對於請求 https://www.example.com/contact ， <match url="^contact$"/> 將提取 /contact 進行比對。

此外，URL重寫模塊會在匹配前自動去除查詢字符串（query string），所以你在正則中只需關注路徑本身。如果需要根據查詢參數做判斷，應使用 <conditions> 配合服務器變量完成。

高級用法：錨點與邊界符號

使用 ^ 和 $ 明確開始與結束邊界至關重要。比如：

<match url="^article$" />          <!-- 精確匹配 /article -->
<match url="article" />            <!-- 錯誤！會匹配 /articles、/redirect/article 等 -->

後者因缺少邊界符可能導致意外匹配，造成安全風險或邏輯錯誤。因此建議始終使用 ^...$ 模式進行精確控制。

以下是一個帶流程圖的規則執行順序示意：

graph TD
    A[收到HTTP請求] --> B{是否存在匹配規則?}
    B -->|否| C[繼續原路徑處理]
    B -->|是| D[檢查rule enabled狀態]
    D -->|false| C
    D -->|true| E[執行match匹配]
    E -->|失敗| C
    E -->|成功| F{stopProcessing=true?}
    F -->|是| G[終止規則鏈]
    F -->|否| H[繼續下一規則]
    G --> I[執行action操作]
    H --> I
    I --> J[內部轉發至目標URL]

該流程清晰展示了從請求進入IIS到最終完成重寫的全過程，強調了 enabled 、 match 、 stopProcessing 在決策鏈中的作用。

3.2 正則表達式在URL匹配中的應用

正則表達式（Regular Expression）是URL重寫中最強大的工具之一，能夠實現高度靈活的路徑匹配。在IIS URL Rewrite模塊中，所有 <match url=""> 內容均採用ECMAScript風格的正則語法，支持捕獲組、反向引用、斷言等多種高級特性。

3.2.1 基礎語法：^、$、.*、[]、?等元字符使用

以下是常用元字符及其意義：

實際示例：

<rule name="Match Category Pages">
  <match url="^category/([a-zA-Z]+)$" />
  <action type="Rewrite" url="/default.aspx?cat={R:1}" />
</rule>

解釋：
- ^category/ ：路徑必須以 category/ 開始；
- ([a-zA-Z]+) ：捕獲一個或多個英文字母作為分類名稱；
- $ ：路徑在此結束，防止 /category/news-extra 被誤匹配；
- {R:1} ：引用第一個捕獲組的內容（即括號內的值）。

這樣，訪問 /category/technology 會被重寫為 /default.aspx?cat=technology 。

3.2.2 捕獲組與反向引用（{R:1}）的實際作用

捕獲組（Capturing Group）是正則中用圓括號 () 包裹的部分，可用於提取URL片段並在後續替換中引用。在IIS Rewrite中，使用 {R:n} 格式引用第n個捕獲組（R代表Rule）。

示例：多級路徑映射

<rule name="User Profile Page">
  <match url="^user/([^/]+)/profile$" />
  <action type="Rewrite" url="/default.aspx?action=profile&username={R:1}" />
</rule>

分析：
- ([^/]+) ：匹配非斜槓字符的一個或多個，即用户名；
- {R:1} ：將捕獲的用户名插入到目標URL中；
- 若訪問 /user/john/profile ，則重寫為 /default.aspx?action=profile&username=john 。

這種方式極大提升了動態路由能力，無需為每個用户創建單獨頁面。

⚠️ 注意： {R:0} 表示整個匹配的原始URL， {R:1} 第一個捕獲組，依此類推。

3.2.3 示例：將“/home”匹配並映射到“/default.aspx?page=home”

現在我們構建一個完整的規則，實現將 /home 映射到後台處理頁：

<rule name="Home Route" stopProcessing="true">
  <match url="^home$" ignoreCase="true" />
  <action type="Rewrite" url="/default.aspx?page=home" appendQueryString="true" />
</rule>

參數説明：

• name="Home Route" ：規則名稱，用於日誌追蹤；
• stopProcessing="true" ：阻止後續規則干擾；
• url="^home$" ：精確匹配 /home ；
• ignoreCase="true" ：兼容 /HOME 、 /Home 等變體；
• action type="Rewrite" ：內部重寫而非跳轉；
• appendQueryString="true" ：保留原有查詢參數，如 /home?ref=nav → /default.aspx?page=home&ref=nav

執行邏輯逐行解讀：

1. 用户請求 https://yoursite.com/home
2. IIS接收請求，URL Rewrite模塊介入；
3. 遍歷所有規則，發現 Home Route 匹配成功；
4. 提取 {R:0} = “home”，無捕獲組；
5. 構造新路徑： /default.aspx?page=home ，並附加原查詢字符串（如有）；
6. 內部將請求轉發至該路徑，頁面正常響應；
7. 瀏覽器地址欄仍顯示 /home ，實現偽靜態效果。

該技術廣泛應用於企業門户、內容管理系統（CMS）中，顯著提升URL語義化程度。

3.3 條件限制與服務器變量檢查

儘管正則表達式提供了強大的匹配能力，但在真實環境中，我們必須謹慎處理靜態資源（如CSS、JS、圖片）的請求，避免它們被錯誤地重寫到 .aspx 頁面，導致資源加載失敗或性能下降。

3.3.1 使用 排除靜態資源干擾

<conditions> 元素允許我們在執行重寫前添加前置判斷條件，常用於過濾特定類型的請求。

<rule name="Dynamic Pages Only" stopProcessing="true">
  <match url="^(.*)$" />
  <conditions>
    <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
    <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
  </conditions>
  <action type="Rewrite" url="/default.aspx?page={R:1}" />
</rule>

上述規則含義：
- 只有當請求的路徑 不是真實存在的文件 且 不是目錄 時，才執行重寫；
- {REQUEST_FILENAME} 是IIS提供的服務器變量，表示映射後的物理路徑；
- negate="true" 表示取反，即“不是文件”且“不是目錄”。

這確保了 /css/site.css 、 /images/logo.png 等靜態資源可直接由IIS返回，繞過ASP.NET處理，提高效率。

3.3.2 判斷REQUEST_FILENAME是否存在物理文件

我們可以進一步細化條件，僅對某些目錄下的請求進行保護：

<conditions>
  <add input="{URL}" pattern="^/(css|js|images)/" negate="true" />
</conditions>

此條件表示：如果URL以 /css/ 、 /js/ 或 /images/ 開頭，則不執行重寫，適用於那些未使用磁盤文件但路徑命名類似的虛擬接口。

另一種常見模式是結合 HTTP_HOST 變量實現多租户路由：

<conditions>
  <add input="{HTTP_HOST}" pattern="^shop\.(.+)$" />
</add>
</conditions>
<action type="Rewrite" url="/tenant.aspx?domain={C:1}" />

此處 {C:1} 引用了條件中的捕獲組（C代表Condition），實現基於子域名的商户分發。

3.3.3 防止無限循環的邏輯設計

由於重寫是“內部轉發”，目標頁面仍可能再次觸發相同的規則，導致無限遞歸。例如：

<rule name="Catch All">
  <match url=".*" />
  <action type="Rewrite" url="/default.aspx" />
</rule>

若未加限制， /default.aspx 請求也會被匹配，進而再次重寫到自身，形成死循環。

解決方法是在條件中排除目標路徑：

<conditions>
  <add input="{URL}" pattern="^/default\.aspx$" negate="true" />
</conditions>

或者更嚴謹地：

<conditions>
  <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
  <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
  <add input="{URL}" pattern="\.(axd|aspx|ashx|ico|png|jpg|css|js)$" negate="true" />
</conditions>

該組合條件確保只有非物理文件、非目錄、且非靜態資源擴展名的請求才會進入重寫流程。

完整防循環規則表：

graph LR
    Start[開始處理請求] --> IsStatic{是否為靜態資源?}
    IsStatic -- 是 --> ServeByIIS[由IIS直接服務]
    IsStatic -- 否 --> IsMatched{是否有匹配規則?}
    IsMatched -- 否 --> DefaultFlow[默認處理]
    IsMatched -- 是 --> CheckLoop{是否指向目標頁?}
    CheckLoop -- 是 --> Abort[終止，防循環]
    CheckLoop -- 否 --> Rewrite[執行重寫]
    Rewrite --> End[完成響應]

該流程圖體現了防禦性編程思想，在追求靈活性的同時保障系統穩定性。

3.4 實戰：配置多個無後綴URL重寫規則

為了展示完整應用場景，我們現在構建一個典型的WebForm站點所需的全部重寫規則集。

3.4.1 設置主頁、產品頁、用户中心等虛擬路徑

假設我們只有一個入口頁面 default.aspx ，但希望通過不同URL展示不同內容：

<rules>
  <!-- 主頁 -->
  <rule name="Home Page" stopProcessing="true">
    <match url="^$" />
    <action type="Rewrite" url="/default.aspx?page=home" />
  </rule>

  <!-- 關於我們 -->
  <rule name="About Us" stopProcessing="true">
    <match url="^about$" />
    <action type="Rewrite" url="/default.aspx?page=about" />
  </rule>

  <!-- 產品列表 -->
  <rule name="Product List" stopProcessing="true">
    <match url="^products$" />
    <action type="Rewrite" url="/default.aspx?page=products" />
  </rule>

  <!-- 產品詳情（帶ID）-->
  <rule name="Product Detail" stopProcessing="true">
    <match url="^product/(\d+)$" />
    <action type="Rewrite" url="/default.aspx?page=product&id={R:1}" />
  </rule>

  <!-- 用户中心 -->
  <rule name="User Dashboard" stopProcessing="true">
    <match url="^user/([^/]+)$" />
    <action type="Rewrite" url="/default.aspx?page=user&name={R:1}" />
  </rule>
</rules>

3.4.2 動態參數提取與QueryString傳遞

所有規則均利用 {R:1} 提取動態段落，並通過 appendQueryString="true" （默認開啓）保留原始查詢參數。例如：

訪問： /product/123?source=ad
重寫為： /default.aspx?page=product&id=123&source=ad

在 default.aspx.cs 中可通過：

string id = Request.QueryString["id"];
string page = Request.QueryString["page"];

獲取數據並渲染對應內容。

3.4.3 測試不同URL模式下的重寫效果

建議使用以下方式驗證：

1. 瀏覽器訪問 ：手動輸入 /about 查看是否正確顯示；
2. F12開發者工具 ：檢查Network面板中請求路徑與狀態碼；
3. Failed Request Tracing ：啓用FRT跟蹤5xx錯誤；
4. 編寫單元測試腳本 ：

Invoke-WebRequest -Uri "http://localhost/home"
Invoke-WebRequest -Uri "http://localhost/product/456"

預期結果：所有請求均返回200，且內容正確，服務器日誌記錄重寫動作。

通過以上配置，我們實現了真正的“無後綴URL”架構，既保留了WebForm的開發便利性，又達到了現代Web應用的標準體驗。

4. 基於Routing機制的內部請求映射實現

在現代Web開發中，URL的設計不再僅僅是技術路徑的體現，更成為用户體驗、搜索引擎優化（SEO）和系統可維護性的重要組成部分。傳統的ASP.NET WebForm雖然以事件驅動和服務器控件為核心優勢，但其默認暴露 .aspx 後綴的URL結構已難以滿足當前對簡潔、語義化路由的需求。為此，ASP.NET引入了 Routing框架 ，允許開發者通過編程方式定義清晰、可讀性強的URL模式，並將這些虛擬路徑映射到具體的物理頁面或處理邏輯上。

與IIS層級的URL重寫不同，Routing是一種 應用層的請求分發機制 ，它運行在ASP.NET HTTP管道中，能夠更加靈活地控制請求的解析與轉發過程。本章將深入探討如何利用ASP.NET Routing框架實現無 .aspx 後綴的內部請求映射，涵蓋從核心組件原理到實際編碼落地的完整流程。

4.1 ASP.NET Routing框架概述

Routing是ASP.NET平台為支持RESTful風格URL設計而引入的核心功能之一，最早隨ASP.NET MVC一同推出，隨後也被整合進WebForm項目中。其核心目標是打破“URL必須對應物理文件”的傳統限制，使開發者可以自由定義用户訪問地址與後台資源之間的映射關係。

4.1.1 RouteTable與RouteCollection的基本職責

在ASP.NET中，所有註冊的路由規則都存儲在一個全局靜態對象 RouteTable.Routes 中，該對象的類型為 RouteCollection 。這個集合本質上是一個有序列表，保存着多個 Route 或 PageRoute 實例，每個實例代表一條URL匹配規則。

當應用程序啓動時（通常在 Application_Start 事件中），開發者會向 RouteTable.Routes 添加自定義路由。這些路由按照添加順序進行匹配，一旦某條規則成功匹配當前請求的URL，則後續規則將不再執行（除非顯式設置允許繼續）。

public static class RouteTable
{
    public static RouteCollection Routes { get; }
}

RouteCollection 提供了多種添加路由的方法，例如：
- MapPageRoute() ：專用於WebForm頁面映射；
- Add() ：手動添加 Route 對象；
- 擴展方法如 MapRoute() （MVC中常用）；

每條路由包含以下關鍵信息：
- URL模板 ：如 "product/{id}" ；
- 目標物理文件路徑 ：如 "~/Product.aspx" ；
- 默認值 ：當URL中缺少參數時使用的默認值；
- 約束條件 ：正則表達式或其他驗證邏輯，用於限定參數格式；

這種集中式的路由管理機制使得整個應用的URL結構變得高度可控且易於維護。

4.1.2 UrlRoutingModule如何攔截請求

ASP.NET Routing的運行依賴於一個關鍵的HTTP模塊—— UrlRoutingModule ，它是 System.Web.Routing 命名空間下的核心類，繼承自 IHttpModule 接口。

請求攔截流程圖（Mermaid）

graph TD
    A[HTTP請求到達] --> B{是否啓用Routing?}
    B -- 是 --> C[UrlRoutingModule捕獲請求]
    C --> D[遍歷RouteTable.Routes]
    D --> E{找到匹配的Route嗎？}
    E -- 否 --> F[繼續原生IIS處理流程]
    E -- 是 --> G[創建RequestContext]
    G --> H[調用RouteHandler]
    H --> I[生成 IHttpHandler]
    I --> J[執行目標頁面處理邏輯]

UrlRoutingModule 在ASP.NET請求管道的早期階段介入（ PostResolveRequestCache 階段），檢查當前請求是否能被任何已註冊的路由匹配。如果匹配成功，它不會讓IIS去查找物理文件，而是動態生成一個 RequestContext 並交由對應的 IRouteHandler 處理。

對於WebForm場景，默認的路由處理器是 PageRouteHandler ，它負責將虛擬路徑綁定到指定的 .aspx 頁面，並返回一個包裝後的 IHttpHandler 實例來執行該頁面的生命週期。

4.1.3 Routing與URL Rewrite的本質區別

儘管兩者都能實現“隱藏 .aspx 後綴”的效果，但它們在工作層次、執行時機和實現機制上有顯著差異：

⚠️ 注意：由於Rewrite發生在IIS層面，因此即使目標文件不存在也不會觸發ASP.NET錯誤頁；而Routing若未正確配置，可能導致404錯誤由ASP.NET拋出。

選擇建議：
- 若追求極致性能且路由規則固定，推薦使用 IIS URL Rewrite ；
- 若需要動態路由、參數約束、與業務邏輯深度集成，應優先採用 ASP.NET Routing ；

4.2 Application_Start中註冊自定義路由

要在WebForm項目中啓用Routing功能，必須在應用程序啓動時完成路由註冊。這一任務通常在 Global.asax 文件的 Application_Start 事件中完成。

4.2.1 Global.asax文件的作用與生命週期事件

Global.asax 是ASP.NET應用程序的全局應用程序類，繼承自 HttpApplication 。它提供了一系列可用於監聽應用級事件的回調方法，其中最重要的是：

• Application_Start ：在整個應用域第一次加載時執行，僅一次；
• Application_End ：應用關閉時調用；
• Session_Start / Session_End ：會話級事件；
• Application_Error ：全局異常捕獲；

void Application_Start(object sender, EventArgs e)
{
    // 在此處註冊路由
    RegisterRoutes(RouteTable.Routes);
}

此方法是註冊路由的最佳位置，因為此時 RouteTable.Routes 已初始化，且整個應用尚未開始接收請求，保證了線程安全。

4.2.2 引用System.Web.Routing命名空間

要使用Routing API，必須確保項目引用了正確的程序集並導入命名空間：

<compilation debug="true" targetFramework="4.8">
  <assemblies>
    <add assembly="System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
  </assemblies>
</compilation>

同時，在 Global.asax.cs 中添加：

using System.Web.Routing;

如果沒有正確引用，編譯器將無法識別 RouteTable 、 MapPageRoute 等類型。

4.2.3 調用RouteTable.Routes.MapPageRoute方法

MapPageRoute 是專門為WebForm設計的擴展方法，用於快速將一個URL模板映射到具體 .aspx 頁面。

示例代碼：

void Application_Start(object sender, EventArgs e)
{
    RegisterRoutes(RouteTable.Routes);
}

private void RegisterRoutes(RouteCollection routes)
{
    routes.MapPageRoute(
        routeName: "HomePage",
        routeUrl: "home",
        physicalFile: "~/Default.aspx"
    );

    routes.MapPageRoute(
        routeName: "ProductDetail",
        routeUrl: "product/{id}",
        physicalFile: "~/Product.aspx",
        defaults: new RouteValueDictionary { { "id", "1" } },
        constraints: new RouteValueDictionary { { "id", @"\d+" } }
    );
}

🔍 代碼逐行解析：

✅ 成功註冊後，訪問 /home 將實際執行 Default.aspx 頁面邏輯，而瀏覽器地址欄仍顯示 /home ，實現真正的“偽靜態”。

4.3 MapPageRoute參數詳解與路由模板設計

為了構建健壯、可擴展的路由系統，必須深入理解 MapPageRoute 方法的各個參數及其應用場景。

4.3.1 routeName、routeUrl、physicalFile參數説明

這三個是最基礎也是必填的參數：

示例對比：

// 正確寫法
routes.MapPageRoute("News", "news/{year}/{month}", "~/Pages/NewsList.aspx");

// 錯誤寫法（路徑未以~開頭）
routes.MapPageRoute("Error", "error", "/Error.aspx"); // ❌ 可能導致找不到資源

4.3.2 支持帶參數的路由如“{category}/{id}”

動態參數是Routing的核心能力之一。通過花括號 {} 定義佔位符，可以在運行時提取URL中的變量並傳遞給目標頁面。

示例：產品分類詳情頁

routes.MapPageRoute(
    "CategoryItem",
    "{category}/{id}",
    "~/ProductDetails.aspx",
    defaults: new RouteValueDictionary(new { category = "default", id = "0" }),
    constraints: new RouteValueDictionary {
        { "id", @"\d{1,6}" },           // ID為1-6位數字
        { "category", @"^[a-z]+$" }     // 分類名為小寫字母
    }
);

在 ProductDetails.aspx.cs 中獲取參數：

protected void Page_Load(object sender, EventArgs e)
{
    var category = Page.RouteData.Values["category"] as string;
    var id = Page.RouteData.Values["id"] as string;

    lblInfo.Text = $"類別：{category}，編號：{id}";
}

📌 Page.RouteData.Values 是WebForm中獲取路由參數的標準方式，替代了傳統的 QueryString 。

4.3.3 默認值與約束（constraints）的應用

（1）默認值（defaults）

用於為缺失的參數提供 fallback 值，提升用户體驗：

defaults: new { page = "1", sort = "asc" }

若用户訪問 /list ，等價於 /list?page=1&sort=asc 。

（2）約束（constraints）

防止惡意輸入或無效請求進入處理邏輯，提高安全性：

表格：常見約束正則表達式參考

使用約束不僅能提升安全性，還能避免數據庫查詢異常或類型轉換錯誤。

4.4 Global.asax.cs中實現完整路由初始化

為了提升代碼可維護性和可測試性，應將路由註冊邏輯封裝成獨立方法，並在 Application_Start 中調用。

4.4.1 編寫RegisterRoutes輔助方法組織代碼結構

良好的代碼組織習慣包括：
- 將路由註冊分離為獨立方法；
- 按模塊分組註冊（如用户、商品、訂單）；
- 添加註釋説明每條路由用途；

private void RegisterRoutes(RouteCollection routes)
{
    // 主頁路由
    routes.MapPageRoute("Home", "", "~/Default.aspx");
    routes.MapPageRoute("About", "about", "~/About.aspx");

    // 產品模塊
    routes.MapPageRoute("ProductList", "products", "~/Products.aspx");
    routes.MapPageRoute("ProductView", "product/{id}", "~/Product.aspx",
        defaults: new { id = "1" },
        constraints: new { id = @"\d+" });

    // 新聞模塊
    routes.MapPageRoute("NewsItem", "news/{year}/{slug}", "~/NewsDetail.aspx",
        constraints: new {
            year = @"\d{4}",
            slug = @"[\w\-]+"
        });
}

這種方式便於後期擴展，也利於團隊協作。

4.4.2 在Application_Start中調用路由註冊函數

void Application_Start(object sender, EventArgs e)
{
    try
    {
        RegisterRoutes(RouteTable.Routes);
        Application["AppStartedAt"] = DateTime.Now;
    }
    catch (Exception ex)
    {
        // 記錄日誌
        System.Diagnostics.EventLog.WriteEntry("ASP.NET", ex.Message, EventLogEntryType.Error);
    }
}

注意： Application_Start 中不應有耗時操作，否則會影響首次訪問性能。

4.4.3 路由調試技巧：查看當前註冊的所有路由

在開發階段，可通過輸出所有已註冊路由來驗證配置是否正確：

// 在任意頁面中加入以下代碼（如Page_Load）
foreach (var route in RouteTable.Routes)
{
    if (route is Route r)
    {
        Response.Write($"Name: {r.RouteName}<br/>");
        Response.Write($"Url: {r.Url}<br/>");
        Response.Write($"Defaults: {r.Defaults}<br/>");
        Response.Write($"Constraints: {r.Constraints}<hr/>");
    }
}

或者使用第三方工具如 Glimpse 或 MiniProfiler 可視化查看路由表。

綜上所述，ASP.NET Routing提供了一種強大且靈活的方式，實現無 .aspx 後綴的URL訪問。相比IIS級別的重寫，它具備更強的編程能力和上下文感知能力，尤其適合需要動態參數、權限控制、多租户等複雜場景的應用系統。合理設計路由結構不僅能提升SEO表現，也為未來遷移到ASP.NET MVC或Core奠定良好基礎。

5. 無.aspx後綴的URL訪問實戰與完整源碼解析

5.1 Default.aspx接收QueryString參數的實現

在基於URL重寫或ASP.NET Routing機制的無後綴架構中， Default.aspx 通常作為前端控制器（Front Controller），負責根據傳入的路由參數動態分發請求。其核心邏輯依賴於 Request.QueryString 獲取由重寫規則或路由系統注入的查詢字符串。

例如，在使用IIS URL Rewrite模塊時，可將 /products/1001 重寫為 /Default.aspx?page=products&id=1001 ，此時 Default.aspx 需從 QueryString["page"] 和 QueryString["id"] 中提取信息：

// Default.aspx.cs
protected void Page_Load(object sender, EventArgs e)
{
    string page = Request.QueryString["page"];
    string id = Request.QueryString["id"];

    if (string.IsNullOrEmpty(page))
    {
        Response.StatusCode = 404;
        Server.Transfer("/404.aspx");
        return;
    }

    // 動態加載內容模板
    switch (page.ToLower())
    {
        case "home":
            LoadHome();
            break;
        case "products":
            LoadProduct(id);
            break;
        case "user":
            LoadUserProfile(id);
            break;
        default:
            Response.StatusCode = 404;
            Server.Transfer("/404.aspx");
            break;
    }
}

上述代碼展示瞭如何通過 QueryString 實現內容分發。值得注意的是，ViewState 和 PostBack 機制仍然有效，因為最終處理頁面仍是 .aspx 物理文件。但需注意：若 URL 路徑被頻繁重寫，可能導致 form action 指向錯誤路徑。為此，建議在 Page_PreInit 中設置 Form.Action ：

protected void Page_PreInit(object sender, EventArgs e)
{
    // 保持表單提交到當前“虛擬”路徑
    this.Form.Action = Request.RawUrl;
}

此外，若使用Routing方式，則可通過 Page.RouteData.Values["paramName"] 直接獲取路由參數，避免對QueryString的強依賴。

該機制確保了傳統WebForm組件模型的完整性，同時兼容現代URL設計規範。

5.2 Page_Load中實現內容分發邏輯

在 Page_Load 中實現的內容分發邏輯是整個無後綴架構的核心調度層。它不僅決定渲染哪部分內容，還需考慮用户體驗、性能及異常處理。

以下是一個增強型分發邏輯示例，結合了 UserControl 實現模塊化組裝：

protected void Page_Load(object sender, EventArgs e)
{
    string route = Request.QueryString["route"] ?? "home";
    string[] parts = route.Split('/');
    string module = parts[0];
    string param1 = parts.Length > 1 ? parts[1] : null;
    string param2 = parts.Length > 2 ? parts[2] : null;

    PlaceHolderMain.Controls.Clear();

    switch (module)
    {
        case "home":
            LoadUserControl("HomeControl.ascx");
            break;
        case "news":
            var newsControl = LoadUserControl("NewsList.ascx") as NewsList;
            newsControl?.SetCategory(param1);
            break;
        case "profile":
            var profileCtrl = LoadUserControl("UserProfile.ascx") as UserProfile;
            if (!string.IsNullOrEmpty(param1))
                profileCtrl?.LoadById(int.Parse(param1));
            else
                Response.Redirect("/404");
            break;
        case "admin":
            if (!User.IsInRole("Admin"))
            {
                Response.StatusCode = 403;
                Server.Transfer("/error.aspx?code=403");
            }
            LoadUserControl("AdminDashboard.ascx");
            break;
        default:
            Handle404();
            break;
    }
}

private UserControl LoadUserControl(string ascxPath)
{
    if (Context == null) return null;
    var control = LoadControl(ascxPath);
    PlaceHolderMain.Controls.Add(control);
    return control;
}

private void Handle404()
{
    Response.Status = "404 Not Found";
    Response.StatusCode = 404;
    Response.TrySkipIisCustomErrors = true;
    Server.Transfer("~/404.aspx");
}

此邏輯具備以下特性：
- 支持多級路徑解析（如 /news/sports/10 ）
- 使用 PlaceHolder 動態插入 UserControl
- 支持權限校驗與安全跳轉
- 正確設置HTTP狀態碼以利於SEO
- 可擴展性強，易於維護

graph TD
    A[收到無後綴請求] --> B{是否匹配路由?}
    B -->|是| C[調用Default.aspx]
    C --> D[解析QueryString或RouteData]
    D --> E[執行Page_Load分發]
    E --> F{模塊是否存在?}
    F -->|是| G[加載對應UserControl]
    F -->|否| H[返回404]
    G --> I[渲染響應]
    H --> I
    I --> J[輸出HTML]

這種結構清晰地分離了路由調度與業務呈現，提升了系統的可維護性。

5.3 兩種方式對比：Rewrite vs Routing

從技術本質看， URL Rewrite 是“偽裝” ——外部URL改變而內部仍指向原頁面； Routing 是“映射” ——建立邏輯路徑與處理程序之間的關係。對於以內容展示為主的靜態型網站（如企業官網），推薦使用 IIS Rewrite ，因其高效且無需修改應用邏輯；而對於功能複雜、需精細控制路由約束的動態系統（如CMS、ERP），應優先採用 Routing 機制。

5.4 完整源碼解析與項目部署流程

5.4.1 Visual Studio項目結構説明

一個典型的可運行項目結構如下：

/WebFormNoExtension
│
├── /App_Code
│   └── Utilities.cs
├── /Controls
│   ├── HomeControl.ascx
│   ├── NewsList.ascx
│   └── UserProfile.ascx
├── /bin
│   └── *.dll
├── Default.aspx
├── Default.aspx.cs
├── Global.asax
├── Global.asax.cs
├── web.config
└── 404.aspx

5.4.2 關鍵文件清單

1. web.config —— 包含URL Rewrite規則：

<system.webServer>
  <rewrite>
    <rules>
      <rule name="RouteRequests" stopProcessing="true">
        <match url="^home$" />
        <action type="Rewrite" url="/Default.aspx?page=home" />
      </rule>
      <rule name="ProductRoute" stopProcessing="true">
        <match url="^products/([0-9]+)$" />
        <action type="Rewrite" url="/Default.aspx?page=products&id={R:1}" />
      </rule>
    </rules>
  </rewrite>
</system.webServer>

2. Global.asax.cs —— 若使用Routing：

void Application_Start(object sender, EventArgs e)
{
    RegisterRoutes(RouteTable.Routes);
}

void RegisterRoutes(RouteCollection routes)
{
    routes.MapPageRoute("Home", "home", "~/Default.aspx");
    routes.MapPageRoute("Product", "products/{id}", "~/Default.aspx");
}

3. Default.aspx.cs —— 核心分發邏輯，已如前述實現。

5.4.3 部署注意事項

• IIS模塊依賴 ：生產環境必須安裝 URL Rewrite Module 2.1
• Application Pool模式 ：建議使用“集成模式”，否則Rewrite可能不生效
• 權限配置 ：確保IIS_IUSRS對網站目錄有讀取權限
• 緩存策略 ：對靜態內容啓用輸出緩存，避免每次重寫都進入ASP.NET管線
• Gzip壓縮 ：開啓 dynamicCompression 提升傳輸效率
• 日誌監控 ：啓用FRT（Failed Request Tracing）便於排查重寫失敗
• HTTPS適配 ：在rewrite規則中添加協議判斷，防止混合內容警告

<conditions>
  <add input="{HTTPS}" pattern="^OFF$" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent" />

上述配置確保系統在高併發場景下依然穩定運行，並具備良好的可觀測性與安全性基礎。