1. 正则表达式到底是什么先搞清楚它在解决什么问题1.1 正则表达式就是给文本写的一张“寻人启事”很多人第一次接触正则表达式是被“头疼”两个字劝退的。一上来就是^(?.*\d)(?.*[a-z])(?.*[A-Z]).{8,}$这种天书一样的字符串瞬间想关掉网页。但我想换个角度说正则表达式本质上只是一门“描述文本长相”的语言你写出来的模式就是告诉程序一张寻人启事——你要找的东西长什么样程序就照这个长相去文本里帮你找人。举个例子。你面前有一百条日志里面混着订单号、手机号、邮箱、IP地址。你要把里面的订单号全部抠出来。手动复制粘贴当然可以但如果是十万条呢正则表达式解决的就是这类问题按模式匹配、提取、替换、分割文本。它不区分语言JavaScript、Python、Java、C# 都有正则引擎语法骨架高度一致只是 API 调用方式略有差别。这篇文章不打算搞成一本教科书。我会沿着一条更“实战”的路线走先讲清楚正则的核心组件和匹配原理再给出一份可直接查阅的语法大全然后对比四种主流语言的正则写法最后用一个真实的提取场景——提取出中间的数字及#符号后的字符串——把前面所有知识串起来。文末附上 20 个高频业务正则和 5 个我在实际开发中踩过的坑。适合所有刚接触正则、或者精通一门语言但想横向对比正则 API 的读者。1.2 五大核心组件字符、量词、锚点、字符类、分组正则表达式再复杂拆开看也就是五类东西的组合。第一类是字面字符就是你希望文本里原样出现的内容。比如你要找“abc”正则里直接写abc就行。中文字符同理订单号可以直接出现在模式里。第二类是字符类用方括号[]表示“这一位可以是括号里的任意一个字符”。[0-9]表示任意一位数字[a-zA-Z]表示任意英文字母[^\d]表示“非数字”。字符类解决的是“这一位有多种可能”的情况。第三类是量词控制前面那个字符出现的次数。*表示 0 次或多次表示 1 次或多次?表示 0 次或 1 次{n,m}表示 n 到 m 次。量词解决的是“这个字符到底会出现多少次”的不确定感。第四类是锚点它不匹配任何字符只匹配位置。^匹配字符串开头$匹配字符串结尾\b匹配单词边界。锚点的作用是限制“从哪开始、到哪结束”避免误伤。第五类是分组用小括号()把一段模式包起来形成一个整体。分组有两个作用一是把多个字符当成一个整体去加量词比如(ab)表示“ab”这个整体重复多次二是捕获内容匹配到的分组内容可以单独拿出来使用。这五类组件配合元字符.\|这类有特殊含义的符号基本覆盖了日常 90% 的需求。看不懂长正则没关系先把这五类概念记住后面所有的模式都是它们的排列组合。1.3 引擎是怎么跑的匹配、回溯与性能隐患理解正则不能只会“看”还要理解引擎在背后是怎么工作的。正则引擎拿到你的模式后会从文本的起始位置开始逐个字符尝试匹配。匹配不上就往后移动一位继续尝试直到找到匹配项或走到文本末尾。这里最关键的机制是回溯。比如模式a.*b匹配字符串abcab引擎先把.*贪婪地吞掉后面所有字符然后一步步往回退尝试找到最后一个b。这个“往回退”的过程就是回溯。回溯是正则引擎正常的工作方式但如果模式写得不好回溯次数会爆炸直接卡死程序。我举个典型的灾难性回溯例子(a)去匹配一串没有a结尾的字符串比如aaaaaaaaaaab。每一层a都有多种分配方式引擎会反复尝试组合时间复杂度从线性变成指数级。现实里我见过有人用这种模式去校验长文本线上服务直接超时。理解回溯有什么用你至少要知道量词默认是贪婪的会尽量多吃字符。如果发现正则匹配特别慢先怀疑是不是出现了大量回溯。后面第五章我会专门讲性能排查的思路。2. 正则语法大全一篇文章过完所有关键语法2.1 字符匹配与字符类精确、区间、排除正则里最常见的操作就是匹配一类字符。直接写字母、数字、中文属于精确匹配而字符类让你从“匹配某一个”变成“匹配某一类”。[abc]匹配 a、b、c 中任意一个[a-z]匹配 a 到 z 区间内的任意小写字母[0-9a-fA-F]匹配十六进制字符[^0-9]匹配非数字字符注意^在字符类内表示取反[\u4e00-\u9fa5]匹配常见中文字符的常用写法.匹配除换行符外的任意字符在 JavaScript 的s模式下也能匹配换行字符类里有一个非常容易踩的坑部分元字符在方括号内部会失去特殊含义。比如[.]匹配的就是字面上的点号不需要转义成[\.]。但[\\]、[\]]这类转义规则在不同引擎里有细微差别我的经验是在字符类里遇到\]^-时保守一点该转义就转义能避免很多莫名其妙的问题。另外提一句字符类的区间[a-z]是基于编码顺序的如果写成[z-a]大部分引擎会直接报错属于非法字符类写之前先想清楚区间的起止顺序。2.2 量词三兄弟贪婪、懒惰、占有量词是正则里最容易产生“预期之外结果”的部分因为默认行为和你直觉经常不一样。默认的*、、?、{n,m}都是贪婪的。所谓贪婪就是引擎在满足整体匹配的前提下尽量匹配更多的字符。举个典型场景用.*去匹配say hello贪婪模式下它会匹配整个say hello因为两个引号之间的一切都被.*吞掉了。这不是 bug这是正则的默认行为。如果你只想匹配say就需要把量词改成懒惰模式写法是在量词后面加一个?.*?。懒惰模式让引擎在满足整体匹配的前提下尽量少匹配字符找到第一个右引号就停。还有占有模式在量词后加比如.*、a。占有模式的特点是匹配过的字符不会吐出来参与回溯速度更快但能用的引擎有限而且一旦不匹配就直接失败不会尝试其他路径。日常开发中用得不多但性能敏感场景值得了解。我的建议很简单只要你在用.*去提取内容先问自己是想要“第一个结束位置”还是“最后一个结束位置”然后选择贪婪或懒惰写法别靠猜。2.3 分组、反向引用与断言正则的“记忆”能力小括号做分组时匹配到的内容会被引擎记住这叫捕获组。捕获组从 1 开始编号模式里第几个左括号就是第几组。你可以在替换时用$1或\1引用它这就是反向引用。比如要把2024-03-15改成15/03/2024用(\d{4})-(\d{2})-(\d{2})捕获三组替换成$3/$2/$1Python 里是\3/\2/\1细节差异后面讲。捕获组让“提取”和“重组”变成一件非常简单的事。如果分组只是为了划定范围、不想捕获内容可以用非捕获分组(?:...)。它不会占用捕获组编号性能也略好适合用在“只需要分组不关心内容”的场合。断言是另一类强大的能力分前瞻和后顾两种每种有正反两个方向(?...)正向前瞻右边必须是这个内容(?!...)负向前瞻右边不能是这个内容(?...)正向后顾左边必须是这个内容(?!...)负向后顾左边不能是这个内容断言不消费字符只做“检查”。最经典的应用是密码强度校验(?.*\d)表示“后面必须出现一个数字”但整体匹配时数字不会被吞掉只是确认存在。后顾断言在不同语言的支持情况有差异。JavaScript 早期版本不支持后顾现在主流环境基本都支持了Python 的re模块要求后顾断言必须是固定长度不能用(?\d)这种不定长写法。写跨语言正则时后顾是最容易在不经意间触发兼容性问题的地方。2.4 语法速查总表建议收藏下面这张表覆盖了我日常写正则时最常用到的语法可以当速查卡用语法含义示例a字面字符 acat匹配“cat”.任意字符默认不含换行c.t匹配“cat”“cbt”[abc]a、b、c 中任一[cb]at匹配“cat”“bat”[^abc]非 a、b、c 的任一字符[^0-9]匹配非数字\d数字等价[0-9]部分语言默认含 Unicode 数字\w字母、数字、下划线等价[A-Za-z0-9_]\s空白字符空格、制表符、换行等\b单词边界\bcat\b精确匹配单词 cat^字符串开头^abc必须以 abc 开头$字符串结尾abc$必须以 abc 结尾*0 次或多次ab*匹配 a、ab、abb1 次或多次ab匹配 ab、abb?0 次或 1 次colou?r匹配 color、colour{n}恰好 n 次\d{4}匹配四位数字{n,}至少 n 次\d{3,}匹配至少三位数字{n,m}n 到 m 次\d{2,4}匹配二到四位数字(abc)捕获组(ab)匹配 ab、abab(?:abc)非捕获组(?:ab)同上但不捕获a|b或cat|dog匹配 cat 或 dog(?...)正向前瞻\d(?px)数字后必须跟 px(?!...)负向前瞻\d(?!px)数字后不能跟 px(?...)正向后顾(?\$)\d匹配 $ 后的数字(?!...)负向后顾(?!\$)\d匹配非 $ 后的数字\1/$1反向引用第 1 组(\w)\1匹配连续相同字符3. 多语言零门槛实操JavaScript、Python、Java、C#3.1 JavaScript从 / 字面量开始的常规操作JavaScript 里两种创建正则的方式字面量和构造函数。字面量写法是直接写/pattern/flags比如/\\d/g构造函数写法是new RegExp(\\d, g)。注意构造函数传字符串时反斜杠得写成双反斜杠这个转义细节经常坑到人。JavaScript 匹配相关的方法主要有四个test判断是否匹配返回布尔值exec查找匹配结果返回数组或 nullmatch在字符串上调用配合全局标志g一次性返回所有匹配replace做替换替换串里用$1引用捕获组函数回调里用参数接收捕获组。我常用的一组实践是用matchAll配合全局匹配提取所有分组。比如从文本里提取所有#标签const text 订单 #SO20240315 已发出备注 #加急; const regex /#(\w)/g; for (const match of text.matchAll(regex)) { console.log(match[1]); // 依次输出 SO20240315、加急 }JavaScript 正则还有一个细节没有s标志时.不匹配换行。处理多行日志时记得加s标志或者改用[\s\S]这种“任意字符包括换行”的写法——[\s\S]在很多语言里是通用招数因为它永远能匹配“任意东西”。3.2 Pythonre 模块与原始字符串Python 的正则入口是re模块核心函数有search查找第一处、findall返回所有匹配、finditer返回迭代器、sub替换、split分割、match从开头匹配严格说不是 search。Python 里有一个其他语言没有的友好设计原始字符串。写模式时建议一律用r...而不是...比如r\d。如果不加rPython 会把\d当普通转义序列处理在 Python 里\d等于d模式就全错了。这是我见过的新手最频繁踩的坑。Python 的捕获组替换用\1而不是$1import re text 日期2024-03-15 result re.sub(r(\d{4})-(\d{2})-(\d{2}), r\3/\2/\1, text) print(result) # 日期15/03/2024Python 的命名分组语法是(?Pname...)和其他语言常见的(?name...)不一样。提取时用match.group(name)获取。如果你要把同一段正则从 JavaScript 迁到 Python命名分组的语法差异是必须改的第一处。3.3 JavaPattern 与 Matcher 的配对关系Java 的正则分两个类Pattern负责编译正则表达式Matcher负责在具体文本上运行。这种“编译一次、多次匹配”的设计在性能上很友好适合循环场景。import java.util.regex.Matcher; import java.util.regex.Pattern; String text 订单 #SO20240315 数量 3 件; Pattern pattern Pattern.compile(#(\\w)); Matcher matcher pattern.matcher(text); while (matcher.find()) { System.out.println(matcher.group(1)); // SO20240315 }Java 的matches()方法要求整串完全匹配而find()是“找到子串即可”。很多人初次使用时分不清这两个方法导致正则明明“看着能匹配”matches()却一直返回 false。如果要做子串提取用find()加group()如果要做整串校验用matches()。Java 替换用replaceAll替换字符串里用$1引用捕获组。另外 Java 正则的命名分组语法是(?name...)在模式里用\kname反向引用字符串替换里用${name}。3.4 C#Regex 静态方法与命名分组C# 的System.Text.RegularExpressions命名空间下有一个Regex类静态方法Regex.Match、Regex.Matches、Regex.Replace、Regex.IsMatch可以直接调用简单场景不用 new 对象。频繁执行时建议用Regex实例或RegexOptions.Compiled预编译提升性能。C# 的命名分组语法是(?name...)和后顾断言(?...)很像但含义完全不同。命名分组提取时用match.Groups[name].Valueusing System.Text.RegularExpressions; string text 编号 #A123 数量 89 件; Match m Regex.Match(text, #(?tag\w)); if (m.Success) { Console.WriteLine(m.Groups[tag].Value); // A123 }C# 写正则时同样建议用原义字符串...否则\d也会被编译器当转义序列处理。原义字符串里的双引号用双引号转义和普通字符串不太一样注意区分。3.5 四种语言 API 对比一览不同语言的正则引擎都源自同一套理论但 API 和语法细节各有脾气。我把日常用得最多的操作整理成一张对照表操作JavaScriptPythonJavaC#是否匹配regex.test(str)re.search(p, s)p.matcher(s).find()Regex.IsMatch(s, p)提取第一处str.match(regex)re.search(p, s)matcher.find()Regex.Match(s, p)提取所有str.matchAll(regex)re.findall(p, s)while(matcher.find())Regex.Matches(s, p)替换str.replace(regex, rep)re.sub(p, rep, s)matcher.replaceAll(rep)Regex.Replace(s, p, rep)分组引用替换$1\1$1$1命名分组(?name...)(?Pname...)(?name...)(?name...)忽略大小写i标志re.IPattern.CASE_INSENSITIVERegexOptions.IgnoreCase多行模式m标志re.MPattern.MULTILINERegexOptions.Multiline4. 实战拆解提取中间的数字和#号后的字符串4.1 需求定义先搞清楚“中间”和“#符号后”是什么意思很多正则写不出来不是不会语法而是需求没定义清楚。拿“提取出中间的数字及#符号后的字符串”这个场景说至少有三个模糊点第一“数字”指的是什么连续的一串数字还是允许带小数点和负号比如-12.5算不算一个数字第二“中间”的位置边界在哪“中间”相对于什么来说的是整段文本的中间位置还是只是说“数字夹杂在其他文字里”第三“#符号后的字符串”到哪结束是到下一个空格就停还是到行尾还是继续匹配到下一个#我的处理习惯是拿到需求先列边界条件再写正则。比如假设文本是这样的订单 #SO20240315 数量 156 件门牌号 702备注 #加急需求是提取所有连续数字156、702以及所有#后面的标签SO20240315、加急。这是最常见的理解。明确了边界正则就很容易写。4.2 数字提取的几种写法与边界处理提取连续数字最直接的写法是\d。在 Python 里import re text 订单 #SO20240315 数量 156 件门牌号 702 print(re.findall(r\d, text)) # [20240315, 156, 702]注意这里把SO20240315里的数字也提取出来了因为\d只认数字不关心它前面有没有字母。如果需求是“只提取独立数字不能是字母或汉字的一部分”就要用单词边界\b\d\b。但中文和英文环境里\b的行为有差异在中文与数字夹杂的场景\b\d\b可能不生效稳妥做法是用前后否定断言(?![\w\u4e00-\u9fa5])\d(?![\w\u4e00-\u9fa5])。这个写法复杂一些但边界控制最可靠。如果需要支持小数和负数模式要扩展成-?\d(\.\d)?但如果文本里混着2024-03-15这种日期-?会把日期拆得乱七八糟。现实开发里的常见坑是正则越通用误匹配越多。建议先明确数字格式再写模式而不是一上来就想写一个“万能数字正则”。4.3 # 符号后的字符串提取非贪婪与边界控制提取#后面的内容基础写法是#(\w)它会匹配井号后面连续的字母数字下划线。回到上面的例子用#(\w)能拿到SO20240315和加急。注意\w在不少语言里只能匹配英文字母、数字、下划线不包含中文。要匹配中文标签需要改成#([\w\u4e00-\u9fa5])或者直接用#\S匹配“井号后所有非空白字符”。#\S的问题在于它会吃到下一个标点。比如文本是“备注 #加急谢谢”#\S会匹配到“#加急”把逗号也吞了。如果只想吃到下一个中英文标点为止边界条件要写得更细#([^\s。,.;!?])字符类[^...]里列出的都是“不允许出现”的字符这种方式比\S更可控。还有一种常见写法是#(.?)(?:\s|$)用非贪婪模式配合空白或行尾做结束判断但要注意捕获组可能包含多余字符。我的建议是先把结束符定死再决定怎么写。“#后面的字符串”在没有额外说明时最常用的是“到空白为止”。所以#([^\s#])是我比较偏好的写法它同时排除了空白和下一个井号避免把多个标签黏在一起匹配。4.4 四个语言完整代码示例把这套逻辑落到四种语言里代码骨架如下Pythonimport re text 订单 #SO20240315 数量 156 件门牌号 702备注 #加急 numbers re.findall(r(?![\w\u4e00-\u9fa5])\d(?![\w\u4e00-\u9fa5]), text) tags re.findall(r#([^\s#]), text) print(数字:, numbers) # [156, 702] print(标签:, tags) # [SO20240315, 加急]JavaScriptconst text 订单 #SO20240315 数量 156 件门牌号 702备注 #加急; const numbers text.match(/(?![\w\u4e00-\u9fa5])\d(?![\w\u4e00-\u9fa5])/g) || []; const tags [...text.matchAll(/#([^\s#])/g)].map(m m[1]); console.log(数字:, numbers); // [156, 702] console.log(标签:, tags); // [SO20240315, 加急]Javaimport java.util.regex.*; String text 订单 #SO20240315 数量 156 件门牌号 702备注 #加急; Pattern numberPattern Pattern.compile((?![\\w\\u4e00-\\u9fa5])\\d(?![\\w\\u4e00-\\u9fa5])); Matcher numberMatcher numberPattern.matcher(text); ListString numbers new ArrayList(); while (numberMatcher.find()) { numbers.add(numberMatcher.group()); } Pattern tagPattern Pattern.compile(#([^\\s#])); Matcher tagMatcher tagPattern.matcher(text); ListString tags new ArrayList(); while (tagMatcher.find()) { tags.add(tagMatcher.group(1)); }C#using System.Text.RegularExpressions; string text 订单 #SO20240315 数量 156 件门牌号 702备注 #加急; string[] numbers Regex.Matches(text, (?![\w\u4e00-\u9fa5])\d(?![\w\u4e00-\u9fa5])) .CastMatch().Select(m m.Value).ToArray(); string[] tags Regex.Matches(text, #([^\s#])) .CastMatch().Select(m m.Groups[1].Value).ToArray(); Console.WriteLine($数字: {string.Join(, , numbers)}); // 156, 702 Console.WriteLine($标签: {string.Join(, , tags)}); // SO20240315, 加急4.5 坑点记录数字字符类在不同语言里的行为差异上面\d这种写法看起来最简单但不同语言对\d的理解其实不一样这是最容易“本地能跑、线上炸”的坑。JavaScript 的\d等价于[0-9]只匹配 ASCII 数字不匹配全角数字。Python 3 的\d默认匹配 Unicode 数字全角数字也能匹配到。Java 的\d默认也是[0-9]但开启Pattern.UNICODE_CHARACTER_CLASS后会匹配 Unicode 数字。.NETC#的\d默认会匹配 Unicode 数字类字符。如果业务数据里可能出现全角数字而且你只想要半角数字最保险的做法不是依赖\d的默认行为而是显式写成[0-9]。类似地\w在 Python 3 里默认匹配 Unicode 字母数字在 JavaScript 里默认只匹配[A-Za-z0-9_]跨语言迁移时真的要逐项核对。5. 高频业务正则与避坑指南5.1 20 个常用正则速查表我在不同项目里反复用到的正则整理成一张表。这些模式覆盖了最常见的业务场景表单校验、日志提取、数据清洗。需要说明的是下面这些正则满足“大多数正常输入”要彻底防住所有异常输入必须结合业务上下文微调。场景正则手机号中国大陆^1[3-9]\d{9}$邮箱^[\w.-][\w-](\.[\w-])$域名^(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?\.)[a-zA-Z]{2,}$IP v4^(?:(?:25[0-5]URL^https?://[\w.-](?:/[\w./?%]*)?$身份证号18位^\d{17}[\dXx]$日期YYYY-MM-DD^\d{4}-(?:0[1-9]时间HH:MM:SS^(?:[01]\d用户名字母开头允许字母数字下划线4-16位^[a-zA-Z][a-zA-Z0-9_]{3,15}$密码强度至少8位含大小写和数字^(?.*[a-z])(?.*[A-Z])(?.*\d).{8,}$邮政编码^\d{6}$车牌号新能源包含8位简化版^[京津沪渝冀豫云辽黑湘皖鲁新苏浙赣鄂桂甘晋蒙陕吉闽贵粤青藏川宁琼使领][A-HJ-NP-Z][A-HJ-NP-Z0-9]{4,5}[A-HJ-NP-Z0-9挂学警港澳]$中文姓名2-4字简化版^[\u4e00-\u9fa5]{2,4}$连续数字提取\d连续中文提取[\u4e00-\u9fa5]去除首尾空白^\s十六进制颜色值^#(?:[0-9a-fA-F]{3}金额两位小数^\d(?:\.\d{1,2})?$时间戳13位毫秒^\d{13}$双引号包裹的文本([^]*)5.2 最容易踩的 5 个坑第一个坑是转义不当。正则里的反斜杠本身就是元字符在不同语言里还要再套一层字符串转义。JavaScript 写new RegExp(\\d)会身心俱疲Python 和 C# 用原始字符串能省一半的事。记得统一用原始字符串或正则字面量不要裸写反斜杠。第二个坑是贪婪模式误伤。用.*提取内容经常把“从第一个开始到最后一个结束”一大段全部吞掉。我见过有人从 HTML 里取标签写着写着把整段 HTML 都抓出来了。遇到这类问题先把贪婪改成懒惰.*?或者把结束条件写具体[^]之类。第三个坑是中文字符匹配。很多人的第一反应是[\u4e00-\u9fa5]这个写法在 JavaScript、Python 里可用但在别的一些环境里写法不同而且它覆盖不了生僻字和扩展区。如果只是判断“有没有中文”用\p{Han}这种 Unicode 属性写法更精确但要注意不是所有引擎都支持。写之前先查文档别想当然。第四个坑是多行模式没开。^和$默认匹配的是整个字符串的开头和结尾不是每一行的开头结尾。处理多行日志时忘了加m标志或re.M结果就是匹配不到任何东西。另外注意$在多行模式里匹配的是换行前的位置有时会多算一个空位置。第五个坑是灾难性回溯。前面提过的(a)就是典型嵌套量词会让引擎走过的路径指数级增长。训练自己的“正则嗅觉”看到(.*)*、(.)、(a|a)*这类模式就要警觉能改写成非嵌套结构就改写实在无法避免就加超时机制保护。5.3 性能优化从“能跑”到“跑得快”正则不是写出来能用就完了在日志解析、批处理、大数据清洗场景里性能差别是数量级的。能用字符类就不用或[0-9]比(?:0|1|2|...|9)快得多字符类是引擎高度优化的分支结构。能锚定就尽早锚定如果确定文本开头才可能出现目标加上^让引擎直接从开头尝试而不是逐位扫描。能不用回溯就不用懒惰量词不一定比贪婪快二者只是遍历顺序不同。真正影响速度的是回溯次数减少嵌套量词才是正路。捕获组能少就少每个捕获组都意味着要记录额外信息频繁匹配时用(?:...)替代纯分组能省一点内存。大文本批量匹配时把正则编译一次复用。Java 的Pattern.compile、.NET 的RegexOptions.Compiled、Python 的re.compile都是干这个的别在循环里重复编译同一模式。性能调优的判断标准很简单先跑一个能代表真实数据规模的样本看看耗时和内存再针对瓶颈优化。不要一上来就“优化”先保证正确性。6. 写到最后几条来自实战的习惯学了语法、过了实战案例、看了速查表最后分享几条我个人在真实项目里沉淀下来的习惯。第一先列测试用例再写正则。每次接到正则需求我先写下期望匹配和不期望匹配的样本至少各三四个然后才动手写模式。正则写完后把这些样本跑一遍能少掉 80% 的返工。第二复杂正则分步写。从最简模式开始比如先写\d验证通过后再加边界限制再加前后断言。一点点往上叠每加一层跑一次测试。一次性写长正则出错了根本不知道是哪一步的问题。第三善用可视化调试工具。浏览器里用 regex101 这类工具能实时看到匹配位置、捕获组内容还会标出回溯次数和潜在的性能堆栈。看不进去长正则的时候把模式丢进可视化工具比盯着一行字符硬猜高效得多。第四建立自己的正则片段库。把邮箱、手机号、IP、日期这些反复用到的正则收集到一个文件里统一维护。不要每次现写也不要到处复制不理解的模式——来源不明的正则往往是线上故障的定时炸弹。正则这东西第一次完整跑通一个需求时觉得神奇多写几个案例之后就会觉得它其实就那几块积木在搭来搭去。关键是理解引擎怎么跑、量词怎么工作、边界怎么卡。把基本功打牢剩下的就是按照需求慢慢搭积木了。