邮件地址验证是几乎每个 Web 应用都会遇到的工程问题，但实现方式往往存在根本性误区。最常见的错误是将验证视为正则表达式问题 —— 团队花费数小时调试复杂的正则模式，试图覆盖 RFC 5322 定义的所有语法规则，却忽略了两个关键事实：第一，完整的 RFC 合规正则超过 6000 字符，维护成本极高；第二，RFC 允许的很多边缘情况在实际邮件系统中几乎不被支持。
更深层的问题在于混淆了 "验证"（validation）与 "确认"（verification）。验证回答的是 "这个地址格式是否正确"，而确认回答的是 "这个邮箱是否真实存在并能接收邮件"。生产系统需要同时处理这两个层面，但策略截然不同。
误区一：RFC 5322 合规不等于可用
RFC 5322 定义的邮件地址语法比大多数开发者想象的更宽松。规范允许引号包裹的本地部分，例如 "john..doe"@example.com 或 " "@example.com（是的，空格在引号内是合法的）。它还允许注释语法，如 john.smith(comment)@example.com，括号内的内容应被忽略。此外，点号规则仅限制未引用的本地部分 ——john..doe@example.com 本身不合法，但加上引号后 "john..doe"@example.com 完全符合规范。
然而，这些边缘情况在真实世界的邮件系统中极少被支持。主流邮件提供商的注册流程通常会拒绝引号、注释和连续点号。这意味着一个严格遵循 RFC 5322 的验证器可能会接受大量无法在实际系统中使用的地址。工程决策应当区分 "协议层面合法" 与 "实际可用"，后者取决于目标用户群体的邮件提供商生态。
误区二：提供商特定的行为差异
Gmail 的处理方式是最典型的例子。Google 会忽略本地部分的点号，将 john.doe@gmail.com 和 johndoe@gmail.com 视为同一邮箱。但这一规则仅适用于 Gmail 域名，其他邮件提供商（包括企业自建邮件系统）通常将点号视为有效字符。如果你的应用基于 Gmail 的行为进行点号归一化，可能导致非 Gmail 用户账户被错误合并。
加号地址（plus addressing）是另一个常见陷阱。user+tag@example.com 格式被 Gmail、Proton Mail、Fastmail 和 Yahoo Mail 支持，用于邮件分类和过滤。但 Outlook.com、iCloud Mail 和 AOL Mail 不支持临时加号地址 —— 它们只允许手动创建别名。如果你的验证正则拒绝加号字符，将直接阻断大量使用 Gmail 的付费用户。根据 Jonas Neubert 的对比分析，不同验证库对加号地址的处理存在显著差异，这进一步说明依赖单一正则的危险性。
误区三：正则表达式的维护噩梦
试图用正则覆盖所有 RFC 5322 规则是一条不归路。完整的规范合规正则超过 6000 字符，包含处理注释、折叠空白、引号逃逸等复杂逻辑的嵌套结构。这种正则难以阅读、难以测试，且容易引入灾难性回溯（catastrophic backtracking）性能问题。
更务实的做法是采用分层策略。前端使用 HTML5 的 <input type="email"> 进行基础格式检查，配合简单的正则 ^[^\s@]+@[^\s@]+\.[^\s@]+$ 捕获明显的输入错误。后端则使用成熟的验证库（如 JavaScript 的 Validator.js、Python 的 email-validator、Java 的 Apache Commons Validator）进行结构检查，这些库经过充分测试，能正确处理长度限制、标签规则和特殊字符。
分层验证的工程实践
生产环境的邮件验证应当分为四个层次，每层回答不同问题：
第一层：格式检查。验证地址包含且仅包含一个 @ 符号，域名部分包含至少一个点号，整体长度不超过 254 字符（SMTP 路径限制），本地部分不超过 64 字节，域名部分不超过 255 字节。拒绝控制字符（尤其是 \r 和 \n）以防止头部注入攻击。
第二层：库级验证。使用专用库检查标签规则（每段 63 字符限制，不能以连字符开头或结尾）、域名格式（拒绝 IP 字面量如 user@[192.168.1.1]，除非有明确的企业用例）。这一层应可配置策略 —— 是否允许加号地址、是否接受引号本地部分、是否支持国际化域名。
第三层：DNS 检查。查询域名的 MX 记录，确认该域名配置为接收邮件。注意部分域名仅配置 A/AAAA 记录而无 MX 记录，根据 RFC 5321 仍可接受邮件。DNS 检查应作为 UX 提示（"您是否想输入 gmail.com？"）而非阻断条件，避免误伤合法但 DNS 配置特殊的域名。
第四层：确认邮件。发送包含唯一验证链接或 OTP 的邮件，要求用户点击或输入以证明邮箱所有权。这是唯一可靠的验证方式 —— 能捕获拼写错误（如 jsmith@gmial.com 格式正确但域名不存在）、废弃邮箱和垃圾邮件陷阱。
国际化与大小写处理
RFC 6530-6533 定义的 Email Address Internationalization（EAI）允许 Unicode 字符出现在本地部分和域名中，例如 miyuki.さくら@例え.テスト。但 HTML5 的 input type="email" 仅支持 ASCII，会直接拒绝国际化地址。如果需要支持 EAI，前端必须使用自定义验证逻辑（JavaScript Unicode 属性转义如 /(\p{L}|\p{N})+/u），后端则需处理 IDN/Punycode 转换以进行 DNS 查询。
大小写敏感性方面，RFC 5321 规定域名部分大小写不敏感，本地部分技术上大小写敏感。但实践中几乎所有主流提供商将本地部分视为不敏感。建议存储原始输入用于显示，但比较时使用规范化形式（通常为小写）。
建议优于拒绝的 UX 策略
严格的验证往往造成比宽松验证更多的数据质量问题。每个被错误拒绝的合法地址都是潜在的用户流失，而每个被错误接受的无效地址都可以通过确认邮件捕获。
更优的策略是 "建议而非拒绝"。当用户输入 derek@gmial.com 时，不显示红色错误提示，而是显示 "您是否想输入 gmail.com？"，允许用户确认或覆盖。常见拼写错误模式包括：错误字母（gnail）、多余字母（gmaill）、缺失字母（gmal）、交换字母（gmial）。针对前十大邮件域名的检测可覆盖绝大多数消费者拼写错误。
可落地的检查清单
在部署邮件验证功能前，对照以下清单进行审查：
- 使用验证库而非自定义正则进行核心解析
- 强制执行长度限制（整体 254 字符，本地部分 64 字节）并拒绝控制字符
- 区分 "格式有效" 与 "可投递"，通过确认邮件验证后者
- 提取流程能处理
Name <email@domain>格式和尾部标点 - 策略决策（加号地址、引号本地部分、Unicode 支持）明确且文档化
- 测试生成唯一、与运行关联的地址，容忍重发和乱序邮件
- 将邮件地址视为个人数据，日志中使用哈希或脱敏形式
邮件地址验证的终极目标不是构建一个完美的 RFC 解析器，而是在用户体验、数据质量和系统安全之间找到平衡。接受边缘情况优于拒绝合法用户，确认邮件优于复杂的正则推断 —— 这是经过生产环境验证的工程智慧。
资料来源
- Mailhook: "Email Addresses in Automation: Validation and Edge Cases" (2026)
- Prospeo: "Email Validation Rules: Complete 2026 Guide"
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。