企业官网建设流程全解析

上个月帮同事排查一个日志提取的问题，他在两千行日志里找所有订单号，第一版用字符串切片加 startswith 判断，结果前端订单号和后端订单号的前缀规则不一样，改了三天还没改干净。我说你花十分钟理解一下正则表达式，把订单号的生成规则写成模式，一行代码就完事。他试完之后跟我说：这玩意儿为什么没有早点学。

这就是正则表达式最典型的处境：看起来符号密集、吓人，学完觉得真香。这篇博文不是从零开始的语法手册，而是把我这些年用正则表达式处理文本、写 Python 脚本、排查线上问题时的经验一次性梳理出来。重点放在三件事：核心语法在真实场景里的含义、怎么从需求推演正则写法、以及 Python 的 re 模块里那些文档不会写清楚的坑。不管你是第一次接触，还是已经写过一阵但总觉得自己是"复制粘贴流"，这篇都值得读完。

1. 正则表达式不是背语法，是换一种角度看文本

1.1 一个让我同事加班三天的匹配需求

他当时的日志长这样：

2025-01-12 10:23:45 order_id=SO20250112001 user=10086 status=paid 2025-01-12 10:25:12 order_id=TB20250112A02 user=10086 status=paid 2025-01-12 10:30:01 order_id=JD20250112003 user=10088 status=cancel

需求是把所有订单号提取出来。订单号规则很清晰：SO、TB、JD开头，后面跟日期和序号。但他用字符串处理时，得先 find "order_id="，再切片到下一个空格，还要判断不同前缀的长度差异，写了一堆 if 分支。等他把这段逻辑跑完，发现有一行订单号后面没空格而是直接跟#，又崩了。

用正则表达式的话，这行模式本身就把"找什么"写清楚了：

import re pattern = r'order_id=([A-Z]{2}\d{8,})' order_ids = re.findall(pattern, log_text)

[A-Z]{2}指两个大写字母，\d{8,}指至少 8 位数字。模式一写，什么样的字符串能匹配、匹配完抓哪个部分，全在规则里，不再依赖文本里那些脆弱的"位置偏移"。这是理解正则表达式最核心的一个视角转变：你不是在"处理字符串"，你是在描述一段文本应该长什么样。

1.2 正则到底在"看"什么：字符流与模式

正则表达式引擎拿到一段文本后，会把它当作一个字符流，从左到右尝试让"模式"去匹配"文本"。你可以把它想象成一把带形状的钥匙，文本是一排排锁孔，钥匙形状对上了才插得进去。

字符流的意思就是：正则引擎不会像人一样理解"订单号"这个概念，它只认字符。所以你要告诉它的不是"找订单号"，而是"找两个大写字母开头、后面跟一串数字、并且存在于 order_id= 之后的连续字符"。这个"告诉"的过程，就是写模式。

而这种思维方式恰恰是初学者最缺的。很多人见到一个需求，第一反应是"用 split 切一下""用 find 找一下"，而不是"这个字符串的结构是什么"。一旦你把结构想清楚，正则表达式只是把结构翻译成符号。比如上面的[A-Z]{2}\d{8,}，本质上就是在描述"大写字母、大写字母、数字、数字……"这一段结构。

1.3 什么场景不该硬上正则

这东西好用，但真不是万能钥匙。我见过有人用正则去解析 JSON，写了两百多个字符的嵌套模式，最后根本维护不了。正则表达式擅长的是匹配没有深层嵌套的线性文本，一旦涉及层级结构——比如 HTML 标签嵌套、JSON 括号配对——正则就会变得无比痛苦，因为你需要自己管理嵌套深度，而正则本身没有"计数器"这种东西。

遇到深度嵌套结构，直接上真正的解析器：Python 里有html.parser、json.loads，根本不应该用正则去碰。正则的边界意识很重要，知道什么时候不写正则，比会写正则更值钱。

2. 核心语法一次梳理：把每个符号放到场景里去记

2.1 基础字符与字符类：先别急着一个个背

很多人一上来就背元字符表，什么^$.*+，背完就忘。我的建议是：别按符号背，按"我想匹配什么"来记。

最基础的概念就三类：

• 字面量：想匹配order，就写order。这是最朴素的匹配。
• 字符类：想匹配"一个数字"，写\d；想匹配"一个字母或数字"，写\w；想匹配"任意空白"，写\s。反过来大写就是取非：\D是非数字，\W是非字母数字，\S是非空白。还有一个点号.，它默认匹配"除了换行符以外的任意字符"，这个很好用，但也是后面很多性能问题的根源，后面细讲。
• 自定义字符集：[0-9]表示一位 0 到 9，[a-zA-Z]表示一位大小写字母，[^0-9]表示一位非数字。注意方括号里的^是"取非"的意思，跟放到模式开头的^含义不一样。

这里有个日常很常见的坑：很多老程序员喜欢用\w匹配"字母数字下划线"，但在 Python 3 里，\w默认还会匹配中文、日文等 Unicode 字符。这个特性在某些场景下很有用，但如果你想做严格校验，比如用户名只允许英文字母和数字，推荐写[A-Za-z0-9_]而不是\w。要不要用\w，取决于你清不清楚它默认带了 Unicode 匹配。

2.2 量词与贪婪/懒惰：为什么正则总是"多拿"

*表示前一个字符出现 0 次或多次，+表示 1 次或多次，?表示 0 次或 1 次，{n,m}表示 n 到 m 次。这些是最常用的量词。

关键知识点来了：这些量词默认是贪婪模式，也就是说，正则引擎会尽可能多地匹配字符，然后如果发现后面的模式匹配不了，再一步步往回退。这个往回退的动作叫"回溯"，是正则性能问题的核心根源，后面我会专门用一个章节讲。

举一个直观的例子，文本"abc123"，模式\w+匹配结果是什么？它会把abc123整个匹配出来，因为+贪婪。如果你想要"最短匹配"，就得在量词后面加个?，写成\w+?，这时它会尽量少匹配，于是只匹配到a。

实际操作中，贪婪本身不是问题，问题是你写的模式因为贪婪导致结果跟你想象的不一样。最典型的是：

re.findall(r'<.*>', '<div>hello</div>')

如果用贪婪模式，.*会一路吃到最后，把<div>hello</div>整个匹配出来，而不是你想要的第一个标签。这时应该用<.*?>才能匹配到<div>。我建议你记住一句话：加了量词的字符，尽量用非贪婪，除非你很确定要贪婪的效果。但过度依赖非贪婪也会产生性能坑，后面会说到。

2.3 分组、捕获与反向引用

括号()在正则里有两个作用：一是改变优先级，二是把一段模式捕获下来。

捕获的意思是，匹配结果里这段模式匹配到的内容会被单独存起来，方便后续提取。前面日志例子里的([A-Z]{2}\d{8,})就是捕获组，re.findall在有捕获组时返回的是捕获组的内容而不是整个匹配内容，这个行为很多人第一次用都会懵，后面 Python 章节我会细讲。

有时候你只想用括号组织逻辑，不想捕获，就写(?:...)，这叫非捕获组。比如(?:ab|cd)+表示 "ab 或 cd 出现一次或多次"，但你并不关心到底是 ab 还是 cd 被匹配了。用非捕获组的好处是省内存，也避免re.findall返回多余的组。

捕获组还能做反向引用。模式(\w+)\s+\1表示"一个单词、空白、再出现一次同一个单词"，\1引用了第一个捕获组匹配到的内容。这个在做重复检测、配对标签时很有用。Python 里也可以给组起名，写成(?P<name>...)，引用时用(?P=name)，读取时用match.group('name')。命名分组在处理多个字段时非常好用，代码可读性高很多。

2.4 零宽断言：只占位置不占字符

这是正则里比较进阶、但实际工作中非常常用的一类：零宽断言，也叫 lookaround。它的特点是只匹配一个"位置"，不消费字符。

• (?=...)正向先行断言：后面必须跟着...，但不消费它。
• (?!...)负向先行断言：后面必须不是...。
• (?<=...)正向后顾断言：前面必须是...。
• (?<!...)负向后顾断言：前面必须不是...。

举一个实际需求：提取所有以.jpg结尾的文件名，但不要.jpg本身。模式可以写成[\w]+(?=\.jpg)。这样匹配到的内容是文件名，断言负责确认后缀存在但不拿进来。

再比如，校验密码必须包含数字：^(?=.*\d).+$。(?=.*\d)表示"从这个位置往后看，必须能找到任意字符后跟一个数字"，它自己不消费字符，只负责把关。这种写法在表单校验里几乎是标配，理解零宽断言后，很多看似复杂的需求其实一行就能搞定。

3. 实战：从具体需求推演正则写法

3.1 13位数字手机号码正则的正确打开方式

热搜上有个高频问题："13位数字手机号码正则表达式怎么写"。这里我必须先澄清一个关键认知：中国大陆手机号是 11 位，不是 13 位。我第一次做实名认证项目时，也曾在测试环境里写了^\d{11}$去校验，结果前端同事说"不对，我填的是 13 位"，实际是他把国家码 86 也加进去了。

所以"13位数字"这个问题，大概率指的是带国家码的完整号码：86加 11 位手机号，正好 13 位数字。如果业务端要求用户必须填带国家码且不带+的 13 位号码，那正确写法是：

^\d{13}$

但这个正则太粗糙了，它不会校验号段是否合法。更务实的做法是，把手机号本身的校验做扎实，国家码单独处理：

^(?:\+?86)?1[3-9]\d{9}$

拆解一下：(?:\+?86)?表示可选的国际区号，+可以出现也可以不出现，86是必须的；1是手机号首位；[3-9]表示第二位，覆盖了目前所有已开放的号段（13x、15x、16x、17x、18x、19x）；\d{9}是剩下九位数字。

这里有一个非常重要的细节：在 Python 3 中，\d默认匹配 Unicode 数字，包括全角数字１２３、阿拉伯-印度数字等。如果你用^\d{11}$去校验手机号，用户填了个全角数字可能也能通过，这在金融、风控场景下是不能接受的。手机号这种严格校验，一律用[0-9]代替\d：

^(?:\+?86)?1[3-9][0-9]{9}$

顺带说一句，早期业界写手机号正则通常是^1[3458]\d{9}$，因为当时只开放了 13、14、15、18 这几个号段。后来 16、17、19 陆续放号，固化的号段版本就经常出错。正确思路是：第二位校验尽量宽松，用[3-9]，把号段管理的责任交给运营商，而不是靠正则判断未来可能出现的号段。

3.2 从日志文本里提取关键信息

回到开头的场景，假设我们不仅要提取订单号，还要把用户 ID 和状态一起提取出来，就可以用命名分组把整行结构化：

import re log_line = "2025-01-12 10:23:45 order_id=SO20250112001 user=10086 status=paid" pattern = r'order_id=(?P<order_id>[A-Z]{2}\d{8,})\s+user=(?P<user>\d+)\s+status=(?P<status>\w+)' match = re.search(pattern, log_line) if match: print(match.groupdict()) # {'order_id': 'SO20250112001', 'user': '10086', 'status': 'paid'}

注意re.search是在整个文本里找第一个匹配，找到就停。如果你需要找所有匹配项，用re.findall或re.finditer。这里我推荐finditer，因为它返回的是匹配对象迭代器，不会一次性把所有结果都读进内存。处理几十兆日志时，findall可能把内存吃爆，finditer稳得多。

提取日志这种场景，正则的价值在于"模式即文档"。后面任何人看到这个正则，都能理解日志的结构是什么样的。比起字符串切片的逻辑，正则要表达的东西一目了然。

3.3 匹配中文和标点符号的正则写法

有网友搜索"正则表达式代表标点符号是什么"，这其实是很多做文本清洗的人都会遇到的问题。

匹配任意标点符号，最简单的方式是"先排除字母数字和空白"：

r'[^\w\s]'

^\w\s里面先取反，意思是"不是单词字符且不是空白"。对于一段混合中英文的文本，这个正则能匹配到大部分半角标点和中文标点。但它的缺点也很明显：一些特殊 Unicode 符号（比如©、™）也会被匹配进来，如果业务上不需要，就得用更精确的字符范围。

中文标点有自己的 Unicode 区段，常见的有：

要匹配一段文字中的所有中文标点，可以用[\u3000-\u303F]；要匹配所有标点（中英文混合场景），可以组合成[\u3000-\u303F\uFF00-\uFFEF]，或者更简单的思路：把不需要的字符从"所有字符"里排除掉，也就是前面说的[^\w\s]思路。

Python 标准库的re模块不支持\p{P}这种 Unicode 属性写法，这是很多从其他语言转过来的人会踩的坑。如果确实需要按 Unicode 属性匹配，比如只想匹配 Punctuation 属性的字符，可以装第三方库regex，它支持\p{P}。但在大多数业务场景里，[^\w\s]已经足够用了。

另一个常见需求是匹配连续的中文字符，用于判断一段文本里有没有中文。最简单的是：

r'[\u4e00-\u9fa5]+'

注意这个范围只覆盖常用汉字，一些生僻字、扩展 B 区汉字不在里面。如果你要提取的是用户输入里的中文，这个范围基本够用。

4. Python 的 re 模块：代码层面最容易踩的坑

4.1 match、search、findall 到底怎么选

这个问题的答案不记牢，写出来的代码经常跟预期不一致。

• re.match：从字符串的开头开始匹配，如果开头不满足模式，直接返回 None。它不要求匹配整个字符串，只要求"开头匹配"。
• re.search：在整个字符串中从头到尾搜索，找到第一个匹配就返回。
• re.findall：返回所有不重叠的匹配结果，如果有捕获组，返回元组列表，这个行为常让人困惑。
• re.finditer：返回迭代器，逐个产出匹配对象，适合大文本。

很多人踩的坑是用re.match去校验完整输入。例如校验手机号时写re.match(r'1[3-9][0-9]{9}', phone)，当用户输入1139876543201时，这个正则会匹配成功，因为match只要求开头匹配。正确做法是加上^和$锚定整串：

re.fullmatch(r'1[3-9][0-9]{9}', phone)

re.fullmatch是 Python 3.4 以后提供的方法，要求整个字符串完全匹配模式，比手动加^...$更直观、更严格。做表单校验时，请优先用fullmatch。

findall的捕获组行为也需要专门记一下：

re.findall(r'order_id=([A-Z]{2}\d{8,})', log_text) # 返回匹配到的部分 re.findall(r'order_id=[A-Z]{2}\d{8,}', log_text) # 返回整个匹配 re.findall(r'order_id=([A-Z]{2}\d{8,}) cookie=(\d+)', log_text) # 返回元组列表

配合一个经验：如果你只是想找到匹配位置或提取多个组，用finditer加group更可控，虽然代码多几行，但不会出现"不知道返回值是字符串还是元组"的尴尬。

4.2 re.sub 与命名分组配合的替换操作

正则替换我工作中用得非常多，尤其是数据脱敏和格式转换。re.sub的替换字符串里可以用\1、\2引用捕获组，也可以使用命名组\g<name>。

比如把日志中的手机号脱敏，保留前 3 位后 4 位，中间用星号替代：

def mask_phone(match): phone = match.group(0) return f"{phone[:3]}****{phone[-4:]}" re.sub(r'1[3-9][0-9]{9}', mask_phone, text)

re.sub的第二个参数既可以是静态字符串，也可以是一个函数。函数的好处是你可以对匹配结果做任意处理，这在脱敏、格式转换等场景下比字符串替换强大得多。

还有一种常见需求是"只在匹配到的地方插入内容"。比如给所有数字加千分位分隔符，用re.sub配合回调函数很容易实现：

re.sub(r'\B(?=(\d{3})+(?!\d))', ',', '1234567') # 输出 '1,234,567'

这个正则用了两个零宽断言，(?=(\d{3})+(?!\d))表示当前位置之后必须是 3 的倍数位数字且后面不再有数字。这是正则里最经典的千分位写法，面试和工作中都很常见。

4.3 compile 预编译到底有没有必要

re.compile后得到一个 Pattern 对象，性能上确实比直接用re.findall(pattern, text)略快，但差距在绝大多数业务场景下可以忽略。真正值得 compile 的理由有两个：

一是复用。同一个正则要在多个地方、多次调用，与其每次写字符串，不如编译一次，统一维护正则文本。这个优势在正则长了以后非常明显。

二是标志位管理。我们在调用re模块函数的时候，flags 参数每次都传很容易漏，而 compile 时把 flags（比如re.IGNORECASE、re.DOTALL、re.VERBOSE）固化在 Pattern 对象里，之后所有调用都用这一个对象，保证行为一致。

re.VERBOSE是我特别想推荐的一个 flag。它允许你在正则里写注释和忽略空白，让复杂的正则可读性大幅提升：

pattern = re.compile(r""" ^(?:\+?86)? # 可选的国际区号 1 # 手机号首位固定为1 [3-9] # 第二位号段 3-9 [0-9]{9} # 剩余9位数字 $ """, re.VERBOSE)

这个正则在逻辑上跟^(?:\+?86)?1[3-9][0-9]{9}$完全一致，但可读性完全不是一个级别。正则一旦超过 20 个字符，建议就用 verbose 模式来写。

4.4 re 模块的隐藏坑：flags 和边界符号

先说re.match与$的配合。很多人以为^和$锚定的分别是字符串开头和结尾，但$在默认状态下还有一个行为：它匹配"字符串末尾"或"字符串末尾换行符之前的位置"。如果你用^abc$去匹配文本"abc\n"，它是能匹配成功的。如果要求严格结尾，用\Z替代$：

re.search(r'^abc\Z', 'abc\n') # 返回 None

这个细节在做文件内容校验时非常关键，一个文件末尾的换行符可能导致校验结果完全不一样。

再一个是re.DOTALL。前面提过.默认不匹配换行符，如果你的文本是多行，而你想让.匹配包括换行在内的所有字符，就加re.DOTALL。还有一种习惯写法是用[\s\S]代替.，因为[\s\S]表示"空白或非空白"，合起来就是所有字符，在任何模式下都能匹配换行符。你在很多老代码里会看到[\s\S]*?，本质就是匹配任意字符的稳妥写法。

5. 性能与灾难性回溯：正则卡死线上服务的真相

5.1 "8 秒才匹配完一行日志"的排查过程

有一次线上服务处理一条日志时耗时 8 秒，通过检查发现，问题出在一个看似简单的正则上。那个正则用来匹配某个业务编号，大致是这样：

pattern = r'^([a-z]+)+-\d+$'

乍一看没问题，[a-z]+后面还跟了+，表示整组重复。问题就出在这两个+上。当输入字符串是"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!-123"时，正则引擎会尝试分配[a-z]+到底匹配多少字符，外层的+又要决定这个组重复几次。由于末尾的!让整体匹配失败，引擎必须尝试所有可能的分组方式——这是一个指数级的回溯路径。

你可以想象你在排列一堆字符的切分方式：a|a|a、aa|a、a|aa，字符越多这种切分组合越爆炸。这就是灾难性回溯（Catastrophic Backtracking）。

5.2 灾难性回溯是怎么发生的

要理解灾难性回溯，需要知道正则引擎的匹配过程。它遇到一个量词时，优先选择"多匹配"（贪婪），然后如果后面匹配失败，就退回一个字符再试，这个退回再试的过程叫回溯。

当模式中存在嵌套量词——比如(a+)+、(a*)*、(a+|b+)+——每个外层量词都会让内层量词的结果产生组合数增长。一旦整体匹配失败，引擎就要把所有组合都试一遍，时间复杂度从 O(n) 变成指数级。这不仅仅是慢的问题，在 Python 的re模块里，遇到灾难性回溯甚至可能直接导致进程卡死，因为标准库的正则引擎没有内置超时机制。

下面这个例子，你可以本地试试，短时间内别跑太长的字符串，感受一下什么叫卡死：

import re re.match(r'^(a+)+$', 'a' * 30 + '!') # 强烈建议不要跑超过30个a，30个已经能卡好几秒

30 个字符就能卡到肉眼可感知的秒级，50 个字符就是几分钟到几十分钟量级，到 100 个字符基本是永远不会返回。

5.3 如何给正则做性能体检

排查性能问题，我有一套固定的检查顺序：

• 找嵌套量词。看到(...*)*、(...+)+、(.*)+、(.+)*这种模式，直接警惕，这是灾难性回溯的头号嫌疑。
• 用专用工具验证。把正则和测试文本贴到 regex101.com，它的右上角会显示匹配步骤数（Steps）。如果步骤数上万，说明有严重回溯问题。正常业务正则，几百步以内是健康的。
• 降低贪婪范围。把.*改成[^"]*（匹配直到遇到引号为止）这类明确字符集的做法，能从根源上减少回溯分支。
• 考虑使用原子组。Python 标准库re不支持原子组，但第三方库regex支持，语法是(?>...)。原子组的意思是：一旦内部匹配完成，就不再回头交还字符，这样能阻断灾难性回溯的威力。
• 给正则加超时保护。如果业务上无法避免复杂正则，用signal模块给整个操作设置超时，或者干脆用regex库的timeout参数：

import regex regex.match(r'^(a+)+$', 'a' * 30 + '!', timeout=0.1) # 会抛出 regex.TimeoutError

最后一条建议：能用字符串方法解决的需求，就别用正则。startswith、split、in这些内置方法性能通常比正则快一个数量级，而且不会回溯。正则适用于模式复杂到字符串方法搞不定的场景，不该大材小用。

6. 我的正则调试工作流与常用表达式清单

6.1 每次写正则我都会走的四步

很多人拿到需求就直接开始拼正则，拼完一测不对，再改再测，越改越乱。我现在的流程固定四步，基本能覆盖 90% 的场景，你直接照做就行。

第一步：明确需求的结构边界。先别写符号，用自然语言描述清楚"我要匹配的部分长什么样、前后有哪些约束、哪些部分是可变、哪些部分是固定"。比如手机号：第一位固定 1，第二位 3-9，剩下九位是数字，前后不能有多余字符。

第二步：写最小可用模式。能匹配成功最重要。此时不用管性能，哪怕全用.*都行，先跑通再说。

r'1[3-9]\d{9}'

第三步：用真实样本和异常样本测试。这一步是分水岭。真实样本验证正常需求，边界样本验证鲁棒性。我会同时准备以下测试内容：

第四步：优化与固化。确认无误后，再把模式收紧、加边界锚定、考虑可读性，提前用re.compile固化到代码里。

6.2 推荐的调试工具

我在实际工作中常用的调试工具是 regex101，它支持 Python、JavaScript、PHP、Java 等主流语言的正则引擎，左侧能实时高亮匹配结果，右侧展示分组捕获信息和匹配步骤数。这个步骤数统计是排查灾难性回溯的利器，刚才讲性能时已经提到了。

还有一个工具是 RegExr，它更轻量，适合快速验证。需要图形化理解时，可以用 Regexper 把正则语法树可视化，它对梳理嵌套分组特别有帮助。

不过要提醒一句：regex101 的 Python 模式用的是第三方regex库，不是标准库re。两者大部分行为一致，但原子组在 regex101 能跑，在标准库 re 里会报错。遇到这种情况先确认你自己代码用的哪个。

6.3 值得收藏的常用正则表达式清单

下面这些是我实际项目里反复用到的，直接贴出来供你参考。每个都经过业务验证，但不同场景可能有细微差异，使用前一定要自己测一遍。

# 手机号（中国大陆） MOBILE = r'^1[3-9][0-9]{9}$' # 带国际区号的手机号（+86为13位数字） MOBILE_WITH_CC = r'^(?:\+?86)?1[3-9][0-9]{9}$' # 邮箱（简易版，够用） EMAIL = r'^[\w.+-]+@[\w-]+(?:\.[\w-]+)+$' # IPv4 地址 IPV4 = r'^(?:(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])\.){3}(?:25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])$' # URL（HTTP/HTTPS） URL = r'https?://[^\s/$.?#].[^\s]*' # 日期格式 yyyy-mm-dd DATE_ISO = r'^[0-9]{4}-[0-9]{2}-[0-9]{2}$' # 中文字符（常用汉字范围） CHINESE = r'[\u4e00-\u9fa5]' # 中文标点 CHINESE_PUNCTUATION = r'[\u3000-\u303F]' # 匹配所有标点（中英文混合文本） ANY_PUNCTUATION = r'[^\w\s]'

这些表达式里，邮箱那个我特意选了"简易版"，因为完整的 RFC 5322 邮箱正则长达几百页，实际开发根本没必要。很多业务场景其实只需要\S+@\S+\.\S+这种级别的校验，够用就好。

再分享一个我个人的经验：把这些常用表达式放到项目的 constants.py 或者 config 文件里统一管理，不要散落在各个模块。这样如果运营商放号段、域名规则变了，只需要改一处。正则这种字符串，测试覆盖不足时很容易改一处崩一片，统一管理能避免很多线上事故。

最后，正则表达式这种东西，看十篇教程不如亲手调一个真的需求。找一个你日常工作中重复了几次的文本处理场景，把它改成正则实现，跑一遍测试用例，你会比别人背十遍语法清单都管用。我自己就是在那次给同事解决问题、把订单号提取改成一行正则之后，才算真正把正则的思维方式内化成了一种本能。