我使用多步骤验证。由于没有任何完美的方法来验证电子邮件地址，因此无法创建完美的电子邮件地址，但至少您可以通知用户他/她做错了什么-以下是我的方法：

我首先使用非常基本的正则表达式进行验证，它只检查电子邮件是否只包含一个@符号，并且在该符号之前或之后不为空。例如/^[^@\s]+@[^@\s]+$/如果第一个验证器没有通过（对于大多数地址来说，它应该通过，尽管它不是完美的），那么警告用户电子邮件无效，不允许他/她继续输入如果通过，则使用更严格的正则表达式进行验证，这可能会禁止有效的电子邮件。如果未通过，将警告用户可能发生错误，但允许用户继续。与步骤（1）不同，因为这是一个明显的错误，所以不允许用户继续。

换言之，第一次自由验证只是去除明显的错误，它被视为“错误”。人们键入了空白地址、没有@符号的地址等等。这应该被视为错误。第二个更严格，但它被视为“警告”，用户可以继续输入，但至少要检查他/她是否输入了有效的条目。这里的关键在于错误/警告方法——错误是在99.99%的情况下不能成为有效电子邮件的东西。

当然，您可以调整使第一个正则表达式更自由和第二个正则表达式更加严格的因素。

根据您的需要，上述方法可能适用于您。

以下是验证电子邮件地址的正则表达式：

^.+@\w+(\.\w+)+$

为这个问题发布的正则表达式现在已经过时了，因为新的通用顶级域（gTLD）即将到来（例如，伦敦、篮球、。通販). 要验证电子邮件地址，有两个答案（这将与绝大多数人相关）。

正如主要答案所说，不要使用正则表达式。只需通过向该地址发送电子邮件来验证它（捕获无效地址的异常）使用一个非常通用的正则表达式，至少确保他们使用的是一个类似于｛something｝@｛some｝的电子邮件结构。{一些}。使用一个详细的正则表达式是没有意义的，因为你不会全部抓住它们，几年后会有一个新的批处理，你必须再次更新正则表达式。

我决定使用正则表达式，因为不幸的是，有些用户没有读取表单，并将错误的数据放在错误的字段中。这至少会在他们试图将非电子邮件的内容输入到电子邮件输入字段时提醒他们，这样可以为您节省一些时间来支持用户处理电子邮件问题。

(.+)@(.+){2,}\.(.+){2,}

我使用

^\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*$

这是RegularExpressionValidator在ASP.NET中使用的值。

我不相信bortzmeyer所说的“语法（RFC 5322中指定的）太复杂了”（无法用正则表达式处理）。

这是语法（来自3.4.1。添加规范规范）：

addr-spec       =   local-part "@" domain
local-part      =   dot-atom / quoted-string / obs-local-part
domain          =   dot-atom / domain-literal / obs-domain
domain-literal  =   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]
dtext           =   %d33-90 /          ; Printable US-ASCII
                    %d94-126 /         ;  characters not including
                    obs-dtext          ;  "[", "]", or "\"

假设点原子、带引号的字符串、obs局部部分、obs域本身是正则语言，这是一个非常简单的语法。只需将addr-spec产品中的本地部分和域替换为它们各自的产品，您就拥有了一种可直接转换为正则表达式的正则语言。

如前所述，您不能使用正则表达式验证电子邮件。然而，这是我们目前用来确保用户输入不是完全虚假的（忘记TLD等）。

此正则表达式将允许IDN域和@符号前后的特殊字符（如Umlauts）。

/^[\w.+-_]+@[^.][\w.-]*\.[\w-]{2,63}$/iu