说到发短信验证码接口，第1印象就是好货不便宜，速度快、送达率高的通道各大短信接口厂商收费也好贵，小微个人不舍得接入，也不符合大部分大厂的准入门槛。
想着自己几张手机卡面每月还有几千条免费短信是不是能好好利用一下，做个能发送短信的app在后台运行问题也不大，不过自己手机号还是不要乱搞的为好。
研发App过程中发现有几个大平台对App提供免费短信验证码，微博开放平台、Mob，App上用完全免费，但WebApi都不免费，也许App内接入SDK可以让他们收回成本吧（真实情况是：收益远大于成本）。
虽然不直接提供免费WebApi，那我们是不是可以通过App来发验证码：手机打开App在后台运行，只有有发验证码的需求时，App自动调用SDK发送验证码。
通过研究微博和Mob的文档发现，理论上是可行的，除了符合国情的标准限制（单手机号每分钟、每天限制）外，每个应用也有速率限制。但对小微网站来讲（没啥流量的博客啥的），远远够用，1天撑死了发100条短信，一小时下来也发不了几条。
注意：流量大的不能用本文这个方法，稳定性和安全性大幅下降，都有这么大流量了，应该不差钱接稳定的短信接口吧。
首先要有个App，并且接入了免费短信SDK，能正常发短信（没有？写一个App，然后尝试申请一下）。有很多混合app开发平台，会js+css就能开发出来，当然原生的比较好。
流程图：
流程分解
一、自研短信API网关
就是个普通REST API，提供3个接口：
单条验证码短信发送请求接口，只需提交手机号参数，然后接口把请求加入队列
发送请求队列拉取接口，用于手机App后台任务定时拉取发送队列(改为WebSocket推送会不会快一些，复杂且没价值!)。
[可选]App发送短信后的回执接口，保存发送结果信息。
二、一个手机+自研App（只要成功接入第三方就行）
当然是手机后台跑着我们的App，然后定时拉取自研短信API网关的队列数据，有发送请求数据就调用第三方SDK进行验证码发送，顺带保存回执。
三、网站使用
在需要发短信验证码的地方调用我们自己的短信API网关。
用户提交短信验证码后调用第三方接口对验证码进行校验（也许有第三方可以发自定义短信，验证码由我们自己生成，就不需要和第三方打交道了）。
注意要点
我们要保证手机App在后台长时间稳定驻留，保证网络稳定。
有备用收费短信接口，避免在我们的短信API网关无法正常发送短信时，直连收费短信接口。
提 高可用性，如果用户是首次点击发送验证码按钮，这次请求发往我们的短信API网关，如果是第二次点击发送验证码按钮（没有收到验证码用户重试），发往收费短信接口，稳定性大幅提高。