正则表达式实战指南：IP校验、日志抓取与多语言应用

很多人都觉得正则表达式是一套"看一遍就会、一用就废"的玄学，常常为了匹配一个IP地址，写出一长串看得懂但改不动的东西。其实正则没那么高深，它本质就是一套描述文本模式的规则语言，只是大多数教材把它讲成了语法字典，导致你背了十几个元字符，遇到真需求还是无从下手。这篇内容我打算不按章节顺序讲语法，而是围绕几个高频场景——包括校验IP、抓日志、在Delphi和C#里使用、以及日常grep过滤——把正则这套东西彻底拆开，让你知道为什么这么写、背后怎么想，以及踩坑之后怎么调。

不管你是刚接触正则的初学者，还是写过一些表达式但总觉得不踏实的开发者，我都建议你带着"我要处理什么样的文本"这个问题来读。正则不是背出来的，是对着真实数据一遍遍试出来的。

1. 先搞清楚正则到底解决了什么问题

1.1 从一次数据清洗说起

我曾经需要从几万行服务器日志里把访问者的IP、请求路径和状态码分别提取出来。如果靠肉眼去翻，或者写一堆Substring加IndexOf，不仅代码难看，遇到格式稍微变化的行还会直接崩。这时候正则是唯一合理的选择：你不需要告诉程序"第3个空格后面是IP"，你只需要描述"我要的是一个由点分隔的四段数字"。

这就是正则的核心价值：用一套简洁的符号系统，把文本模式变成可执行的匹配规则。它的本质是形式语言理论在工程里的落地——你可以把它理解成一种专门用来描述字符串集合的微型语言。像\d{1,3}(\.\d{1,3}){3}这种写法，说白了就是在描述"1到3位数字，重复4次、中间用点隔开"这一整类字符串。

1.2 为什么不少人觉得正则难学

问题出在很多教程把正则的语法点平铺出来，却没有告诉你在真实任务里哪些是主力、哪些只是冷门补充。比如\b、(?!...)这种零宽断言，日常用得远没有.*、\d+、[a-z]频繁。我自己的经验是，先掌握20%的核心语法就足以覆盖80%的需求，剩下的完全可以在遇到具体问题时查文档。

另一个难点在于，正则的思维方式和你平时写命令式代码完全不同。写if语句，你是从第一个字符开始，逐步判断，逻辑是线性的；而正则是一整台状态机同时扫描文本，匹配结果往往是"最左最长"或"最左最短"。你心里得装着一个概念：正则引擎不是在"寻找一个匹配"，而是在"遍历所有可能，找到那个符合规则的"。理解了这一点，后面遇到贪婪、回溯这些坑就容易接受了。

1.3 先设计，再写表达式

我见过太多人上来就写一气，结果表达式复杂到自己都看不懂。其实写正则和写代码一样，应该先拆解需求，再逐步组合。

比如要校验IP地址，如果你一上来就写\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}，的确能匹配"999.999.999.999"这种非法数据，因为你的规则里没有限制数值范围。这种粗放式写法不是不能用，但在严格校验场景下就是埋雷。

更合理的做法是先把IP的格式拆成两条规则：

• 结构上：四段数字，每段由点分隔。
• 数值上：每段范围是0到255。

结构规则容易写，数值范围规则要用分组配合分支来实现。这类先拆解再组合的思路，是贯穿正则需要掌握的核心工作方法。接下来我会从语法基础开始，把每一块真正讲透，再回到这些场景去落地。

2. 正则语法核心拆解：从元字符到组合逻辑

2.1 字符匹配的三种粒度

正则处理文本的最小单位是"字符匹配"，但实际工作中，我们很少只匹配一个固定字符，更多时候需要匹配"一类"字符或"一个位置"。我习惯把常用的匹配能力分成三个粒度来记忆，这样比死记硬背元字符表清晰得多。

精确字符：直接写那个字符本身，比如a匹配字母a，5匹配数字5。这种写法简单，但局限也明显——只能匹配写死的那个字符。

字符类：用方括号[...]表示"匹配括号内任意一个字符"。比如[a-zA-Z0-9]匹配任意字母或数字。字符类内部还可以用排除符^，写成[^0-9]就表示匹配"不是数字的任意字符"。这里要注意，^在方括号内和方括号外含义完全不同——在字符类里它是否定，在模式开头它是行首锚点。

预定义字符类：也就是\d、\w、\s这套缩写。\d等于[0-9]，\w等于[A-Za-z0-9_]（部分引擎还支持Unicode），\s匹配空白符。大写形式表示否定，\D是非数字，\W是非单词字符，\S是非空白。

2.1 常见元字符速查与对比

你得根据手头任务选择合适的粒度。比如要匹配一段日志里的时间戳2024-05-20 13:45:30，最直观的方式是用字符类配合精确字符：\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}。这里虽然长，但每一段含义清晰，出问题也容易定位是年月日分还是秒的规则不对。

2.2 量词背后的贪婪与懒惰

单个字符类只能匹配一个字符，实际文本往往需要匹配"一串连续出现的字符"，这时就要用量词。*表示重复0次或多次，+表示重复1次或多次，?表示0次或1次。用量词修饰一个字符或一组字符，就构成了重复匹配。

这三个量词默认是贪婪的。贪婪的意思是：正则引擎在尝试匹配时，会先尽可能多地吞入字符，再逐步吐出来，直到满足整体匹配。

举个例子，文本是<b>hello</b>world，如果你用<.*>去匹配，得到的是<b>hello</b>而不是<b>。因为.*先贪婪地吃掉了b>hello</b>，再回溯吐出>右侧的字符来满足结尾的>。如果你想要最短匹配，就得给量词后面加?，写成<.*?>。加了?之后，引擎会尽可能少地匹配，遇到第一个>就停下来，结果就是<b>。

还有{n,m}这种区间量词，{2,4}表示重复2到4次。{2,}表示至少2次，{2}表示恰好2次。

2.2 量词选择参考表

一个我在实战里反复踩的坑是：在写日志提取规则时，如果两个字段之间的分隔不固定，用贪婪匹配很容易把后面几个字段一起吞掉。你需要学会在脑子里模拟一遍"引擎会怎样吃字符"，这比写完再反复调试效率高得多。

2.3 分组、捕获与反向引用

圆括号()在正则里不只用于改变优先级，它还会把括号内的内容捕获成一个分组。分组有两个主要用途：一是把一组字符当作整体应用量词，比如(ab)+匹配"ab"连续出现一次或多次；二是把匹配到的子内容存下来，方便后续提取或反向引用。

比如要匹配重复的英文单词（类似"the the"这种笔误），可以写成\b(\w+)\s+\1\b。\1就是对第一个分组的反向引用，表示"这里要出现和前面这个分组相同的内容"。这在很多文本编辑器里做查重很好用，但要注意，不同工具对反向引用的写法支持程度略有差异。

分组在替换操作中的价值更加明显。比如你想把"2024/05/20"统一改成"2024-05-20"，用分组捕获可以写成这样：

python复制import re
text = "日期：2024/05/20"
result = re.sub(r'(\d{4})/(\d{2})/(\d{2})', r'\1-\2-\3', text)
print(result)  # 日期：2024-05-20

Python里用\1引用分组，在替换串里同样用\1。C#的Regex.Replace方法也差不多，不过更推荐用$1这种写法。还有一点要说清楚：分组捕获是有性能开销的。如果你的分组只是为了把多个字符组合起来加量词，并不需要捕获内容，应该写成非捕获分组(?:...)。比如(?:ab)+在逻辑上和(ab)+一样能匹配，但不会保存捕获内容。

2.4 位置锚定与断言：在不消费字符的前提下做判断

锚点和断言是正则里最像"逻辑判断"的部分。^和$匹配的是位置，不是字符。配合多行模式(?m)使用时，^和$能匹配每一行的开头和结尾，这在处理多行日志时极其有用。

零宽断言则在更精细的场景派上用场。(?=...)是正向前瞻，表示"后面必须跟什么"；(?!...)是负向前瞻，表示"后面不能跟什么"。举个例子，要匹配一个后面跟着px的数字，但不把px包含进匹配结果，可以写\d+(?=px)。这在处理CSS样式、配置文件时特别好用——你只是想找到数字，并不需要把单位也抓出来。

还有后顾断言(?<=...)和(?<!...)，分别表示"前面必须是"和"前面不能是"。像从"价格: $100"里提取价格但不要$符号，可以写(?<=\$)\d+。不过要特别提醒：后顾断言在不少旧版正则引擎里不受支持，或者要求断言部分必须是固定长度。使用前建议先在目标环境里做个快速验证，避免线上代码因为引擎差异报错。

3. 实操场景一：C#里校验IP地址并计算单网段最大主机数

3.1 为什么需要自定义IP校验

你可能会想，C#自带的IPAddress.TryParse不是能校验IP吗？实测下来，它做的是"能否解析成IP地址"的校验，而不是"格式是否符合IPv4点分十进制规范"。IPAddress.TryParse("999.1.1.1")在某些环境下会返回true，因为底层的解析逻辑比较宽松。换句话说，当你需要严格校验一个输入字符串是不是标准IPv4地址时，手写一个正则是更可控的做法。

3.2 IP地址格式拆解与正则设计

先把需求摆清楚：IPv4地址是四段十进制数字，每段用点分隔，每段范围0到255。拆成正则的语言来说，需要先解决"如何匹配0到255"这个数值问题。

逐段分析：

• 一位数：[0-9]可以覆盖0到9。
• 两位数：[1-9][0-9]覆盖10到99。
• 三位数又分三档：
  • 1[0-9][0-9]覆盖100到199。
  • 2[0-4][0-9]覆盖200到249。
  • 25[0-5]覆盖250到255。

把这几档用|合并，再加上0单独处理，可以写成这样：
(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])

为了避免误匹配，还要把每段当成整体对待，不给前后多余的数字留空间。IP地址可能出现的位置前后要么是字符串边界，要么是非数字字符。所以完整的IPv4正则推荐写成：

csharp复制string ipv4Pattern = @"^(?:(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])$";

解释一下这三层结构：最外层用^和$锚定整个字符串，确保不匹配"abc192.168.1.1xyz"这种带前后缀的内容。中间用{3}把"一段数字加一个点"重复三次，最后一段不再带点。每一段数字的规则用同一个非捕获分组(?:...)来约束，既减少了重复，也避免了不必要的捕获开销。

3.3 完整C#代码实现与验证

在C#里，可以用Regex.IsMatch来做校验。IsMatch只返回布尔值，适合校验场景；如果你还要提取具体某一段，才需要用Match或Matches。

csharp复制using System;
using System.Text.RegularExpressions;

public class IpValidator
{
    private static readonly string Ipv4Pattern =
        @"^(?:(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}" +
        @"(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])$";

    private static readonly Regex Ipv4Regex = new Regex(Ipv4Pattern, RegexOptions.Compiled);

    public static bool IsValidIPv4(string input)
    {
        if (string.IsNullOrWhiteSpace(input))
            return false;

        return Ipv4Regex.IsMatch(input.Trim());
    }
}

这里有个容易被忽略的细节：我把正则对象放在静态字段里，并且加了RegexOptions.Compiled。如果你在方法内部每次都new Regex(...)，性能上会打折扣；而Compiled选项能让正则引擎在首次使用时生成更快的匹配代码，适合高频校验的场景。在低流量场景下差距不明显，但作为工程习惯，这种写法值得保留。

接下来写个测试验证一下边界情况：

csharp复制string[] testInputs = {
    "192.168.1.1",   // 合法
    "0.0.0.0",       // 合法
    "255.255.255.255", // 合法
    "256.1.1.1",     // 非法，第一段超出255
    "1.2.3.4.5",     // 非法，多了一段
    "192.168.1",     // 非法，少了一段
    "01.2.3.4",      // 这个结果取决于你更倾向于严格还是宽松
    "abc.2.3.4"      // 非法
};

foreach (var input in testInputs)
{
    Console.WriteLine($"{input} => {IpValidator.IsValidIPv4(input)}");
}

01.2.3.4这种写法，在部分老系统里会被解释为八进制，但现在的网络协议栈一般按十进制处理。如果你们系统要求严格禁止前导零，可以在每段的分组里把"0不能作为多位数开头"这个规则加进去，比如把[0-9]|[1-9][0-9]|1[0-9][0-9]...改成更严格的分支。实践里，这种细节最好在需求评审时就定下来，正则本身倒好改，关键是标准别模糊。

3.4 计算单网段最大主机数

校验出IP只是第一步，热搜词里还提到"计算其对应的单网段最大"。我理解这个问题隐藏的信息是：给你一个IP地址，再给你一个子网掩码（或者CIDR前缀长度），让你算这个子网里最多能容纳多少个主机。

先铺垫一个网络基础概念：一个IPv4地址是32位二进制数，子网掩码用连续的1表示网络位，剩下的0表示主机位。比如255.255.255.0就是前24位是网络位、后8位是主机位。单网段的最大主机数等于2^主机位数 - 2，减掉的那个2分别是网络地址和广播地址。

如果你拿到的是CIDR写法，比如192.168.1.100/24，那主机位就是32 - 24 = 8位，最大主机数就是2^8 - 2 = 254。如果你的输入是传统的点分十进制掩码，比如255.255.255.240，需要先把掩码转成二进制，数一下里面有多少个0。240的二进制是11110000，主机位是4位，所以可用主机数就是2^4 - 2 = 14。

下面是C#实现，把IP校验和掩码解析放在一起，直接跑通从字符串到主机数的全流程：

csharp复制using System;
using System.Net;
using System.Text.RegularExpressions;

public class SubnetCalculator
{
    public static (bool IsValid, int MaxHosts) CalculateMaxHosts(string ipWithCidr)
    {
        var match = Regex.Match(ipWithCidr.Trim(),
            @"^(?<ip>(?:(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}" +
            @"(?:[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5]))/(?<prefix>3[0-2]|[12]?[0-9])$");

        if (!match.Success)
            return (false, 0);

        string ipPart = match.Groups["ip"].Value;
        int prefixLength = int.Parse(match.Groups["prefix"].Value);

        if (!IPAddress.TryParse(ipPart, out _))
            return (false, 0);

        int hostBits = 32 - prefixLength;
        if (hostBits < 2)
            return (true, hostBits == 0 ? 1 : 0); // 实际可用0或极少，取决于定义

        long maxHosts = (1L << hostBits) - 2;
        return (true, (int)maxHosts);
    }
}

这里用命名分组(?<ip>...)和(?<prefix>...)让后面的提取代码变得直白，避免用索引Groups[1]、Groups[2]导致后来改表达式的时候索引对不上。我个人的经验是，只要表达式中超过两个分组，就应该用命名分组，否则代码维护就是一场灾难。另外注意计算1L << hostBits时一定要用long类型，避免int移位溢出。

3.5 为什么我坚持用正则做格式校验的辅助

上面这套代码结合了正则做格式校验和IPAddress.TryParse做解析确认，看起来似乎有点冗余。但实际上这是合理的防御性编程：正则负责形状校验，TryParse负责语义解析。两者职责不同，前者告诉你"长得像不像"，后者告诉你"能不能被系统识别"。我见过不少只用正则不用TryParse的代码，结果在IPv6、压缩格式、空格等边界输入上栽了跟头。

当然，如果你面对的不是用户输入，而是程序内部已经确认过格式的IP，那直接用IPAddress类处理会更省事。正则的定位是"入口守门员"，不是"内部解析器"。

4. 实操场景二：在grep命令里用正则做日志与代码检索

4.1 grep、egrep与正则的三种模式

Linux环境下天天要用grep，但你真的搞清楚它支持哪几种正则了吗？简单说，grep默认使用基础正则表达式（BRE），此时?、+、|、{}这些字符要被转义才表示量词和分支；如果你用grep -E（等价于egrep），就切换到扩展正则表达式（ERE），这时候?、+、|不需要转义。还有grep -P启用PCRE（Perl兼容正则），它能使用更多高级语法。

很多人在这上面吃过大亏：在脚本里写好一个正则，直接grep跑出来结果不对，搜了半天最后发现是忘记加-E。所以我的习惯是在脚本里始终显式写grep -E，除非有特殊理由用默认模式。

4.2 实际案例：从access.log里提取特定IP段的请求

假设你在调试一个线上问题，怀疑某个IP段的请求量异常，日志是标准Nginx access.log。你需要把所有来自192.168.1.0/24网段、且请求路径包含/api/v1/order的行筛出来。

命令可以这样写：

bash复制grep -E "192\.168\.1\.[0-9]{1,3}.*GET /api/v1/order" access.log

这里把点转义成\.很关键。如果不转义，.会匹配任意字符，那么192x168y1z100这种非法行也会被捞进来，导致结果里混进脏数据。在日志量特别大的时候，脏数据会直接影响你排查问题的思路。

再进阶一点，你可以用grep结合-o只输出匹配的那一部分，而不是整行。比如想统计日志里所有出现过的状态码：

bash复制grep -oE '"status": [0-9]{3}' app.log | sort | uniq -c | sort -rn

这条命令把"status": 200这种片段全部抓出来，然后统计频次。实际使用中，-o这个参数比很多人想象中有用得多——它把grep从"行过滤器"变成了"字段提取器"。

4.3 利用字符类过滤掉干扰项

还是以日志为例，你只想抓/api/v1/order的GET请求，但语法里如果直接写GET，可能把GETTEXT这种词也匹配上。虽然日志格式通常不会出现这种歧义，但更严谨的写法是利用字符类和边界控制：

bash复制grep -E "\bGET\b.*/api/v1/order" access.log

\b保证GET是一个独立的词。在grep的-E模式下，\b是否可用取决于grep版本和locale设置，用的时候建议先快速验证一下，比如echo "GETTEXT" | grep -E "\bGET\b"，如果能匹配出内容就说明边界符没有按预期工作，需要改用其他方案。

4.4 grep正则里容易踩的坑梳理

还有一个很多人容易忽略的细节：grep处理的是行。默认情况下，^和$锚定的是每一行的开头和结尾，而不是整个文件的开始和结束。如果你用grep -z配合空字符处理多行数据，锚定行为又不一样。在写检索命令时，脑子里始终要有"我在按行处理文本"这个前提。

5. 实操场景三：在Delphi中集成正则表达式

5.1 为什么Delphi原生不支持正则

现代开发环境大多内置正则库，但Delphi的RTL（运行时库）偏偏没有把正则作为一等公民提供。早期的Delphi版本，要么装第三方组件，要么自己封装系统API。直到Delphi XE之后，才在System.RegularExpressions单元里引入了基于PCRE的正则支持。

如果你还维护着老Delphi项目，又不想升级到XE以上，可以考虑用PerlRegEx这个经典第三方库。PerlRegEx封装了PCRE，使用起来比较接近Perl的语义，在社区里非常流行。我自己在维护一个老Delphi 7项目时就用它处理过批量文本清洗，稳定性不错。

5.2 用TRegEx完成匹配与替换

如果你用的是Delphi XE及以上版本，推荐直接用官方单元System.RegularExpressions。它提供了TRegEx静态类和TMatch、TGroup这些类型，风格跟.NET的正则很接近，熟悉C#的人上手几乎零成本。

下面这段代码演示的是：从一个文本中提取所有形如192.168.x.x的IP，并逐一打印出来。

delphi复制uses
  System.SysUtils, System.RegularExpressions;

procedure ExtractIPs(const AText: string);
var
  Regex: TRegEx;
  Match: TMatch;
begin
  Regex := TRegEx.Create('\b(?:(?:25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\.){3}' +
                         '(?:25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9]?[0-9])\b');
  Match := Regex.Match(AText);
  while Match.Success do
  begin
    WriteLn(Match.Value);
    Match := Match.NextMatch;
  end;
end;

这里我的IP段数值规则比之前C#版本略宽松，使用了[1-9]?[0-9]来匹配0到99，这样表达式能短一些，副作用是"00"这类前导零也会被匹配。在实际提取场景中通常没关系，但在严格校验场景就得用更精确的分支。

5.3 Delphi正则的替换与分组提取

Delphi里做字符串替换同样支持引用分组。以把"2024/05/20"改成"2024-05-20"为例：

delphi复制function NormalizeDate(const ADate: string): string;
var
  Regex: TRegEx;
begin
  Regex := TRegEx.Create('(\d{4})/(\d{2})/(\d{2})');
  Result := Regex.Replace(ADate, '$1-$2-$3');
end;

注意替换串里用的是$1这种写法，而不是\1。这是Delphi System.RegularExpressions与Perl风格一个不小的差异，如果你是从Perl或Python转过来，很容易在这里栽跟头。

5.4 老项目使用第三方库的注意事项

如果你的项目确实停留在老Delphi版本上，需要用PerlRegEx，建议在封装层加一个壳，别让业务代码直接依赖第三方类型。比如你自己定义一个TTextRegex类或接口，内部调用PerlRegEx，以后引擎升级或替换成官方TRegEx时，只改封装层就行。

另外要注意字符编码。PerlRegEx早期版本对Unicode支持不够好，处理中文或UTF-8编码文本时可能出现乱码或匹配失败。老项目里我通常是先把字符串转成UTF-8编码的AnsiString再交给正则处理，处理完再转回来，虽然麻烦但稳定。

6. 正则调试与性能优化经验

6.1 分阶段验证的调试习惯

写复杂正则最大的痛点不是不会写，而是写完了不知道它到底匹配了哪些内容。我的习惯是分阶段验证，先匹配最小片段，再扩大到完整场景。比如要匹配一个URL，我不会直接写出完整的一长串，而是先匹配协议部分https?://，确认这一步没问题，再加域名部分[a-zA-Z0-9.-]+，最后加路径部分。每一阶段都运行一次，输入一批样本，看哪些符合预期、哪些超出预期。

线上调试最佳拍档是支持正则的文本编辑器或在线测试工具。你可以准备三组文本：一组是必须匹配的正样本，一组是必须排除的负样本，还有一组是边界样本。写完正则后逐组测试，这样比肉眼检查可靠得多。

6.2 正则性能的三个隐形杀手

正则写不好，在数据量小的时候看不出问题，一旦跑在几百万行的日志上，性能差距天壤之别。我梳理了三个最常见的性能杀手：

灾难性回溯：当正则包含嵌套量词或者多个分支，且文本结构复杂时，引擎可能会尝试海量路径。比如(a+)+$去匹配一串不含结尾a的字符，引擎会反复尝试不同分组方式，产生指数级匹配路径。避免办法是：尽量用原子组(?>...)或占有量词*+（在支持PCRE的引擎中），或者简化为a+$这种无歧义的写法。

过度使用通配符：.*在日志解析里太方便了，但有时它会吃掉大量字符再回溯。能限定范围就限定范围，比如用[^;]+来匹配直到分号的内容，远快于用.*;。

无关的捕获组：前文提过，捕获组是要存内容的，性能开销比非捕获组大。如果你不需要反向引用，直接用(?:...)。

6.3 不同语言中正则书写风格差异

正则语法在不同语言里不是100%通用的。比如：

• C#和Java里，测试一个字符串是否匹配整个输入，通常用Regex.IsMatch(input, pattern)配合^和$，或者用\A和\z来锚定。
• Python中需要用re.fullmatch才能实现"C#里从头到尾匹配"的效果，单纯用re.match只从头匹配，re.search则是在任意位置找匹配。
• JavaScript里，^和$在默认情况下只匹配整个字符串首尾，但在多行模式下就变成匹配行首行尾，行为差异很容易让经验不足的人写上半天。

我建议每个开发者都给自己维护的代码里留一个"写法映射表"——记录常用模式在当前主力语言里应该怎么写、加了什么参数。这不丢人，反而能避免不少低级错误。

6.4 关于调试工具的一个真诚建议

不要盲目依赖某一个在线工具，因为不同工具默认的正则引擎和参数（是否区分大小写、是否多行、是否全局匹配）不同，你在网页上测着没问题，拿到代码里跑却发现结果各异。我通常是先在编辑器里用样本数据过一遍，再写最小测试程序验证一次，最后才把正则合入业务代码。对重要正则，我还会把正样本和负样本写成单元测试固定下来，防止后续有人改坏。

6.5 常见问题速查表

这个表我建议截图保存，基本都是日志解析、表单校验、文本清洗场景里高频出现的问题。有些问题看起来不复杂，但一旦触发，排查起来非常浪费时间。

7. 关于正则的日常维护，我的几条经验

正则表达式写在代码里，天然存在可读性差的问题。几个月之后再看自己写的一大串模式，你很可能完全想不起来当初的逻辑。为此我有几条自觉很实用的习惯：

控制表达式的长度和复杂度。如果一个正则超过一到两行，我会尝试把它拆成多个小型正则，通过多次匹配或条件判断完成目标。比如同时校验IP和端口号，可以拆开分别校验，再用代码判断组合关系，而不是硬写一个超复杂模式。

复杂表达式必须写注释。在使用正则的代码位置上方，用注释把需求翻译成人话。例如：

csharp复制// 匹配IPv4地址：四段0-255的数字，用点分隔，字符串严格整体匹配
// 每段范围拆成单/双/三位数三档，再合并边界值
string ipPattern = @"^(?:...)$";

把常用正则沉淀为工具类或配置文件。同一个正则可能在多个项目里复用，比如邮箱格式、手机号、身份证号这些。用工具类集中管理，别复制粘贴到各个模块，不然改一处规则要全局搜索替换。

正则只做格式层校验，不做业务层判断。比如判断一个用户输入是否是邮箱，正则可以说"看起来像个邮箱"；但判断这个邮箱是否真实存在、是否已被注册，那是业务系统的职责，正则做不到也不该做。把正则放到合适的位置，整个架构才会清爽。

最后再分享一个具体技巧：调试正则时，把每一部分单独用圆括号包起来，用分组命名来定位问题。我在处理一段特别乱的日志格式时，会用(?<ip>\d+\.\d+\.\d+\.\d+) - - \[(?<time>[^\]]+)\]这种方式给每个字段起名字，然后用测试程序打印每个分组的值，一下子就能看出哪一段规则匹配错了，比盯着整串正则反复揣摩高效得多。