.htaccess 語法檢查工具
貼上 .htaccess 檔案內容，即可立即發現常見錯誤：區塊標籤未閉合、指令名稱拼寫錯誤、RewriteRule 引數不足、以及缺少對應規則的孤立 RewriteCond。
使用提示
- 本工具是基於逐行規則的啟發式靜態檢查，並非真正的 Apache 解析器。部署前請務必在真實伺服器或預釋出環境中測試。
- 如果你能訪問 Apache 伺服器的命令列，
apachectl configtest是最權威的語法檢查方式。本工具適合在無法使用該命令的共享主機環境中做初步檢查。 - "未識別指令"的警告只是基於固定白名單的低置信度推測。如果你使用了較冷門模組的指令，出現該警告也不一定代表寫法有誤。
- 連續書寫多行 RewriteCond 是常見寫法（相當於 AND 條件的疊加）。本工具只會在連續 RewriteCond 的最後一行之後沒有 RewriteRule 時才發出警告。
- 上線到生產環境前，建議分批小幅應用改動並逐步驗證，而不是一次性替換整份檔案。
常見問題
最常見的原因是 Apache 主配置中該目錄被設定為
AllowOverride None，導致 .htaccess 被完全忽略。請讓伺服器管理員確認已啟用 AllowOverride All（或至少你所需要的具體項，例如 AuthConfig、FileInfo）。同時也請檢查是否存在瀏覽器或 CDN 快取導致看到的是舊內容。基本形式是
RewriteRule 匹配模式 替換目標 [標誌]。匹配模式是一個正規表示式，用於匹配請求的 URL 路徑（不含開頭的斜槓），替換目標可以通過 $1、$2 等引用匹配模式中的括號分組。標誌寫在方括號內並用逗號分隔，例如 [L]（停止處理後續規則）或 [R=301]（永久重定向）。一個常見原因是重寫後的 URL 再次匹配了同一條 RewriteRule 的模式，導致 Apache 反覆重寫。標準做法是加上類似
%{REQUEST_FILENAME} !-f 的 RewriteCond（僅當路徑尚未對應一個已存在的檔案時才生效），這樣目標一旦真實存在，規則就不會再繼續觸發。在大多數共享主機環境下，該目錄下的所有頁面都會開始返回"500 Internal Server Error"。如果你能檢視伺服器的錯誤日誌，那是定位具體出錯行和原因最快的方法。
不能保證。本工具只是基於逐行正則的啟發式靜態檢查，並不能完全還原真實 Apache 解析器的行為。所需模組（如 mod_rewrite）是否已載入、某條指令在當前上下文中是否被允許，都取決於具體的伺服器環境，因此在正式依賴結果之前，請務必在預釋出環境或真實伺服器上進行驗證。
閒話 ― 為什麼叫做".htaccess"
".htaccess" 這個名字是"hypertext access"（超文本訪問）的縮寫，其歷史可以追溯到 1995 年前後 NCSA httpd 及早期 Apache 版本。最初它被引入是為了讓目錄的所有者能夠為自己管轄的空間設定密碼保護（Basic 認證），而無需觸碰只有伺服器管理員才能編輯的全域性配置檔案（httpd.conf）。
".htaccess" 之所以強大，是因為只要 Apache 管理員通過 AllowOverride 指令允許，使用者通過 FTP 或檔案管理器上傳檔案後配置即刻生效，無需重啟伺服器。這讓共享主機上通常無法訪問主配置檔案的使用者，也能夠按目錄精細控制重定向、快取策略和訪問限制。
不過這種便利也是有代價的。Apache 官方文件明確建議：只要有許可權訪問伺服器主配置檔案，就應該把指令寫在那裡而不是 .htaccess 中。原因很簡單——Apache 在處理每一次請求時，都要沿著目錄樹向上查詢並重新讀取所有的 .htaccess 檔案，這帶來的效能開銷遠比寫在主配置檔案中要大。
一處細微的語法錯誤也可能造成不小的麻煩：在許多共享主機環境下，無效的 .htaccess 會導致該目錄下所有頁面變成一片空白的"500 Internal Server Error"，定位具體原因往往要耗費不少時間。除了仔細通讀程式碼，藉助這類靜態檢查工具也能在上線前提前發現粗心導致的錯誤。