一串天書先被拆開了：ValidX 與正則表達式，是兩種被設計出來的可讀性

2026 年 10 月 28 日，開發者 vipxieliang 在掘金發表了一篇長文，標題是「ValidX vs 正則表達式：可讀性與維護性對比」。文章把同一個驗證需求交給兩種寫法，再逐項比較。這類技術選型文在技術社羣裡很常見，但這一篇值得從設計角度讀，因為它比較的其實是兩種「介面」：一種把規則壓縮成一行字串，另一種把規則攤開成結構化的語意呼叫。

先看那個最具體的物件。文章舉的中國手機號正則是長這樣的：^1(?:3[0-9]|4[579]|5[0-35-9]|6[2567]|7[0-8]|8[0-9]|9[0-9])\d{8}$。對會寫正則的人，這行字是可解讀的，代價是逐字元分析：括號裡列舉的是號段，尾段是八位數字。問題在於，號段一旦更新，修改的單位是一個字元，而不是一段有名稱的邏輯。這就像排版時把整段文字壓進一個不可斷行的欄位，省了空間，卻失去了可以局部編輯的結構。

ValidX 走的是相反方向。它把驗證攤平成語意化的 API 呼叫，每一條規則有自己的名字與位置。作者在文中明確定位：ValidX 不是要取代正則，而是在正則之上提供語意化、可擴充、可維護的驗證層。這個定位本身是克制的設計判斷。簡單格式如「六位數字」，^\d{6}$ 一行就夠，換成結構化 API 反而囉嗦；但當驗證從「格式對不對」升級到「值合不合法」，例如身分證需要校驗位、銀行卡需要通過 Luhn 演算法，正則的表達力就到牆了。Luhn 是數學計算，正則只能描述文字模式，算不了加總與模除。

文章把差異整理成三個痛點：可讀性差、維護性差、表達力有限。對應到設計語言，這正是「壓縮」與「展開」的取捨。正則是高度壓縮的符號系統，資訊密度高，但閱讀與修改的成本轉嫁給了接手的人；結構化驗證把資訊攤開，佔的行數多，但每一行都可以被單獨指認、命名與更換。跟傳統的正則寫法相比，ValidX 換掉的是工程師閱讀規則時的那層解碼工作。

這篇文章與我們先前觀察過的ValidX 語言包的介面設計屬於同一條線索：同一個開源驗證庫，在錯誤訊息那一端處理的是輸出給使用者看的文字，在驗證規則這一端處理的是寫給工程師看的結構。兩端共享同一個設計哲學，把原本隱晦的東西攤開成可讀的介面。

作者也沒有把比較停在可讀性。文中的維護性章節以「號段更新」為例：正則方案碰到號段變動時近乎重寫，結構化方案則是改一條規則；性能章節則指出 ValidX 實際上是混合方案，底層仍借助預編譯的正則做格式比對，再疊上演算法校驗。換句話說，它沒有發明新的比對引擎，而是重新安排了規則的版面。這一點誠實：可讀性的收益不是用性能換來的幻覺。

技術選型文容易寫成二選一的站隊，這篇的可取之處在於收束方式：什麼時候正則就夠、什麼時候需要驗證層、如何混合使用。把它當設計案例看，結論也一樣清楚。正則適合放在沒有人需要再讀它的地方，一行格式檢查，寫完即封存；一旦規則會隨業務變動、需要被別人接手維護，驗證邏輯就值得被攤開成有名稱、有層次的結構。可讀性從來不是把字寫漂亮，而是決定規則要以什麼單位被人修改。