你们中有多少人曾在会议上或以其他方式争论如何正确地进行电子邮件验证？
TLDR：简单的回答，不要这样做，不值得付出努力，只有一种方法，发送电子邮件并查看用户是否点击其中的链接，就是这样。
现在来看看更长的版本。在本文中，我使用“验证”一词来表示阻止屏幕上的进度或不将数据保存到数据库，直到满足此类验证规则为止。
在我从事软件开发行业的十五年中，我对这一问题有过很多争论（在同一个问题中包括邮政编码和电话号码，或整个送货地址！），并且在我早期的职业生涯中投入了大量的时间在不同的平台上实现最花哨的、有时基于正则表达式、有时基于代码的格式验证、双重输入和阻止复制粘贴类型的解决方案（Silverlight、ASP.NET、React、NodeJS，随便什么都可以），但我才意识到，这是徒劳的，到最后，毫无用处的操作，没有任何影响。
追根溯源，你为什么需要电子邮件验证？有几个原因，让我们一一分析一下：
知道这是一个我可以发送电子邮件的地址
您可以想出任何花哨的本地验证，但它永远无法证明您可以向其发送电子邮件，直到尝试为止，例如，它是一个完全有效的公司地址，但由于该人离开公司而刚刚被停用。
只需查看 RFC 2822（它覆盖了 RFC 822）即可知 加纳 电话号码库 仍能正常工作的地址格式有多复杂 https://datatracker.ietf.org/doc/html/rfc2822(https://datatracker.ietf.org/doc/html/rfc2822)。您不想复制此操作，或者在某些行业中您不能重用任何开源库（例如在银行业，只需询问 IT 安全人员他们的意见）。
知道我可以通过这封电子邮件联系到客户
同样的问题，本地计算永远不会帮助您与目标客户建立沟通，拼写错误仍然会导致有效的电子邮件地址，但您无法通过单个邮箱联系到正确的客户或事件。
因此，要真正确定电子邮件地址是否有效且正确，您需要向该地址发送一个秘密并以某种方式索取，以便客户证明他拥有并可以访问该电子邮件帐户。
但是等等，发送消息的成本不是太高了吗？
对于大多数安全、GDPR 和其他法规，您无论如何都必须确认用户的身份以及他们是否真的拥有该帐户的权限（例如，您不能只是通过随机地址订阅所有新闻通讯）。
如今，在您选择的平台上设置或访问 SMTP 服务器并发送电子邮件非常简单，成本仅限于某些计算能力等。由于您永远不会信任前端验证（希望您不要！），您将在后端重复验证，这反过来会花费您的计算时间，同时也不会消除发送电子邮件本身的需要。
并且比较一下您这样做了多少次，为了 重塑内容营销自动化 保护帐户，您无论如何也要提供 OTP（一次性密码）解决方案？几乎所有登录都使用相同的逻辑，而不是在第一次登录之上。
只需比较这两个图表，就会发现增加了多少复杂性，而除了提醒客户他们的某个输入字段之间是否有拼写错误，或者你只是激怒了他们而使他们无法使用原本有效的电子邮件地址之外，什么也没有得到。
但您仍未解决其他多个问题：
- 您确定这个地址只属于一个人吗？与电子邮件列表一样，多个用户通过共享密码访问 → 您可以根据您所在行业在 EULA（最终用户许可协议）或其他合同条款中处理此问题，让用户对共享密码造成的损害负责
- 您确定这个地址是唯一的，并且不会指向同一个人或电子邮件地址吗？就像别名（与电子邮件列表不完全相同）。大多数人都不知道 阿拉伯语数据 但电子邮件地址实现了一种隐式别名机制，例如在 @ 符号前放置一个 + 符号，并在它们之间输入任何内容，您的电子邮件仍然会发送到同一个地址，只是您现在有无数个别名，（享受一些与电子邮件地址绑定的试用访问）→ 您创建的某些验证不会捕获到这一点，因此，集中精力解决可能造成损害的问题不是更好吗？如果您使用不同的数据来识别您的客户，例如在财务方面，您已经制定了如何做到这一点的规定，而这些规定从不包含电子邮件地址，那么您再次使验证变得多余或无用
- 您确定电子邮件地址不是临时的吗？就像一次性电子邮件一样，类似于一次性电话，甚至可以在设定的时间段后自毁，甚至使检测实际上属于同一个人的多个地址变得复杂。
我们当然需要验证电话号码——不，我们不需要
很多时候，我甚至数不清有多少客户希望我验证电话号码，并完全忽略不符合要求的值，不让客户或管理员将该号码保存到系统中。每次他们几周后都会问我们是否可以再添加一个有效的电话，一遍又一遍，最后问，哦，我们可以支持国际号码吗？
或者最浪费时间的是去追查为什么一位客户无法完成电子商务网站的注册，尽管他住在服务区，所有数据都正确，但他有一个外国手机号码，因为最近刚搬家。现在商店失去了一位客户，他本来可以很容易地得到商店的服务，而无需进行电话验证。
即使在单一市场中你会做什么呢？比如匈牙利有固定电话和 3 个主要的移动网络，以及一些鲜为人知但仍然存在的小型网络，这些人从其他国家移居过来并决定保留他们的原始号码，甚至选择在服务提供商之间转移这些号码。
同样的规则适用，向电话号码发送一个秘密并要求客户输入（您不会自己发送短信而是使用 SaaS（软件即服务），不是吗？），现在您确定他们可以访问电话（并不是说只有他们有访问权限，等等，所以再说一次，如果想用它进行个人身份识别，请用合同条款或其他方式保护自己，但在这方面你可以比电子邮件更好地使用它，现在电话更像是个人物品）。
然而，这里又回到了价格的争论中，发送短信的成本比发送电子邮件的成本高得多，因此制定好的策略来降低每个客户发送短信的次数是必要的（可以是另一篇自己的博客文章），然而，在静态的本地代码中严格验证号码仍然不会有太大帮助。
例如，你可以明显地限制号码，因为现在匈牙利的电话号码只有 9 位数字，不是吗？我们的号码在两年后就会用完，或者由于其他原因，现在市场上有 10 位数字，你必须升级所有超过 2 年的代码，以便让相当一部分客户进入你的业务。
相反，您可以选择引导客户采用更便宜的解决方案，仅在必要时使用短信作为后备（例如在信用卡支付 3DS 验证过程中），并在可能的情况下使用推送通知或电子邮件。或者，当不作为后备时，用户仍然出于某种原因想要短信，将其计入他们的成本或账单，但不要浪费精力在前端和后端代码上验证它们，您将有更多的后续工作、生产支持和不眠之夜，而不是那些可能不必要的短信成本。
好吧，但发送真实邮件的成本更高——确实如此，但无论如何，验证地址还是很有趣的
关于邮政服务，大多数人不知道的有两件有趣的事情。第一，他们是服务无人问津地区的英雄；第二，地址对计算机来说大多毫无意义。
除了一些很酷的地区，比如曼哈顿，那里的电网几乎是完美的，道路是平行的，地块是正方形的，地球上的大多数地区都很奇怪，不遵循易于计算机化的逻辑，大多数地方都是在算法应用之前设计的，它们以人类为目标，以帮助它们完成工作。
客户只需简单询问，无论客户输入哪个城市送货，我们都会根据给定的城市自动填写邮政编码。哦，必须从下拉菜单中进行填写，并且必须填写。不行，邮政编码和城市（或更常见的村庄名称）是多对多关系。就像大多数首都或大城市都有多个区和多个邮政编码，而农村地区通常有多个村庄使用相同的邮政编码。
如果它们如此关联，我们就不需要在地址上使用其中一个或另一个，因此可以帮助建议某个城市的一个或多个邮政编码，或建议某个邮政编码对应的一个或多个城市，但如果不访问庞大的邮政地址数据库，就永远无法完全确定，例如对于银行来说这是不可行的。