Regex.Match() 最常用但容易忽略返回值检查
调用
Regex.Match()后,它**总是返回一个
Match对象**,哪怕没匹配上——此时
Match.Success为
false,
Match.Value是空字符串。很多人直接取
.Value导致逻辑出错。 务必先判断
match.Success再访问
match.Value或
match.Groups单次匹配用
Match;想获取所有匹配项,改用
Regex.Matches()返回
MatchCollection如果正则含捕获组(如
(d+)),通过
match.Groups[1].Value取第一个括号内容,索引从 1 开始,
Groups[0]是整个匹配串
var input = "ID: 12345";
var match = Regex.Match(input, @"ID:s+(d+)");
if (match.Success) {
Console.WriteLine(match.Groups[1].Value); // 输出 12345
}RegexOptions 枚举影响匹配行为的关键细节
不传
RegexOptions时默认区分大小写、不忽略空白、不支持内联注释。几个高频选项组合常被误用:
RegexOptions.IgnoreCase:让
a匹配
A,但注意它**不影响 Unicode 大小写规则**(比如土耳其语的
i/
İ)
RegexOptions.Multiline:仅改变
^和
$的行为(使其匹配每行首尾),**不影响
.是否匹配换行符**——那得用
RegexOptions.Singleline
RegexOptions.Compiled:提升重复使用的正则性能,但首次编译开销大,且会阻止 JIT 内联优化;只推荐在热路径、固定正则、长期存活的场景下使用
Match.NextMatch() 比 Matches() 更省内存的场景
当输入文本极大(如几百 MB 日志)、而匹配结果稀疏(比如每万行才一个目标),用
Regex.Matches()会一次性构建全部
Match对象,内存压力陡增。这时应迭代调用
Match.NextMatch(): 从第一次
Regex.Match()开始,循环调用
nextMatch = currentMatch.NextMatch()每次只保留当前一个
Match实例,GC 压力小 注意
NextMatch()在末尾返回的
Match对象,其
Success为
false,需显式判断退出
var match = Regex.Match(largeText, @"ERROR");
while (match.Success) {
Console.WriteLine($"Found at {match.Index}");
match = match.NextMatch();
}正则字符串里反斜杠的双重转义陷阱
C# 字符串字面量和正则引擎都吃反斜杠。写
d时,你得决定是用逐字字符串(
@"")还是普通字符串: 用逐字字符串:
@"d+"→ 正则收到的就是
d+(推荐,直观) 用普通字符串:
"\d+"→ 第一个 转义第二个 ,最终正则也收到
d+混用会翻车:比如
@"C: emp"在正则里是错的路径写法,因为
被解释成制表符;此时必须写成
@"C:\temp"或
"C:\\temp"
最易错的是匹配反斜杠本身:正则要写
\\(四个),逐字字符串写成
@"\\"(两个),普通字符串写成
"\\\\"(八个)——别硬记,统一用
@""+ 双反斜杠最稳。
