不能仅靠RFC兼容正则验证邮箱，因其难以完整实现、不支持引号本地部分、+标签、IDN，且性能差；应分层处理：预处理输入、正则初筛、net/mail语法解析、域名黑白名单校验及IDN转Punycode。
Go 语言标准库 net/mail 解析器比任何正则表达式都更贴近 RFC 5322 —— 但直接用它做“格式校验”反而容易误判合法邮箱，比如 test@example.co.uk 会被 mail.ParseAddress 拒绝（因缺少显示名），而 mail.ParseAddressList 又过于宽松。真正靠谱的验证，是分层处理：先做轻量级正则初筛，再交由 mail.ParseAddress 做语法解析，最后补充常见域名规则。
为什么不能只靠 RFC 兼容正则？
RFC 5322 定义的邮箱地址正则理论上可达上千字符，实际中几乎没人完整实现。Go 社区常用的那个“号称 RFC 合规”的 ^[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])?)*$ 看似严谨，但它：
• 不支持带引号的本地部分（如 "Abc@def"@example.com）
• 把 user+tag@example.com 当作非法（其实合法）
• 对 IDN 域名（如 用户@例子.中国）完全无感知
• 在 Go 中用 regexp.Compile 编译后性能下降明显（尤其高并发场景）
用 net/mail 解析前必须预处理
mail.ParseAddress 要求输入形如 "name <user>"</user> 或纯 user@example.com，但不接受末尾空格、换行、控制字符，也不容忍多余引号。常见失败不是语法错，而是输入脏：
- 先用
strings.TrimSpace清除首尾空白 - 拒绝含
\x00-\x08、\x0B-\x0C、\x0E-\x1F的字符串（RFC 5322 明确禁止） - 若字符串含
@但无.在 @ 后（如user@localhost），可提前返回 false ——mail.ParseAddress会解析成功，但绝大多数 SMTP 服务器拒收 - 对含中文或 emoji 的本地部分（如
??@example.com），需确认目标系统是否支持 SMTPUTF8；否则应直接拒绝
域名部分要单独校验 DNS 可达性吗？
不要在验证函数里查 MX 记录：
• net.LookupMX 是阻塞操作，超时难控，易拖慢 API 响应
• 大量临时域名（如 user@guerrillamail.com）有 MX 却不接受注册，查了也没用
• 真正该做的，是检查域名是否在已知一次性邮箱列表（如 mailinator.com）或明显无效（如 example、localhost、test）
• 推荐用轻量白名单 + 黑名单组合：白名单存常见免费邮箱域名（gmail.com、outlook.com），黑名单过滤已知垃圾域，其余放行
立即学习“go语言免费学习笔记（深入）”；
最常被忽略的是国际化域名（IDN）处理：Go 的 net/mail 不自动 Punycode 编码，用户@例子.中国 必须先转成 用户@xn--fsq.xn--fiqs8s 才能被正确解析 —— 这步漏掉，会导致看似合法的地址被拒。
