做開發(fā)、運維或者測試的朋友早晚都會碰到“正則表達式”這個東西。第一次看見一長串\d\.\d的時候大多數(shù)人腦子里只有三個字這是啥。實際上正則表達式就是一套用字符描述“你要在文本里找什么形狀”的規(guī)則它能幫你做三件事校驗一段文本符不符合某種格式、從一堆文字里提取你需要的片段、把匹配到的內(nèi)容批量替換成別的東西。這套規(guī)則在幾乎所有編程語言、命令行工具、甚至編輯器和數(shù)據(jù)庫里都是通用的學(xué)會一次到處能用。這篇文章不講高深理論直接按我平時寫正則的路徑走先搞懂語法骨架再用幾個真實場景練手最后把我看過最多的坑和排查思路整理出來。無論你是剛接觸正則的新手還是寫過一陣但總是“調(diào)不對”的老手都能拿這份內(nèi)容當參考。1. 正則表達式到底是什么——先打破“天書”濾鏡1.1 說白了就是一套字符匹配規(guī)則我經(jīng)常跟新同事打一個比方正則表達式像一張“鏤空的卡片”你把它蓋在文本上只有形狀對得上的地方才會透出光來。這里的“形狀”不是你肉眼看到的文字而是你定義的一套字符規(guī)則比如“三個數(shù)字”“任意字母”“行首位置的ERROR”等等。這里的關(guān)鍵點是正則描述的是“結(jié)構(gòu)”不是“內(nèi)容”。比如我想找所有身份證號我不會逐個輸入具體號碼而是描述“18位數(shù)字最后一位可能是數(shù)字或X”正則表達式用\d{17}[\dX]就表達完了。這種“用規(guī)則代替枚舉”的思路是理解正則的第一塊基石。也因為它是描述規(guī)則所以它能通吃不同的文本源。昨天你在grep里過濾日志今天在Python里批量清洗數(shù)據(jù)明天在數(shù)據(jù)庫里做模糊查詢底層邏輯都是同一套。很多新手被勸退不是規(guī)則本身難而是被各個工具里的“方言”繞暈了。其實核心語法就那么多后面會一個個說清楚。1.2 三個最典型的應(yīng)用場景正則到底能解決什么實際問題我總結(jié)了三個高頻場景基本覆蓋90%的使用需求。第一個是格式校驗。你寫了一個注冊表單用戶輸入的郵箱看起來像不像郵箱、IP地址到底合法不合法、手機號是不是11位這種“判斷一個字符串是否符合某種格式”的需求正則是首選方案。判斷邏輯寫一次前后端都能用。第二個是信息提取。日志文件幾萬行你想把里面所有IP、訂單號、金額篩出來爬蟲抓了一堆網(wǎng)頁你想把鏈接和標題拎出來這種“從大文本里撈特定片段”的場景正則加一個提取函數(shù)就搞定了。第三個是批量替換與清洗。代碼里大量接口從HTTP切到HTTPS或者把數(shù)據(jù)里所有手機號中間四位打碼正則配合替換函數(shù)一步到位。我見過不少新手用一堆if和indexOf去處理這些事遇到復(fù)雜一點的格式就寫得又長又容易出錯。正則的定位從來不是炫技它就是用最小成本完成文本處理的最優(yōu)工具。后面我會用幾個真實例子帶你把這三種場景都走一遍。2. 語法骨架字符、元字符與量詞2.1 字面字符容易被忽略的基礎(chǔ)正則里最基礎(chǔ)的一類元素是字面字符。什么意思就是正則里寫的字母、數(shù)字、標點原樣匹配輸入文本里的對應(yīng)字符。比如正則abc就只能匹配到文本里的“abc”這三個連續(xù)字符。你可能會覺得這太簡單了沒什么好講的。但我想提醒一點很多復(fù)雜的匹配問題本質(zhì)上是“字面字符 規(guī)則字符”的組合。比如你匹配一個文件路徑C:\Users\name里面的反斜杠就是字面字符但在正則里它有特殊含義你必須寫成C:\\Users\\name才能匹配到真正的反斜杠。搞不清哪些字符需要轉(zhuǎn)義這是后面所有坑的源頭。另外字面字符的匹配是區(qū)分大小寫的。除非你顯式開啟IGNORECASE或?qū)?yīng)的忽略模式否則abc不會匹配ABC。這個細節(jié)在排查“為什么我的正則沒匹配上”的時候非常常見卻經(jīng)常被忽略。2.2 元字符正則表達式的真正主角如果說字面字符是“兵”元字符就是“將領(lǐng)”它們決定了匹配的靈活性。正則里最核心的元字符我按使用頻率給你列一下.匹配除換行符以外的任意單個字符。注意是“任意單個”用它的時候你自己得心里有數(shù)別讓范圍失控。^匹配行首位置不是字符本身。比如^ERROR只匹配出現(xiàn)在行首的ERROR。$匹配行尾位置。比如END$匹配行尾的END。*前面的字符重復(fù)0次或多次。a*能匹配出空字符串、a、aa、aaa……前面的字符重復(fù)1次或多次。a至少要有一個a才算匹配。?前面的字符重復(fù)0次或1次也就是“可有可無”。colou?r能同時匹配color和colour。{}指定重復(fù)次數(shù)。\d{4}匹配恰好4位數(shù)字\d{2,4}匹配2到4位\d{2,}匹配至少2位。[]字符類匹配方括號內(nèi)任意一個字符。[abc]匹配a、b、c中任意一個。\轉(zhuǎn)義符讓后面的元字符變成普通字符或者讓普通字母擁有特殊含義比如\d表示數(shù)字。|或者匹配左邊或右邊任意一邊。cat|dog匹配cat或dog。()分組把一段正則當成整體處理也能捕獲匹配內(nèi)容。這些元字符是正則語法的“主菜”幾乎每一條實用正則都會用到兩三個以上。我的建議是第一次接觸不用死記先混個臉熟后面跟著案例用幾遍就記住了。2.3 量詞與貪婪、懶惰模式*、、?、{}這四個都叫量詞它們控制的是“前一個元素重復(fù)幾次”。但這里有個新手幾乎必踩的坑量詞默認是貪婪的。什么意思正則引擎會盡量匹配最長的結(jié)果。舉個很典型的例子。輸入字符串是b加粗/b和b正常/b你用正則b.*/b去匹配直覺上你可能以為它匹配到第一個/b就結(jié)束了但貪婪模式會讓它一直吃到最后一個/b得到一整段b加粗/b和b正常/b。很多新手第一次碰到這種情況都會以為自己的正則寫錯了其實不是這是貪婪的默認行為。想讓匹配結(jié)果“見好就收”在量詞后面加一個問號b.*?/b。這就是懶惰模式也叫非貪婪模式它會從左邊開始找最短的匹配。剛才那個例子里懶惰寫法就能分別匹配到b加粗/b和b正常/b兩個結(jié)果。記住這個“量詞后加問號變懶惰”的口訣能少走很多彎路。2.4 字符類與預(yù)定義字符類字符類[]可以讓你在一組候選字符里挑一個匹配。[aeiou]匹配任意一個元音字母[0-9]匹配任意一位數(shù)字[a-zA-Z]匹配任意大小寫字母。定義取反也很方便在左方括號后面加一個^[^0-9]匹配任意非數(shù)字字符。為了方便正則里有一組預(yù)定義字符類本質(zhì)是常見字符類的簡寫\d等價于[0-9]匹配一位數(shù)字。\w等價于[A-Za-z0-9_]匹配字母、數(shù)字、下劃線。\s匹配空白字符包括空格、制表符、換行符。\D、\W、\S分別是上面三個的取反。我工作中最常用的組合是\d匹配一串數(shù)字[\w.-]匹配域名或郵箱的前半部分\s匹配連續(xù)空白。新手容易把\w理解成“中文也能匹配”實際上在大多數(shù)默認配置下它只認英文字母、數(shù)字和下劃線匹配中文要用[\u4e00-\u9fa5]或者開啟對應(yīng)語言的Unicode模式。這個差異在不同語言里表現(xiàn)還不一樣后面會提到。3. 實戰(zhàn)案例IP校驗、grep過濾、字母數(shù)字組合3.1 用正則表達式判斷字符串是不是合法的IPv4地址這是網(wǎng)上問得最多的正則場景之一也是檢驗?zāi)闶遣皇钦娑侄魏瓦吔绲暮美?。先明確需求IPv4地址由四段組成每段是0到255之間的數(shù)字段與段之間用英文句點分隔。注意“0到255”這個范圍是不能簡單用\d{1,3}來匹配的因為999也會被它匹配上。正確的做法是把0到255拆成四段來看250到25525[0-5]也就是“25”后面跟0到5。200到2492[0-4]\d也就是“2”、0到4、任意數(shù)字。100到1991\d\d也就是“1”加任意兩位數(shù)字。0到99[1-9]?\d也就是可以有一位非零數(shù)字也可以沒有后面再跟一位任意數(shù)字。這里有一個“正則味”很濃的寫法它同時覆蓋了個位數(shù)和十位數(shù)。把四段拼起來再用括號把“點號加一段”這個整體重復(fù)三次得到最終表達式^(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}$注意開頭有^結(jié)尾有$這是必須的。少了邊界錨定123.456.789.0這種非法地址也能在里面“截胡”出看起來合法的片段。這也是我在前面強調(diào)過的寫校驗型正則永遠帶上邊界。如果你在C#里使用代碼是這樣using System; using System.Text.RegularExpressions; public class IpValidator { public static bool IsIpv4(string input) { string pattern ^(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}$; return Regex.IsMatch(input.Trim(), pattern); } }這里用了C#的逐字字符串語法目的是讓正則里的反斜杠不用寫雙份。你換成Python時用r原始字符串也是一個道理。這一點很多人栽過跟頭我單獨放到后面“反斜杠地獄”里細講。順帶提醒這個正則只認IPv4IPv6的格式完全不同需要另一套規(guī)則。如果輸入里可能混入空格、全角符號最好先做一次Trim()或者規(guī)范化處理否則邊界錨定會直接失敗。3.2 在grep命令中使用正則表達式過濾文本grep是Linux命令行里最常用的文本搜索工具它天然支持正則。但新手經(jīng)常在grep里被正則語法“坑”到原因是grep的默認模式是“基礎(chǔ)正則表達式”很多元字符需要轉(zhuǎn)義才能生效。比如|和()在基礎(chǔ)正則里只是普通字符你得寫成\|和\(才有特殊含義。最省心的做法是直接用擴展正則模式參數(shù)是-E。grep -E的語法和絕大多數(shù)編程語言里的正則更接近不用額外加一堆反斜杠。我個人的習(xí)慣是只要涉及復(fù)雜規(guī)則一律用grep -E。幾個高頻場景直接抄作業(yè)# 找出以ERROR開頭的所有行示例日志診斷 grep -E ^ERROR app.log # 找出2024年1月15日當天的訪問記錄 grep -E 2024-01-15 access.log # 用 -o 只提取匹配的部分而不是整行 # 下面這個命令能從日志里把IP地址都摳出來 grep -oE [0-9]\.[0-9]\.[0-9]\.[0-9] access.log # 用 -v 反向過濾排除以#開頭的注釋行示例配置檢查 grep -vE ^# nginx.conf # 統(tǒng)計匹配次數(shù)而不是列出內(nèi)容 grep -cE ERROR app.loggrep里還有一個經(jīng)典細節(jié)單引號和雙引號。建議在正則有特殊字符時用單引號包住整個表達式避免shell把$、*、!等字符先解釋一遍。這個坑我踩過一次寫grep -E err.*(1|2)$時shell把$當成了變量符最后匹配結(jié)果完全不對。改成單引號立刻正常。3.3 字母和數(shù)字組合怎么寫密碼與賬號校驗“字母和數(shù)字的組合”是很多業(yè)務(wù)系統(tǒng)的剛需最常見的就是密碼規(guī)則。需求通常是密碼只能包含字母和數(shù)字而且二者都要有。直接寫[A-Za-z0-9]只能保證“都是字母數(shù)字”卻攔不住“全是字母”的情況。要限制“至少包含”需要用到后面會細說的零寬斷言這里先亮出寫法^(?.*[A-Za-z])(?.*\d)[A-Za-z\d]$拆開看這行正則分三段(?.*[A-Za-z])從當前位置開始往后看必須存在至少一個字母。這是一個斷言它不消費字符只做“有沒有”的判斷。(?.*\d)同理必須存在至少一個數(shù)字。[A-Za-z\d]$整個字符串從頭到尾只能由字母和數(shù)字組成。如果需求更嚴格要求必須同時包含大寫、小寫、數(shù)字、特殊字符并且長度8到20位可以寫成^(?.*[a-z])(?.*[A-Z])(?.*\d)(?.*[^A-Za-z0-9])[\s\S]{8,20}$這里[\s\S]的作用是匹配任意字符包括換行因為某些語言里.默認不匹配換行。用[\s\S]可以規(guī)避這個差異。這個寫法我在多個項目里直接用過基本拿到需求改一改就能上線。4. 進階分組、斷言與性能4.1 分組與捕獲把匹配結(jié)果拆開使用括號在正則里最基礎(chǔ)的作用是分組但它同時還做了另一件事捕獲。捕獲的意思是被括號包住的部分匹配結(jié)果會被單獨存起來供后續(xù)提取或反向引用。比如從日期文本2024-09-15里提取年月日^(\d{4})-(\d{2})-(\d{2})$匹配成功后第一個捕獲組是年份第二個是月份第三個是日期。在Python里可以用match.group(1)拿到在JavaScript里可以用match[1]拿到在sed替換里可以用\1引用。這個“提取”能力是正則從“判斷有沒有”進化到“掏出內(nèi)容”的關(guān)鍵。反向引用也是我很常用的技巧。比如找出文本里連續(xù)重復(fù)的單詞\b(\w)\s\1\b這里\1引用了第一個捕獲組已經(jīng)匹配到的內(nèi)容所以它能匹配類似the the、is is這種重復(fù)詞。很多文本去重、錯別字檢查工具背后都有類似邏輯。不是所有括號都需要捕獲。比如我前面寫的IP校驗分組只是想把“點號加一段”這個整體重復(fù)三次并不需要單獨取出每一段。這時可以用非捕獲組(?:)來替代()能省掉一些性能開銷也能讓捕獲組的編號更干凈。IP校驗正則改成非捕獲版本是這樣的^(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(?:\.(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}$從功能上講它和捕獲版沒區(qū)別但如果你要據(jù)此擴展、解析每一段的具體數(shù)值捕獲版反而更方便。用哪種取決于你有沒有“取出這段”的需求。4.2 零寬斷言匹配位置而不是內(nèi)容零寬斷言是正則里最“概念化”的部分但它非常實用。核心思想是它只要求“這個位置滿足某個條件”但不會把內(nèi)容算進最終匹配結(jié)果里。所以叫“零寬”意思就是它不吃字符。四種斷言按方向分兩類正向先行斷言(?...)右邊必須是…比如\d(?元)能匹配“100元”里的100但不會把“元”帶出來。負向先行斷言(?!...)右邊不能是…比如\d(?!元)匹配后面不是“元”的數(shù)字。正向后行斷言(?...)左邊必須是…比如(?)\d匹配人民幣符號后面的數(shù)字同樣不包含符號本身。負向后行斷言(?!...)左邊不能是…比如(?!)\d匹配不在人民幣符號后面的數(shù)字。這個能力最大的價值是“精準定位又不破壞內(nèi)容”。舉個例子給一個長數(shù)字加千分位分隔符需要從右往左每三位加一個逗號。用替換功能配合正則(?\d)(?(\d{3})(?!\d))就可以只插入逗號、不碰數(shù)字本身。這比先把數(shù)字拆成數(shù)組再處理要簡潔得多。新手學(xué)斷言容易混淆的一點是斷言里寫的表達式還是要“符合某個形態(tài)”但它不參與最終捕獲結(jié)果的切片。建議在腦子里把斷言理解成一個“站在當前位置往兩邊看的條件”這樣就不會糊涂了。4.3 回溯與性能陷阱為什么你的正則越來越慢正則寫到后期性能問題會浮出水面。尤其在NFA非確定有限自動機引擎里匹配過程靠回溯來試錯。某些寫法會讓回溯量爆炸式增長日志處理、網(wǎng)關(guān)過濾這類高吞吐場景下一個糟糕的正則就能拖垮服務(wù)。最典型的災(zāi)難性回溯是嵌套量詞。比如匹配a標簽內(nèi)容如果寫成a.*/a倒還好但如果你為了“保險”寫成了a(.*)*/a問題就來了內(nèi)層的.*和外層的*都擁有回溯權(quán)限引擎會反復(fù)嘗試各種分割方式輸入一長CPU瞬間打滿。我見過有人拿這種正則在線上網(wǎng)關(guān)過濾HTML結(jié)果壓力測試時直接把節(jié)點CPU跑滿。這不是正則“不靈”是寫崩了。幾個性能優(yōu)化經(jīng)驗我每次寫正則都會過一遍盡量用錨定^和$讓引擎快速排除不匹配的輸入。用字符類代替多選交替比如[abc]優(yōu)先于(a|b|c)雖然差別不大但積少成多。避免嵌套量詞(a)、(.*)*這種結(jié)構(gòu)能繞開盡量繞開。能用懶惰量詞就用懶惰量詞避免貪婪匹配吃掉大段內(nèi)容。大文本里提取IP優(yōu)先考慮\d{1,3}(\.\d{1,3}){3}這類簡單模式而不是寫一個帶四段校驗的復(fù)雜模式先過濾一遍再在代碼里做二次校驗。記住一個原則正則不是越復(fù)雜越安全能用簡單模式解決問題就別寫花活。5. 新手最容易踩的坑與排查套路5.1 反斜杠地獄不同語言里的轉(zhuǎn)義規(guī)則正則里有大量反斜杠但在不同語言里字符串本身也會解析反斜杠這就會導(dǎo)致同一個正則在不同語言里寫法不一樣。最常見的困惑是為什么Python里寫\d到了JavaScript里要寫\\d原因在于某些語言里反斜杠是字符串的轉(zhuǎn)義字符\d這個字符串里的\d會被字符串解析器當成無效轉(zhuǎn)義吃不到正則引擎里。所以要么寫成\\d先讓字符串解析成一個反斜杠再傳給正則要么用該語言提供的原始字符串語法。我列一下常用語言的安全寫法Pythonre.compile(r\d)推薦使用r開頭原始字符串。C#Regex.IsMatch(input, \d)推薦使用逐字字符串。JavaScript沒有原始字符串只能寫\\d或者/\d/正則字面量。Java同樣沒有原始字符串必須寫\\d。Go推薦使用反引號原始字符串\d。每次在群里看到有人把“為什么我的正則搜不到”的問題截圖發(fā)來十有八九就是反斜杠被字符串層吃掉了。建議你寫代碼之前先查一下當前語言有沒有原始字符串語法有就優(yōu)先用。如果沒有就數(shù)清楚反斜杠必要時可以先print出來看一眼正則引擎到底收到的是什么。5.2 常見問題速查表我在帶新人的過程中把出現(xiàn)頻率最高的問題匯總成了一張表遇到問題直接查能省去大量瞎試的時間?，F(xiàn)象常見原因解決方案明明有內(nèi)容卻匹配不到正則里有轉(zhuǎn)義字符被字符串層吞掉改用原始字符串或補上反斜杠匹配結(jié)果比預(yù)期長量詞默認貪婪吃到了很遠的地方在量詞后加?改為懶惰模式只匹配到行首/行尾附近的內(nèi)容邊界錨定^和$影響了范圍確認是否真的需要全文匹配還是應(yīng)該限定行內(nèi)搜索郵箱、手機號規(guī)則時靈時不靈沒有考慮邊界和前后綴字符加上^和$或使用分詞符\b\w匹配不到中文默認字符類不包含中文用[\u4e00-\u9fa5]或啟用Unicode模式空白字符匹配不上可能混入了全角空格或換行用\s匹配必要時先用編輯器顯示隱藏字符排查在grep里|和寫法混亂基礎(chǔ)正則和擴展正則語法不同捕獲組取出的內(nèi)容不對分組編號與預(yù)期不符先用非捕獲組(?:)調(diào)整編號再取捕獲值正則運行很慢存在嵌套量詞或過度回溯簡化模式用錨定、字符類、懶惰量詞這張表不是標準答案但它覆蓋了絕大多數(shù)日常場景。遇到問題先對號入座基本能定位到80%的原因。5.3 一份可復(fù)制的排查流程正則寫出來不對別急著盲目加字符。我自己的排查流程固定下來就四步推薦你也試試。第一步先確定需求邊界。你要匹配的到底是“整段文本必須完全合規(guī)”還是“只要文本里含有合規(guī)片段就行”這兩者對應(yīng)完全不同的寫法前者要加^和$后者通常不需要。很多人第一步就搞混了后面全白搭。第二步把表達式拆成最小單元逐個測試。比如IP校驗正則先單獨測試25[0-5]能不能匹配255和256再測2[0-4]\d能不能匹配249和250最后拼起來整體測。用在線正則工具比如regex101、regexr能實時看匹配結(jié)果還能看到捕獲組和匹配位置非常直觀。第三步造幾個“邊境用例”驗證邊界。寫日期正則就測一下1月、12月、01月、31日、00日這些邊界寫密碼正則就測純數(shù)字、純字母、字母數(shù)字混合、超長、超短。邊界用例能幫你把隱藏的邏輯漏洞揪出來。第四步確認當前語言里的轉(zhuǎn)義和模式差異。同一個正則在Python的re模塊、JavaScript、grep -E之間多多少少有細微差別。特別是字符類的Unicode支持和斷言的支持情況不同版本和不同工具差別很大。寫完之后最好在目標環(huán)境里跑一遍真實用例不要只看在線工具的結(jié)果。最后再分享一個我自己的小習(xí)慣寫了這么多年正則我最大的體會是這玩意兒不值得死記硬背真正值錢的是“拆解思路”。拿到需求先想結(jié)構(gòu)、再選字符類、最后調(diào)量詞和邊界比背一百條現(xiàn)成規(guī)則都管用。說實話我現(xiàn)在寫復(fù)雜正則也還是會翻速查表這很正常沒人會把所有冷門語法都裝在腦子里。最后一個小技巧所有校驗型的正則我?guī)缀醵紩陂_頭加^、結(jié)尾加$除非我明確知道自己做的是“包含匹配”。另外正則表達式最好加上注釋。很多語言支持(?#注釋)這種內(nèi)聯(lián)注釋但更實用的做法是在代碼里留一行字符串說明“這個正則到底在匹配什么、為什么這么寫”。不然三個月后你回來看自己寫的那串天書真的會懷疑人生。希望這份內(nèi)容能幫你少走點彎路早點把正則變成你工具箱里順手的那把螺絲刀。