Regex.IsMatch匹配不到手机号主因未加^和$锚点导致子串误匹配，正确校验应为@"^1[3-9]\d{9}$"，提取时建议用\b防连号，并注意C#字符串转义、号段兼容及Unicode空白处理。
Regex.IsMatch 为什么匹配不到手机号？检查边界和修饰符
直接用 Regex.IsMatch("13812345678", @"1[3-9]\d{9}")
常见错误是没加字符串开头结尾锚点，导致子串误匹配（比如 "abc13812345678def" 也会返回 true）。实际提取或校验时必须加 ^ 和 $：
- 校验完整手机号：用
^1[3-9]\d{9}$ - 从文本中提取：改用
Regex.Match或Regex.Matches，不加$但建议加\b防止连在其他数字里（如 "138123456789" 会被截成前 11 位） - C# 字符串字面量要记得转义反斜杠，或用 @"" 前缀；写成
@"^1[3-9]\d{9}$"更安全 - 注意：国内手机号正则不覆盖 170/171 等虚拟运营商号段，若需兼容，把
[3-9]改成[3-9]|7[0-1]
提取邮箱时 Match.Groups[1] 为空？分组没写对
想提取 name@domain.com 中的用户名部分，却写了 @"\w+@\w+\.\w+" —— 这整个模式没分组，Match.Groups[1] 必然越界。正确做法是用圆括号明确捕获：
- 提取用户名：
@"(\w+)@\w+\.\w+"，然后取match.Groups[1].Value - 同时提取用户名和域名：
@"(\w+)@(\w+\.\w+)"，Groups[1]是用户名，Groups[2]是域名 - 邮箱正则不能只靠 \w，会漏掉
user.name+tag@gmail.com这类合法地址；基础场景可用@"[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}"，但生产环境建议用MailAddress解析而非正则校验
RegexOptions.Compiled 能不能随便加？性能有代价
看到“提升性能”就给 new Regex(pattern, RegexOptions.Compiled) 加上，结果发现首次匹配慢了 3–5 倍，还占更多内存。这不是 bug，是设计使然：
-
RegexOptions.Compiled把正则编译成 IL，适合**长期复用、高频调用**的场景（如 Web API 请求中反复解析日志） - 如果只是偶尔用一次（如配置文件读取时校验一个邮箱），用静态方法
Regex.IsMatch(input, pattern)更快，它内部缓存了常用正则 - 编译后的 Regex 实例必须手动管理生命周期；若每次 new 一个 Compiled Regex，GC 压力反而更大
中文文本里匹配失败？编码和 Unicode 类别要注意
在含中文的字符串里找手机号，比如 "联系人：张三，电话：13912345678"，用 @"1[3-9]\d{9}" 却匹配不到 —— 很可能是前后有全角空格、中文冒号或换行符干扰。
- 用
\s不一定能匹配中文全角空格（U+3000），建议显式写[\s\u3000] - 提取时加
RegexOptions.IgnorePatternWhitespace没用，那是用来忽略正则里的空白和注释的，不是处理文本空白 - 更稳妥的做法是预处理：用
input.Replace(" ", " ").Replace("：", ":")清洗常见中文标点，再匹配 - 如果必须支持 Unicode 字母数字（比如邮箱用户名含中文），用
\p{L}和\p{N}替代\w，但注意邮箱标准本身不支持中文用户名
正则写得越“准”，越容易卡在边界情况里；手机号和邮箱的规范本身就在变，别指望一条正则通吃所有业务场景。
