做C#开发的朋友遇到需要从一段文本里找出手机号、解析协议字段、批量替换敏感信息的时候第一个能想到的方案多半就是正则表达式。但正则表达式在C#里用起来有不少细节和Python、JavaScript不太一样最典型的坑就是字符串里的反斜杠转义还有Match、Matches、IsMatch这几个方法各自的行为差异。我最早接触C#写上位机时就因为在串口报文里提取温度值用正则一直匹配不到排查了半天才发现是C#字符串中\d写成了普通字符串里的d那种挫败感到现在还记得。这篇文章我把C#里正则表达式最常见的几种方法整理出来包括静态方法和实例方法的取舍、常用正则语法、实际开发中怎么封装一个顺手的小工具类以及我踩过的各种坑。不管你是刚入门C#还是已经写了好几年WinForm、WPF只要还在和字符串打交道这篇文章多少能帮你省点时间。1. 选型思路什么时候用正则怎么选Regex的调用方式1.1 字符串方法一长串正则帮你把规则收拢成一个表达式C#的String类自带IndexOf、Substring、StartsWith、Contains这些方法简单场景下确实够用。比如判断一个字符串是否以数字开头可以写char.IsDigit(input[0])但如果要判断“这个字符串是不是一个合法的手机号”“从一段报文里提取所有温度值”“把日志中的IP全部替换成脱敏格式”再用Substring配合IndexOf就非常痛苦了逻辑会变成十几个if和一串魔法数字。正则表达式的价值是把这些复杂的查找规则浓缩成一段字符串由Regex引擎负责解释和执行。C#的System.Text.RegularExpressions命名空间下核心就是Regex类它内部把正则表达式编译成一系列指令再对输入字符串进行匹配。用一句话总结当你需要按照“某种模式”而不是“某个固定文本”去查找、提取、替换时就应该考虑正则。不过也不是说正则万能。如果条件只是判断固定字符是否存在IndexOf比正则快得多如果要从非常规整的固定格式字符串里截取数据或许直接用Split更简单。我自己的判断标准是规则里只要出现“任意”“数字”“字母”“开头结尾”“长度范围”这类词就值得用正则如果只是“等于某个词”直接用Equals或Contains。1.2 静态方法还是实例方法别搞错性能预期Regex类既提供了静态方法也支持创建实例。初次接触的人容易疑惑Regex.IsMatch(input, pattern)和Regex reg new Regex(pattern); reg.IsMatch(input)到底有什么区别静态方法每次传入patternCLR内部会对这个正则进行解析和编译同时缓存最常用的15个模式。也就是说如果同一个pattern反复调用静态方法也能利用缓存不用每次重新编译。但缓存有上限一旦超过15个旧的模式会被淘汰可能又触发重新编译。对于大多数业务代码静态方法足够用而且不用考虑释放资源。但如果你在一个循环里对大量文本执行同一个复杂正则或者这个正则本身非常复杂我更建议显式创建Regex实例可以配合RegexOptions.Compiled让引擎一次性把正则编译成更高效的IL指令后续匹配速度更快。代价是第一次编译耗时更长、占用内存更多。简单来说瞬时少量匹配用静态方法高频复用用实例方法。我们还要注意一个关键点不管静态还是实例默认都不支持超时设置。.NET Core 2.0以上版本如果在无超时情况下遇到灾难性回溯可能长时间卡死。所以面对不可控的输入最好在实例化Regex时指定超时时间或者在Regex构造函数里传入Timeout。2. 常用方法逐个拆解顺带把C#正则语法捋清楚2.1 Regex.IsMatch只需要判断“有没有匹配上”IsMatch方法最常用在表单校验、权限判断这类只关心“是否符合规则”的场景。返回bool用法很简单using System.Text.RegularExpressions; bool isValid Regex.IsMatch(13800138000, ^1[3-9]\d{9}$); Console.WriteLine(isValid); // True注意pattern前面的这表示C#原生字符串反斜杠不再被C#字符串转义处理。没有的话你得写^1[3-9]\\d{9}$一旦正则复杂这种双重转义很容易让人崩溃。IsMatch默认匹配的是“输入字符串的任意位置”不是“整个字符串必须完全匹配”。这也是新手最容易踩的坑。比如你写Regex.IsMatch(abc123def, \d{3})返回的是True因为123在中间也算匹配。如果你要校验整个字符串都是数字必须像上面那样加^和$锚定。必要时还要考虑\A和\z的区别不过常规场景^和$配合RegexOptions.Multiline已经够用。2.2 Regex.Match提取第一个匹配以及匹配位置和分组Match方法返回一个Match对象它不仅仅告诉你匹配到了什么还能告诉你位置、长度和各个分组的值。一个典型的例子是在传感器报文中提取温度string data ID:1001;TEMP:25.6;HUM:60; Match m Regex.Match(data, TEMP[:](?temp\d(\.\d)?)); if (m.Success) { string tempValue m.Groups[temp].Value; Console.WriteLine(tempValue); // 25.6 }这里的(?temp...)是命名分组取出数据时不用记忆Group下标代码自文档化特别适合多个字段一起提取的场景。注意我说过Match只返回第一个匹配如果你需要所有匹配要用Matches。还有一点Match对象有一个Index属性和Length属性可以用来定位原字符串中匹配的位置。比如你想把匹配到的部分高亮显示就可以用这两个属性在原字符串中截取或替换。2.3 Regex.Matches循环拿到所有匹配Matches返回MatchCollection适合统计、提取所有满足条件的结果。比如从日志里找出所有IP地址string log 2025-06-01 10:00:01 192.168.1.1 GET /api 200\n 2025-06-01 10:00:02 10.0.0.8 GET /api 500; MatchCollection matches Regex.Matches(log, \b(?:\d{1,3}\.){3}\d{1,3}\b); foreach (Match m in matches) { Console.WriteLine(m.Value); }这里用\b做单词边界防止把“192.168.1.1111”里的“192.168.1.111”也算进去。注意(?:...)是非捕获组因为我们不需要这个组的值只要整体匹配结果。MatchCollection是惰性求值的也就是说foreach遍历到哪个位置才计算哪个位置不需要一次性把结果全部存下来。但如果你要在遍历过程中动态修改原字符串或者字符串非常大建议先把结果复制到列表避免迭代器失效或性能问题。例如Liststring ips matches.CastMatch().Select(m m.Value).ToList();。2.4 Regex.Replace字符串替换也能按规则来Replace常常用于脱敏、格式化、清理脏数据。手机号脱敏是最经典的场景string input 联系 13800138000 或者 13912345678; string masked Regex.Replace(input, (?\d{3})\d{4}(?\d{4}), ****); Console.WriteLine(masked); // 联系 138****8000 或者 139****5678这里的(?...)是后行断言(?...)是先行断言它们只参与位置判断不消耗字符所以替换时不会把边界数字吞掉。C#里的正则替换模式还有$1、${name}这些引用方式例如string result Regex.Replace(abc-def, (\w)-(\w), $2-$1); // result def-abc注意在替换模式里$符号有特殊含义如果目标字符串里本身包含$字符替换时可能被转义。这种情况可以用$$表示一个普通的美元符号或者用Regex.Replace的重载传入MatchEvaluator委托自己控制替换逻辑避免一堆转义闹心。2.5 Regex.Split把字符串按正则规则切开Split和String.Split类似但String.Split只能按固定字符Regex.Split可以按模式切分。比如把一段由分号、空格、竖线分隔的数据拆开string input a; b |c d; string[] parts Regex.Split(input, [;|\s]); // parts [a, b, c, d]这个方法的坑在于如果正则里用了捕获组Split的结果会包含捕获到的内容。比如Regex.Split(a1b2c, (\d))的结果是[a, 1, b, 2, c]有时候这符合预期有时候完全不是你想要的。要避免这种情况请使用非捕获组(?:...)。这也是我在处理表格或配置文本时经常踩坑的地方。2.6 C#正则在语法上有什么不一样C#的正则语法总体和Perl兼容大部分网上找的表达式能直接拿到C#里用。但有几个细节需要注意C#字符串里反斜杠要么写成\\要么用原始字符串。推荐后者\d{11}比\\d{11}清晰太多。C#支持命名分组语法是(?name...)同时也兼容Python式的(?Pname...)。访问时优先用m.Groups[name]而不是m.Groups[1]可读性完全不一样。正则选项里RegexOptions.IgnoreCase对应其他语言里的i修饰符RegexOptions.Multiline会让^和$匹配每行的开头结尾RegexOptions.Singleline让.匹配换行符。这三个最常用尤其在解析多行日志时需要特别注意。3. 实操过程我封装的RegexHelper和三个实战案例3.1 先封装一个顺手的小工具类我不会把正则逻辑散落在各个窗体或Service里那样时间长了根本不知道哪段规则是干嘛的。通常会先封装一个简单工具类把常用功能收敛起来using System; using System.Collections.Generic; using System.Text.RegularExpressions; public static class RegexHelper { private static readonly TimeSpan MatchTimeout TimeSpan.FromSeconds(2); public static bool IsMatch(string input, string pattern, RegexOptions options RegexOptions.None) { if (string.IsNullOrEmpty(input) || string.IsNullOrEmpty(pattern)) return false; return Regex.IsMatch(input, pattern, options, MatchTimeout); } public static string GetMatchValue(string input, string pattern, string groupName null) { if (string.IsNullOrEmpty(input) || string.IsNullOrEmpty(pattern)) return string.Empty; Regex regex new Regex(pattern, RegexOptions.None, MatchTimeout); Match match regex.Match(input); if (!match.Success) return string.Empty; if (!string.IsNullOrEmpty(groupName)) return match.Groups[groupName].Value; return match.Value; } public static Liststring GetMatchValues(string input, string pattern, string groupName null) { Liststring result new Liststring(); if (string.IsNullOrEmpty(input) || string.IsNullOrEmpty(pattern)) return result; Regex regex new Regex(pattern, RegexOptions.None, MatchTimeout); foreach (Match match in regex.Matches(input)) { result.Add(string.IsNullOrEmpty(groupName) ? match.Value : match.Groups[groupName].Value); } return result; } public static string Replace(string input, string pattern, string replacement) { if (string.IsNullOrEmpty(input) || string.IsNullOrEmpty(pattern)) return input; Regex regex new Regex(pattern, RegexOptions.None, MatchTimeout); return regex.Replace(input, replacement); } }这个工具类至少有几点好处统一了超时时间避免正则陷入死循环把常用的操作精简成一行调用返回值处理得比较保守不会因为匹配不上就抛异常。你完全可以根据自己项目需要加更多方法比如TryGetMatchValue之类的。3.2 实战案例上位机串口报文里提取多个字段很多C#上位机项目离不开串口和TCP通信比如读取温湿度传感器数据。假设串口收到的一帧数据是RCV: ID1001, TEMP25.6, HUM60.2, STATUSOK我需要把ID、温度、湿度、状态都提取出来。如果用IndexOf和Substring每取一个字段都要算位置报文格式一旦有小改动就崩。用正则配合命名分组就比较优雅string frame ID1001, TEMP25.6, HUM60.2, STATUSOK; string pattern ID(?id\d),\s*TEMP(?temp\d(?:\.\d)?),\s*HUM(?hum\d(?:\.\d)?),\s*STATUS(?status\w); Match m Regex.Match(frame, pattern, RegexOptions.IgnoreCase); if (m.Success) { int id int.Parse(m.Groups[id].Value); double temp double.Parse(m.Groups[temp].Value, System.Globalization.CultureInfo.InvariantCulture); double hum double.Parse(m.Groups[hum].Value, System.Globalization.CultureInfo.InvariantCulture); string status m.Groups[status].Value; Console.WriteLine($ID{id}, TEMP{temp}, HUM{hum}, STATUS{status}); }你可能会问为什么温度的正则写成\d(?:\.\d)?而不是\d\.\d因为温度可能是整数25也可能是带一位或多位小数25.6我希望能同时兼容。(?:...)?表示整个小数部分可有可无。另外解析浮点的时候一定要考虑系统区域设置。在某些语言的系统上小数点分隔符是逗号直接double.Parse可能解析失败所以我这里显式用了InvariantCulture。这是上位机国际化和多语言环境下的常见隐藏坑。3.3 实战案例日志批量提取并统计统计日志里每个IP出现多少次也是正则高频使用的场景。比如有一个访问日志文件每行包含IP和时间我要统计一段时间内哪些IP最活跃。var ipCounts new Dictionarystring, int(); MatchCollection matches Regex.Matches(logText, (?ip\b(?:\d{1,3}\.){3}\d{1,3}\b)\s(?time\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2})); foreach (Match m in matches) { string ip m.Groups[ip].Value; ipCounts.TryGetValue(ip, out int count); ipCounts[ip] count 1; } var topIps ipCounts.OrderByDescending(kv kv.Value).Take(5); foreach (var kv in topIps) { Console.WriteLine(${kv.Key}: {kv.Value}次); }这里我用命名组(?ip...)和(?time...)把IP和时间一起提取然后在循环里只取需要的组。如果你还关心访问时间分布可以顺手把time也存进去。这种做法的好处是不需要在正则之外再做一次字符串二次拆分逻辑更集中。3.4 实战案例批量替换脱敏脱敏需求在C#写软件里太常见了。不管是手机号、邮箱还是身份证号核心思路都是“保留头和尾中间打码”。我经常用MatchEvaluator实现灵活的替换string input 联系13800138000备用13912345678; string masked Regex.Replace(input, 1[3-9]\d{9}, match { string value match.Value; return value.Substring(0, 3) **** value.Substring(7); }); Console.WriteLine(masked); // 联系138****8000备用139****5678MatchEvaluator的好处是替换逻辑可以写任意代码不用去记正则替换模式里的$1、$2。尤其当你要根据匹配内容动态生成结果的时候比纯字符串替换模式直观很多。4. 常见问题与排查技巧实录4.1 为什么正则明明看着没问题就是匹配不上这类问题占了我日常答疑的六成以上。归纳下来常见的就这几种转义错误是C#新手最常踩的坑。只要看到pattern里反斜杠后面跟着字母首选检查一下是否写了。比如\d在C#字符串里实际上是d根本不会匹配数字正确写法必须是\d或\\d。锚定问题。^匹配的是整个字符串的开头$匹配整个字符串的结尾。在默认模式下Regex.Match(abc\n123, ^123)匹配不到因为123不在字符串开头。如果需要逐行匹配必须加上RegexOptions.Multiline。.匹配不到换行也是个容易忽视的点。默认.不匹配\n如果要匹配跨行内容要么用[\s\S]要么加RegexOptions.Singleline。很多时候你看到一段文本明明有数据正则在流式读取时却匹配不到多半就是这个原因。隐藏字符。串口报文经常以\r\n结尾如果正则里用了$字符串结尾其实是\n但$在.NET默认匹配的是整个字符串结尾可能会受\r影响导致$前的老实说容易出错。更保险的是在正则里显式写\r?\n或用RegexOptions.Multiline后按行处理。编码问题。如果你从文件或网络读取文本时指定错了编码中文全部变成乱码正则里写的中文关键字自然匹配不上。这种情况不是正则的问题是编码的问题。排查时优先用UTF-8读取或者用十六进制看原始字节。4.2 遇到“灾难性回溯”程序卡死怎么救当一个正则里出现多个嵌套量词比如(a)输入又是大量不满足条件的文本时正则引擎会尝试海量路径导致CPU飙到100%程序像死了一样。这就是著名的“灾难性回溯”。C#的Regex类允许你设置超时。给Regex构造函数传入TimeSpan.FromSeconds(1)如果匹配开销超过1秒会抛出RegexMatchTimeoutException。所以不管用静态还是实例我都建议显式传入超时时间。特别注意如果使用RegexOptions.Compiled首次编译的时间不算在超时内超时只计算匹配过程本身。除了设超时另外一个实用习惯是不要试图用一个超级复杂的“天书正则”解决所有问题。比如你要从HTML里提取特定内容别写一个覆盖所有换行和嵌套标签的巨长表达式先通过正则把候选片段缩小范围再用String、HtmlAgilityPack等工具做结构处理。宁可多写几行也别让一个正则拖垮整个程序。4.3 几个能直接抄作业的细节技巧正则写好后先放在小样本上验证再放上生产环境。我自己习惯写一个临时控制台用Console.WriteLine把每个匹配结果打印出来确认无误后再迁移到正式代码。很多人喜欢用在线正则工具可以但从在线工具复制到C#只要没加转义问题几乎必现所以务必在C#里再跑一遍。分组名就是注释。在复杂正则里尽量给每个捕获组取有意义的名字。不要用m.Groups[1]、m.Groups[2]过一周你自己都分不清哪个是哪个。命名组还让代码可以通过nameof或者常量引用重构时更安全。截取字符串优先用正则分组。热搜里有个问题问“c#语言怎样截取字符串”本质上很多人想从固定格式文本里取字段比如“从A和B之间取出内容”。用正则分组可比固定Index和Substring稳得多特别是在分隔符长度可能变化的时候。例如title(?title.*?)/title就可以提取HTML标题配合非贪婪.*?不会把多个title标签吞到一起。手机号码正则别写错位数。网上经常有人问“13位数字手机号码正则怎么写”其实是把手机号位数记错了。中国大陆手机号是11位以1开头第二位是3-9所以标准写法是^1[3-9]\d{9}$。如果你真的要匹配任意13位数字那是^\d{13}$但不要把它叫“手机号正则”否则需求和实现就错位了。4.4 C#常用正则速查表下面这张表我整理了平时写C#软件时最常用到的几个正则都验证过可以直接复制后用...包起来用途正则表达式C#写法示例/提示11位手机号^1[3-9]\d{9}$校验手机号任意13位数字^\d{13}$业务编号邮箱常用简化版^[\w.-][\w-]\.[\w.-]$大多数场景够用IPv4地址\b(?:\d{1,3}\.){3}\d{1,3}\b提取时不要加^$日期 yyyy-MM-dd^\d{4}-(?:0?[1-9]|1[0-2])-(?:0?[1-9]|[12]\d|3[01])$校验日期格式中文字符[\u4e00-\u9fa5]匹配单个中文字符空白行^\s*$多行模式下过滤空行URL简化https?://[\w\-./?]提取URL身份证号18位^\d{17}[\dXx]$校验格式不校验校验位提取括号内内容\((?content[^()]*)\)匹配嵌套括号内最内层内容时间的时分秒^([01]\d|2[0-3]):[0-5]\d:[0-5]\d$校验HH:mm:ss用这张表的时候提醒一下正则的校验能力和完整性永远是个平衡。比如“邮箱”这个正则你真要支持完整RFC 5322规范表达式会复杂到怀疑人生。实际业务里我一般先满足“大多数合法输入能通过、明显非法输入能拦截”然后配合后端再做一次校验即可。最后再说一个我一直保留的习惯每写一个有点复杂的正则我都会在代码旁边注释里写上一行示例比如“匹配格式TEMP25.6”或者把测试用例放到单元测试里。正则表达式这东西当时能看懂不代表三个月后还能看懂一条好的注释比十个文件都存在。希望这些内容能帮你在字符串处理和C#开发里少踩几个坑。真要遇到调不通的正则别硬扛先拆小再一个个试很快就能找到问题所在。