您现在的位置：程式碼之家 >> 編程語言 > >> 網頁程式設計 >> PHP 程式設計 >> PHP 相關知識

正則表達式最佳實踐：五大習慣讓你的 Regex 更易讀、好維護

編輯：PHP 相關知識

前言：為什麼正則表達式總是寫時爽、改時痛？

正則表達式（Regex）是開發者工具箱中威力強大卻又最易變成「寫時只懂自己，改時連自己都不懂」的利器。它難寫、難讀、難維護，稍有不慎就會錯配預期外的文本，或漏掉本該匹配的內容。問題的核心在於：每個元字符的能力與細微差異組合在一起，使得代碼若不借助高強度腦力解讀，幾乎無法理解其真實意圖。

雖然市面上有不少輔助工具能讓編寫與閱讀 Regex 變得容易些，但它們往往不符合程式設計師的直覺習慣。對許多開發者而言，寫 Regex 彷彿是在施展「黑魔法」，只能憑藉經驗與樂觀態度硬闖。但如果你願意養成本文探討的五個好習慣，你設計的正則表達式將能經得起反覆測試與時間考驗。本文將以 Perl、PHP、Python 為示範語言，但建議幾乎適用於所有支援正則表達式的環境。

習慣一：善用空白與註釋，讓 Regex 呼吸

幾乎沒有程式設計師會把業務邏輯代碼擠在一行裡，因為大家都知道這樣難以閱讀、維護。但偏偏到了正則表達式這裡，許多人就忘記了這項鐵律。其實，主流 Regex 引擎（Perl、PHP、Python 等）都支援「擴展空白模式」，允許將模式拆分為多行，並在行尾添加註釋。Perl 6 甚至預設啟用此模式。

關鍵在於：啟用擴展模式後，引擎會忽略模式中的空白字符。若需匹配字面空白，必須顯式聲明（如 \s 或）。

語法啟用對照表

Perl：在分隔符後加 x，如 m/foo bar/x
PHP：同樣在結尾加 x，如 "/foo bar/x"
Python：傳遞 re.VERBOSE 旗標給 re.compile()

實戰對比：美國電話號碼匹配

單行版（難以察覺缺陷）：

(?\d{3})? ?\d{3}[-.]\d{4}

這行代碼能匹配 (314)555-4000，但你能一眼看出它不匹配 314-555-4000（缺區號分隔符）也不匹配 555-4000（無區號）嗎？缺陷藏在緊湊的語法裡。

多行註釋版（缺陷暴露無遺，易於修正）：

/
(?          # 可選左括號
  \d{3}     # 必須的區號
)?          # 可選右括號
[-\s.]?     # 分隔符：破折號、空白或句點
\d{3}       # 三位前綴
[-.]        # 另一分隔符
\d{4}       # 四位號碼
/x

現在清晰可見：區號後缺少可選分隔符。修復只需在 )? 後加上 [-\s.]?。另一開發者若需將區號設為可選，也能瞬間定位修改點。這就是「可讀性即可維護性」的威力。

習慣二：建立三層測試機制，在生產環境前攔截 Bug

測試分三個層次，層層疊加可靠性：

思維推演：明確「必須匹配什麼」與「能容忍什麼錯配」。在嚴格（漏配）與寬鬆（錯配）間尋找平衡點。例如電話號碼驗證：Web 表單可能只需十位數字；但從大量文本提取時，則需嚴格排除 800-555-4000 = -5355 這類噪音。
單元測試：編寫腳本跑測試用例。覆蓋正常、邊界、異常輸入。任何複雜 Regex 都值得寫專門測試腳本。
回歸測試套件：將所有 Regex 測試整合至自動化測試流程。即使尚無完整測試框架，Regex 測試也是啟動它的最佳切入點。每次修改後必跑測試，前期投入極少，後期省力無窮。

測試腳本範例（以 Perl 為例）

#!/usr/bin/perl
my @tests = (
    "314-555-4000", "800-555-4400", "(314)555-4000",
    "314.555.4000", "555-4000", "aasdklfjklas", "1234-123-12345"
);

foreach my $test (@tests) {
    if ( $test =~ m/
        (?          # 可選括號
          \d{3}     # 區號
        )?          # 結束可選
        [-\s.]?     # 分隔符
        \d{3}       # 前綴
        [-\s.]      # 分隔符
        \d{4}       # 號碼
    /x ) {
        print "Matched: $test\n";
    } else {
        print "FAILED: $test\n";
    }
}

執行後會發現 1234-123-12345 也被錯配 —— 這就是測試的價值：暴露邏輯盲區。

習慣三：為交替操作（`|`）加上分組括號

交替操作符 | 優先級極低，常導致匹配範圍超出預期。經典錯誤：

^CC:|To:(.*)

意圖是匹配以 CC: 或 To: 開頭的行並捕獲後續內容。實際上：

匹配 ^CC: 開頭的行，但捕獲組為空；
匹配任意包含 To: 的行，並捕獲其後所有內容。

結果大量垃圾數據混入，卻無人發現 Bug。正確寫法需顯式分組：

^(CC:|To:)(.*)

養成「交替必分組」習慣，即可徹底避開此類陷阱。

習慣四：優先使用非貪婪量詞（`*?`、`+?`、`??`）

許多開發者避開非貪婪量詞，實則它們能讓表達式更易寫、更易懂、更不易出錯。貪婪量詞會匹配盡可能多的字符，非貪婪則匹配盡可能少。

例子：從 foo###bar+++bar 捕獲中間的 ###。

foo(.*)bar → 捕獲 ###bar+++（貪婪匹配到最後一個 bar）
foo(.*?)bar → 捕獲 ###（非貪婪在第一個 bar 停下）

當你清楚目標文本的結構邊界（如標籤、分隔符）時，非貪婪量詞是極佳利器，能大幅減少後續字符集組裝的麻煩。

習慣五：靈活選擇分隔符，告別「斜線森林」

Perl/PHP 慣用 / 作為分隔符，Python 用引號。若模式本身包含大量斜線（如 URL、HTML 標籤），你將陷入 \/ 轉義地獄，降低可讀性並埋下遺漏轉義的 Bug。

Perl/PHP 允許使用任意非字母數字、非空白字符作為分隔符；成對符號（()、[]、{}、<>）只需保持成對即可。常用替代分隔符：#、!、|、% 等。

對比

# 斜線版：轉義噩夢
/http:\/\/(.*)\//

# 井號版：清爽自然
#https://(.*)/#

選擇不衝突的分隔符，能讓 Regex 瞬間變清晰，減少一半轉義符，降低認知負擔與錯誤率。

總結

正則表達式本身不複雜，複雜的是我們對它的隨意態度。養成這五個習慣 —— 空白註釋、分層測試、交替分組、非貪婪量詞、靈活分隔符 —— 將從根本上改變你與 Regex 的關係：從「寫時爽、改時痛」進化為「寫得清、改得快、錯得少」。下次動筆寫 Regex 時，請先給自己留出幾行空間，未來的你（或接手的同事）會感謝今天的你。