前言
Regex 很強，強到很多人會下意識「先用 regex 解決看看」。
但真正的問題不是「能不能寫出來」，而是：
這件事，該用 regex 嗎？
這篇不教語法，而是給你一個更實用的判斷方式——
什麼時候該用 regex，什麼時候應該停手。
通則
一句話原則
當你需要「理解結構」而不是「找樣式」時，就不該用 regex。
把問題拆開：三個層級
與其問「regex 可不可以」，不如先問：
你現在在處理的是哪一層問題？
第一層：Pattern（樣式）
這是 regex 的舒適圈。
你在做的是：
- 找 email
- 抓 URL
- 統一標題前綴（例如「攻略｜」）
- 批次清理空白或符號
- 搜尋／取代特定字串
這些事情的共同點是：
- 不需要理解上下文
- 不需要配對結構
- 只看「長得像不像」
👉 在這一層：
regex 幾乎沒有對手。
第二層：Structure（結構）
問題開始變得微妙。
你可能會想做這些事：
- 抓某個
<div>裡的內容 - 避開巢狀的 HTML tag
- 只修改某個區塊內的文字
- 處理 Markdown 的段落或列表
這時候會發生什麼？
- 你開始思考「範圍」
- 你開始擔心「配對」
- 你開始怕「抓太多或抓不到」
regex 在這裡不是做不到，而是開始出現這些特徵：
- 表達式變長
- 可讀性下降
- 行為變得不穩定
- 很容易因為資料變動而壞掉
👉 一個很實際的判斷：
你寫得出來，不代表你未來看得懂。
第三層：Semantics（語意）
到了這一層，就不該再用 regex 了。
例如：
- JSON 是否合法
- HTML 是否正確關閉
- Markdown 如何解析成段落／列表／程式碼區塊
- 程式碼語法分析
這些問題的共通點是：
- 需要理解「它是什麼」
- 需要判斷「對不對」
- 有明確的語法規則
👉 在這一層：
regex 不只是不好用，而是用錯工具。
當你開始處理這類問題時，你其實已經不在處理「字串」，而是在處理「結構本身」。
也就是說，你關心的已經不是某段文字長什麼樣子，而是：
- 它在整體中的位置
- 它屬於哪個區塊
- 它是不是一個合法的結構
這類問題通常會交給專門的解析工具處理，而不是用 regex 硬做。
一個很實用的自我檢查
如果你在寫 regex 時開始出現這些想法：
- 「這個 tag 有沒有對應的 closing？」
- 「我要確保這段在某個區塊裡」
- 「我要避免抓到巢狀內容」
- 「這樣寫會不會抓到錯的結構？」
那其實代表一件事：
你已經在處理「結構」，而不是「樣式」。
常見情境：哪些可以用？哪些不該用？
✅ 適合用 regex
- 統一文章標題格式
- 找出所有外部連結
- 清除多餘
<br>或空白 - 抓出特定參數（例如
utm_）
⚠️ 勉強可以，但風險很高
- 抓某個 HTML 區塊內的內容
- 修改巢狀結構中的一部分
- 處理混合 Markdown（例如 list + code block）
這些情境常見，但有一個共通點：
regex 可以做到，但你不應該這樣做。
❌ 不該用 regex
- 解析 HTML → 應該用 DOM parser
- 處理 JSON → 應該用 JSON parser
- 轉換 Markdown → 應該用 AST 工具
- 分析程式碼 → 應該用語法解析工具
regex 的本質限制
regex 擅長處理的是：
「字串長什麼樣子」
但很多實際問題需要的是：
「這段內容在整體結構中的位置與角色」
這兩件事本質上不同。
你可以把它想成：
- regex → 超強版 Ctrl + F
- 結構工具 → 真的理解文件內容
結論
regex 解決的是「字串長什麼樣子」，
但網站資料真正的問題，往往是「它屬於哪一個結構」。
當問題從「像不像」變成「對不對」，
regex 就該退場了。