Apache Rewrite 模塊 vs 404 錯誤頁面偽靜態實現差異深度對比

動態網站偽靜態實現主流有兩條技術路線：Apache mod_rewrite (Rewrite) 與 404 錯誤頁面捕獲 (ErrorDocument 404)。兩者原理不同，適用場景各異，本文從資源消耗、參數傳遞、SEO 友好、規則靈活性四個維度深度對比。

核心原理對比

四大關鍵差異詳析

1. 資源消耗與性能

• 404 方案：不載入 mod_rewrite，節省模組初始化內存、正則編譯 CPU。大流量站點 (日 PV 百萬級) 可減少 5-10% Apache 進程內存佔用
• Rewrite 方案：每請求經過正則匹配引擎，複雜規則集 (超過 50 條) 明顯增加 CPU 開銷
• 結論：極致性能敏感場景 (靜態化門戶、CDN 邊緣節點) 優先 404 方案

2. 參數傳遞能力 (GET/POST)

• Rewrite：完美支持 QUERY_STRING 透傳 (QSA 旗標)、POST 數據體保持。RewriteRule ^(.*)$ index.php?$1 [L,QSA] 可獲取 $_GET/$_POST
• 404 方案：原生不支持 GET/POST 參數透傳。請求 /305.php?name=value 觸發 404 進入處理器時，$_GET['name'] 為空；表單 POST 到 404 生成頁面同樣無法接收數據
• 變通方案：404 處理器中解析 $_SERVER['REQUEST_URI'] 手動提取參數，但 POST 體需讀取 php://input 且易丟失
• 結論：需處理表單提交、API 參數、RESTful 查詢字符串的應用 必須用 Rewrite

3. HTTP 狀態碼與 SEO 收錄

• 404 方案：默認返回 404 Not Found，搜索引擎判定為死鏈不收錄。必須在處理器開頭輸出：

  <?php header("HTTP/1.1 200 OK"); ?>  (Apache 1.x/2.0)
  <?php header("Status: 200 OK"); ?>     (Apache 2.2+ / FastCGI)

  不同主機商/Apache 版本需實測調整，否則導致大量頁面不被收錄
• Rewrite 方案：內部重寫默認返回 200 OK，無需額外處理，天然 SEO 友好
• 驗證工具：站長工具「HTTP 狀態碼查詢」/「404 檢測」批量驗證

4. 規則靈活性與維護成本

• 404 方案：單一入口處理器 (index.php) 解析 REQUEST_URI 分發，一套代碼覆蓋所有 URL 模式。新增頁面類型只需修改 PHP 路由邏輯，無需修改 Apache 配置
• Rewrite 方案：每種 URL 模式需編寫獨立 RewriteRule。如 /305.html、/305-1.html、/305-2.html 需 3 條規則。規模增長導致 .htaccess/httpd.conf 膨脹、維護困難
• 結論：URL 模式多樣、頻繁變更、由開發人員維護路由邏輯的項目，404 方案維護成本更低

綜合選型建議

現代最佳實踐：前端控制器模式 (Front Controller)

現代框架 (Laravel/Symfony/ThinkPHP/Yii) 均採用 Rewrite 將所有請求路由至單一入口 public/index.php，由框架路由組件解析 REQUEST_URI 分發。結合了 Rewrite 的標準化、參數透傳、SEO 友好與 404 方案的單一入口靈活性。

# Laravel 標準 .htaccess
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [L]

純 404 方案屬於「歷史巧技」，現代生產環境強烈建議使用 Rewrite + 前端控制器。僅在極端性能敏感、無框架、純靜態化、開發團隊熟悉 404 路由模式的舊專案中考慮保留。