最直接标准是用C++11 std::regex匹配邮箱，但RFC 5322过于复杂，推荐折中正则^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$作前端粗筛；实际校验需结合状态机或发信验证。
用正则表达式匹配邮箱格式最直接
标准 C++11 起支持 std::regex，能快速验证基础邮箱结构。但要注意：RFC 5322 定义的合法邮箱极其复杂，实际项目中不建议用正则完全覆盖——既难写全，又影响性能。
推荐一个兼顾可读性与实用性的折中正则：
^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$
它能拦住明显非法的情况（如缺少 @、无域名、顶级域太短），但会拒绝一些真实存在的合法邮箱（如含引号或注释的）。使用时需明确这是「前端粗筛」而非「终极校验」。
-
std::regex在某些旧版 libstdc++（如 GCC 4.8）中存在 bug 或缺失，编译报错std::regex_error时优先检查标准库版本 - Windows 上 MSVC 默认启用
/std:c++17后std::regex可用；Linux 下若用 Clang + libc++，需确认是否启用了-stdlib=libc++ - 正则对象建议缓存为
static const std::regex，避免重复构造开销
不用正则时可用手写状态机简单判断
如果项目禁用正则（如嵌入式环境、或担心异常抛出），一个轻量级状态机足以过滤掉 95% 的无效输入。核心逻辑是检查三段结构：local-part@domain.tld，且各段非空、不含非法字符。
立即学习“C++免费学习笔记（深入）”；
关键约束点：
-
local-part不能以.开头/结尾，也不能连续出现.. -
@必须且仅出现一次 -
domain部分不能含下划线_（虽部分 MX 允许，但多数服务端拒绝） - 顶级域（
tld）长度至少为 2，且只含字母
这种写法没有依赖，几行 for 循环加几个布尔标志就能实现，适合对启动时间或二进制体积敏感的场景。
别在 C++ 层做最终邮箱有效性验证
无论正则多完善、状态机多严谨，C++ 代码里都无法确认一个邮箱地址是否真实存在、能否收信。真正有效的验证只有两种方式：
- 向该邮箱发送含 token 的激活邮件，并等待用户点击链接或输入验证码
- 调用 SMTP
RCPT TO命令试探（需连接目标 MX 服务器，受反爬和频率限制，且很多服务器会拒绝未认证试探）
把邮箱格式校验和邮箱真实性校验混为一谈，是初学者常踩的坑。格式对 ≠ 邮箱可用，后者必须交由异步业务流程完成。
第三方库如 libemailaddress 并不比手写正则更可靠
网上有些 C++ 邮箱解析库声称「完全兼容 RFC」，但实际要么依赖 Boost.Spirit（增大依赖链），要么用递归下降解析器（对畸形输入易栈溢出），要么干脆把整个 RFC 5322 当摆设——它们依然无法解决「邮箱是否存在」这个本质问题。
更现实的选择是：
- Web 后端：让前端用相同正则做即时反馈，后端用同样逻辑再校验一次（防绕过），然后立即进入发信流程
- CLI 工具或配置文件解析：接受宽松格式（如允许
user@localhost），把校验粒度交给使用者决定 - 日志或调试场景：直接记录原始字符串，不尝试解析，避免误判引入噪声
真正难的从来不是“怎么写对”，而是“在哪一层、以什么代价、承担多少责任去校验”。格式只是第一道滤网，漏过去的部分，得靠后续环节兜底。
