c++oding="utf-8" ?>
c++标准库不提供rfc 5322邮箱验证，因std::regex缺乏递归、平衡组等关键特性且存在栈溢出风险；合规实现需词法分析器或第三方库，工程中宜分层校验并明确验证目标。
直接结论：C++标准库不提供RFC 5322邮箱验证
别指望 std::regex 配一个正则就搞定——RFC 5322 的 ABNF 规则太复杂，完整实现需要数百行解析逻辑，且标准正则引擎（尤其 C++11/14 的 std::regex）不支持递归、平衡组、条件断言等关键特性，std::regex 甚至在某些编译器（如 libstdc++）上对长模式有栈溢出风险。
为什么不能只用一个正则表达式
RFC 5322 允许嵌套括号注释、带引号的本地部分（如 "John..Doe"@example.com）、域文字（user@[192.168.1.1]）、IPv6 地址域（u@[::1]），还要求语义合法（比如连续点号 a..b@example.com 是非法的，但单纯靠正则很难区分语法合法与语义非法）。
-
std::regex不支持(?R)或(?&name)这类递归引用，无法处理嵌套注释 - POSIX BRE/ERE 和 ECMAScript 模式都不支持平衡括号匹配
- 即使抄来网上流传的“RFC 5322 正则”，也基本是简化版（如仅覆盖 80% 常见格式），且在 GCC libstdc++ 上可能触发
std::regex_error: regex_error: stack overflow - 真正合规的实现需构建词法分析器 + 递归下降解析器，或调用成熟外部库
实用方案：用 libemailaddressparser 或手动分层校验
如果你必须在 C++ 项目中做严格验证，优先选已验证的第三方解析器；若受限于部署环境无法引入新依赖，则退而求其次，分三步做“足够严”的校验：
- 先用轻量正则粗筛：
^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$—— 这个能拦掉明显非法格式（空@、双@@、尾部点号），但不过 RFC - 再拆解
@前后：本地部分长度 ≤ 64 字节，域名部分 ≤ 255 字节（RFC 5321 限制，常被误当作 RFC 5322 要求） - 对域名部分额外调用
getaddrinfo()或简单 DNS 查询（如用 c-ares）确认其可解析——这步虽超出 RFC 5322 范畴，却是实际工程中判断“是否可能送达”的关键
注意：std::regex 在 Clang libc++ 上对长模式更稳定，但依然无法保证 RFC 合规；若用 PCRE2（需自行链接），可用 pcre2_compile() + pcre2_match() 实现更接近的语法检查，但仍缺语义层验证。
最容易被忽略的细节：空白、注释和编码
RFC 5322 明确允许邮箱地址含无意义空白（如 user @ example.com）和括号注释（如 user (comment) @ example.com），但绝大多数业务系统根本不接受这些。你得明确：你要的是“语法严格符合 RFC”，还是“能被主流 SMTP 服务器接受”？后者往往更宽松（如 Gmail 会静默去除注释并标准化空格），前者反而会导致误拒。
另外，RFC 5322 本身不规定字符编码——UTF-8 邮箱（国际化域名 IDN）需先经 SMTPUTF8 和 U-label / A-label 转换，这部分完全不在纯字符串校验范围内，必须依赖 ICU 或类似库做前置 normalize。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
