最常用且稳妥的邮箱验证方式是使用 regex.ismatch 配合 rfc 5322 简化正则，如 ^[a-za-z0-9._%+-]+@[a-za-z0-9.-]+.[a-za-z]{2,}$，需预编译、转义点号、限定域名后缀长度，并避免用 mailaddress 构造函数作初筛。
用 Regex.IsMatch 验证邮箱最常用也最稳妥
直接用 Regex.IsMatch 判断字符串是否匹配邮箱正则，是 C# 里最主流、最可控的方式。别迷信“一行代码搞定”的第三方库，基础验证自己写反而更清楚边界。
常见错误是照抄网上过度简化的正则，比如 ^[w-]+@[w-]+.[w-]+$ —— 它连 a@b.co.uk 都会判错，更别说带加号的 GMail 地址（user+tag@gmail.com）。
实操建议：
- 用 RFC 5322 的简化子集，兼顾准确性与可读性，例如：
^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$ - 注意
.在正则中需转义为\.，否则会误匹配任意字符 - 域名后缀长度限制为
{2,}，比硬写{2,6}更合理（.travel、.museum 都超 6 位） - 开头和结尾加
^和$，避免"abc@def.com xyz"这类字符串被误判为合法
为什么不用 MailAddress 构造函数做格式校验
MailAddress 看似“官方”，但它的构造行为不是纯格式校验：它会自动修剪首尾空格、把多个连续点替换成单点、甚至接受不带域名的本地地址（如 "user@"），导致误放行。
典型问题场景：
- 用户输入
" test@example.com "→MailAddress成功创建，但你可能想先拦住开头空格 - 输入
"user..name@gmail.com"→ 构造成功（内部归一化），而实际邮箱服务商大多拒收 - 输入
"@example.com"→ 抛FormatException，但错误信息是 “The specified string is not in the form required for an e-mail address”，不够明确
所以，MailAddress 更适合在正则初筛之后，用于后续发信前的最终解析，而不是第一道格式关。
带国际化支持（IDN）的邮箱怎么处理
如果业务要支持中文域名（如 张三@例子.中国），不能只靠 ASCII 正则。得先用 IdnMapping 把 Unicode 域名转成 Punycode，再走常规校验。
关键步骤：
- 用
new IdnMapping().GetAscii("例子.中国")得到xn--fsq088a.xn--fiqs8s - 把原始邮箱拆成本地部分 + @ + 域名部分，仅对域名部分做 IDN 转换
- 拼回
"张三@例子.中国"→"张三@xn--fsq088a.xn--fiqs8s"，再用标准正则校验 - 注意：本地部分（@前）一般仍限制为 ASCII，除非你明确支持 UTF-8 mailbox（极少见）
漏掉这步，遇到 test@公司.cn 就直接挂掉——不是正则写错了，是根本没走到正则那步就抛异常了。
性能敏感场景下正则要不要预编译
高频调用（比如 API 请求里每条都校验）必须用 static readonly Regex，否则每次 new Regex 都有明显开销。
正确写法：
private static readonly Regex EmailRegex = new Regex(
@"^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$",
RegexOptions.Compiled | RegexOptions.IgnoreCase);
容易踩的坑：
- 漏掉
RegexOptions.Compiled：解释执行慢 3–5 倍（尤其短字符串多时） - 在方法内 new Regex：GC 压力大，且无法复用编译结果
- 用
string.Split('@')手动拆分再校验——看似简单，但绕过正则引擎优化，且难覆盖嵌套点、转义等边界
正则本身不是性能瓶颈，滥用才是。预编译一次，后面几千次调用都省事。
