直接用正则判断RFC 5322邮箱格式不现实，因其语法过于复杂（含嵌套引用、注释等），std::regex不支持递归或平衡组；应采用分层验证策略：先用简化正则R"(^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$)"初步筛选，再结合长度限制、点号规则及SMTP/DNS校验确认可达性。
直接用正则判断RFC 5322邮箱格式不现实
标准RFC 5322定义的Email语法极其复杂，包含嵌套引用、注释、折行、多种括号嵌套等，std::regex在C++17及之前版本不支持递归或平衡组，根本无法完整匹配。试图写一个“完全合规”的正则，要么漏判（如"a@b.c"被拒），要么误判（如"test@example..com"被放过），还可能引发灾难性回溯导致卡死。
实际项目中该用什么验证策略
生产环境推荐分层验证：先做轻量级格式过滤，再交由SMTP服务器或专用库做最终校验。重点不是“是否RFC合规”，而是“是否大概率能送达”。
- 用简洁正则快速筛掉明显非法输入，例如：
^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$—— 注意只检查基本结构，不尝试覆盖RFC所有边缘情况 - 必须额外检查长度限制：
local-part≤ 64 字符，domain≤ 255 字符，整个地址 ≤ 254 字符（RFC 5321） - 禁止连续点号：
"a..b@c.com"应拒绝；禁止开头/结尾是点号或特殊字符（如".a@b.com"） - 域名部分需进一步DNS验证（MX记录查询）才能确认可投递，但这已超出字符串判断范畴
std::regex在C++里验证邮箱的坑
C++标准库的正则引擎性能差、功能弱，且不同编译器实现差异大。GCC libstdc++在匹配长字符串时可能栈溢出，MSVC的std::regex对Unicode支持极差。更麻烦的是，C++17前不支持p{L}这类Unicode属性，无法正确处理国际化域名（IDN）。
- 避免使用
.*或+嵌套量词，比如[a-z]+@[a-z.]+在恶意输入下极易触发回溯爆炸 - 不要依赖
std::regex_match的全局锚定行为——它默认不强制首尾匹配，需显式加^和$ - 若真需要更强能力，改用
PCRE2或Boost.Regex，但会引入第三方依赖
真正可靠的方案：交给专业库或服务
自己实现RFC 5322解析器成本远超收益。成熟方案是调用经过充分测试的库：
立即学习“C++免费学习笔记（深入）”；
- 用
libemailvalidation（C）或封装它的C++ wrapper，专注做语法+DNS双重校验 - 后端服务场景下，直接发HTTP请求到验证API（如Hunter.io、AbstractAPI），它们内部跑的是真实SMTP探针
- 若仅需前端简单提示，用HTML5原生
<input type="email">+ JS轻量校验足矣，别在客户端硬刚RFC
最常被忽略的一点：即使字符串通过所有本地校验，"user@nonexistent-domain-123456789.com"依然无效——真正的邮箱有效性只能靠发送试探邮件并捕获退回（bounce）来确认。
