验证电子邮件

“正确”验证电子邮件是一个比看起来更困难的问题： RFC 5322 是一个怪物。在实践中，我们选择一个“足够好”的模式 接受常见的情况，拒绝明显错误的情况。

Pattern: ^[\w.+-]+@[\w-]+(?:\.[\w-]+)+$

• [\w.+-]+ -- 本地部分：字母、数字、_、.、+、-。
• @ -- 分隔符。
• [\w-]+(?:\.[\w-]+)+ -- 域名 + 至少一个由 . 分隔的 TLD。

它接受：mario.rossi@example.com、foo+bar@sub.example.co.uk、 user_123@test-domain.io。

它拒绝：mario@、@example.com、mario@example（无 TLD）、空格。

权衡

上面的模式不接受：

• 引用的字符串 "strange (things)"@example.com （RFC 允许）。
• 具有 Unicode 字符的域 (\u00fcber@m\u00fcnchen.de)。
• 未通过 \w 的超长 TLD（例如国际化 TLD）。

如果您需要它们，请使用 u 标志将类扩展到 \p{L} ，或委托给 专门图书馆。

电子邮件验证的权衡和最佳实践

任何正则表达式都不能保证电子邮件地址确实存在。过于复杂的模式会降低性能并排除异常但有效的域。最好使用简单的验证模式来拒绝明显的拼写错误并发送验证码。

尝试一下

复习练习

额外的挑战