用户发送验证码给服务器 是什么思路

你说的这个 “用户给服务器发送” 指的是哪种？ 举个栗子

有短信接收硬件来处理接收短信后发送到服务器吧。就相当于这个硬件接收到短信后，就把短信号码和信息转发到设置的服务器了。这里最主要的就是这个硬件了，没硬件就做不到

我想到的实现：
1、用户访问验证页面，服务器生成页面+验证码+页面token（页面token和验证码绑定）
2、用户通过某个客户端（可以识别用户身份-包括手机短信、微信客户端等等其他平台）发送验证码到指定地方（比如发短信到某个号码，发消息到某个公众号），服务器绑定这些平台的回调接口，获取到发送人的信息和验证码。
3、根据前面获得的发送人信息和验证码获取发送人的授权信息，再根据验证码和页面token的绑定关系通知到验证页面，授权访问验证页面的用户。

没太明白，楼主说的是短信验证码？ 是用户给某个手机发送验证码，然后服务器得到验证码，是这个意思？

这个应该需要硬件支持

本质上是一样的吧，验证码也是由服务器生成，只是你提交验证码的位置变了而已。

“猫池”，也可以自己开发个安卓的 App ，监听短信的广播，然后把发信人手机号 + 内容发送到服务端去就好了

发送完 用户主动点已发送就完事散

这个你得找电信运营商。

挺多短信运营商都支持信息接受，服务端生成验证码，前端展示给用户，提示用户使用指定手机号发送到指定号码，发送完点击已发送，然后你自己用短信运营商的 api 去查，如果查到且内容一致，就通过校验。

一般的业务应当不涉及这种需求，可以咨询一些短信服务商，他们可以提供短信上行回调的（就是接收到用户发送的短信），用词建议将服务器改为服务端

前面看你说轮询比较 low，其实我并不以为，在验证这些场景下轮询是最好的解决方案，额外维护一套长连接会额外消耗巨额服务端资源，所以并不是更高深的技术就是好的，原始的技术就 low，适合业务需求的才是最好的。可以看一下阿里腾讯字节相关业务全部都是采用轮询的方式

1. 用户发送短信
2. 服务器记录短信
3. 用户点击已发送短信，服务端校验数据，并做出相应动作

发送验证码核心是验证手机的发送功能，主要是安全考虑，避免一些物流卡的滥用。当然，之前也有说短信的上下行对等可以让网站发送短信费用下降的，不过后来这个成本被腾讯等大型公司忽略了。 主要是出于安全考虑。

找个支持上行的短信通道运营商，一般会配置个上行短信的回调，将短信发给你提供的地址。是否采用长连接还是手动刷新取决于业务场景。

很少做短信上行验证的原因是体验很差，所以除非必要验证用户手机号的上行能力，还是尽量用下行验证。