发送和接收短消息必须借用通信运营商的信道，许多短信验证码接口平台通过与通信运营商联系并提供简单有效的API接口，为大多数软件开发人员提供更快，更优质的服务。

对于短信接口平台，我将它分为两种类型：

第一种是验证码由软件开发者（即短消息接口平台的用户）提供，短消息接口平台不保存和处理验证码，即验证码的验证过程。验证码需要由开发人员处理;

另外，验证码由短消息接口平台提供，同时提供验证验证码的另一界面，即验证码不需要开发者处理和验证，更方便，更方便。

当然，短消息接口平台很可能同时提供上述两个接口。至于具体的短信接口平台公司，这里不再赘述。

验证码存储

这里主要谈谈上述第一类短消息接口，即验证码本身是随机生成的，我们需要将其存储起来，以便随后判断验证码是否正确。

验证码的存储可分为以下两种类型：

第一种类型，验证码存储在服务器端会话中（实际上可以使用一个对象），不需要使用数据库资源，但一旦服务器异常重启，会话中的数据将被完全清除，也就是说，验证码将被使用一段时间。它将全部失败，另一个必须认真对待的问题是我们必须清除会话中过时的数据，否则它将继续占用内存并导致内存泄漏。

其次，验证码存储在数据库中，这将占用额外的数据库资源，但显然服务器端将更容易，并且许多数据库提供TTL（生存时间）功能，通过设置数据的有效期， database将自动删除过期的数据。当然，我们可以简单地存储验证码创建或过期的时间，并花时间判断验证码是否在有效期内。推荐：企业网站登录注册的短信验证码操作机制

中昱维信短信验证码平台

实施例

使用哪个数据库？直接使用mongo，它支持TTL本身，项目的其他数据存储也将使用mongo，因此除了项目本身将使用redis进行缓存之外，不需要为验证代码执行redis数据库。

服务器端逻辑过程：

1.接受用户的手机号码并判断其合法性。

2.随机生成4位验证码。

3.调用短消息接口平台的API接口，并使用随机生成的验证码和用户的手机号码作为输入。

输入参数，接收该接口的输出，判断短信验证码是否成功发送。4.将验证码和手机号码保存在数据库中，并将TTL设置为验证码的有效时间。

5.验证过程中，输入手机号码和验证码，检查数据库中是否有相应的数据。

一般过程是这样的。

执行：

1.判断手机号码的合法性：复杂，查询三大运营商的合法个人号码。这太麻烦且实际上有意义。简单地愚弄它。从1开始的11位数可以通过规律来判断。

2，随机生成验证码：Math.random（）拼接自己。

3，短信平台的界面调用：不同的平台界面，去看官方文档。

4，存储验证码和手机号码，设置TTL有效时间

5.验证码验证：同时查询是否有与手机号码和验证码匹配的数据。