前言
假如你碰到了一个扫码登录场景，有个pad或者pc端给定一个二维码，让已经登录过得用户扫码实现登录，并且这个二维码是随机生成的，不能是固定组合，你会怎么设计呢
这个扫码登录能解决，那么扫码处理订单此类功能也会有思路了
当然本篇只讲扫码登录有哪些方式，比较哪种方式更好用(当然可能不全，欢迎补充😄)
扫码登录方案
做扫码登录首先要明白，需要做到哪些功能
- 后端提供生成二维码的唯一标识
- 前端、pad请求接口获取后端的唯一表示生成二维码
- 手机端扫码读取到其中的唯一表示
- 手机扫码端拿着标识请求后端的登录接口，此时需要后端提供登录确认接口，手机端传递唯一标识和用户令牌给后端，将该用户和二维码唯一标识绑定
- 前端、pad在生成为二维码后，需要和后端持续通信，当得知后端二维码唯一标识和用户绑定后，表示用户扫码登录了，此时传给前端、pad登录所需用户信息或者令牌，表示登录成功
此过程其他都比较像，不同的是生成二维码的前端、pad 和后端绑定标识后 的通信方式，也就是最后一条的最后一步，而这一步需要考虑的是，用户生成二维码后需要等待后端反馈用户登录消息
此通信方式大致有以下几种：socket、SSE、http轮询、硬件通信(不稳定)
socket通信
socket即时通信这也是大家可能第一时间想到的，要想前后端长时间通信，那么socket很适合，使用socket有如下几个步骤：
- 前后端建立socket通信保持连接
- 后端返回二维码标识，前端、pad生成二维码继续保持连接，等待后续登录消息传来
- 后端等待过程发现手机端扫码登录了，继续传递给前端、pad 登录成功信息
- 登录成功终止socket连接
当然上面也可以通过http获取二维码，socket仅仅是等到后端登录成功消息
SSE通信
虽然socket即时通信这也是大家可能第一时间想到的，但后面发现整个过程都是后端在推送消息给前端，那么可以采用更节省资源的SSE模式，也就是后端单向通信模式，发现挺好，相比socket更节省资源，算是一个http特殊情况(Connection：keep-alive还了解么)，现实并不是那么常用，仅仅在一些场景比较常用(例如：股票)，毕竟SSE看着虽简单，也不是所有人能直接上手，更主要的是这个不是前端写的应用(ios、android、小程序)，可能就更没那么友好了
- 建立SSE通信
- 后端返回二维码标识，前端、pad生成二维码继续保持连接，等待后续登录消息传来
- 后端等待过程发现手机端扫码登录了，继续传递给前端、pad 登录成功信息
- 登录成功断开连接
当然上面也可以通过http获取二维码，SSE仅仅是等到后端登录成功消息
http轮询(简单粗暴、推荐)
上面的情况都会加大开发复杂度，并且资源说是节省，然而并没有节省那么多，一个登陆需要花费多久呀，轮询几次没登录就算超时就行了，现实更多地是采用http轮询的方式，简单粗暴，且功能无论对于前后端来说看起来更加简单粗暴好维护
当然有人会反驳，频繁的http可能比socket、sse更占用资源，现实是2~5s的轮询无论是人力开发，还是硬件开销可能都比实际想象的小一些(无论是前端开发开始后端开发都要简单不少)，且标准的http请求上看起来更友好，尤其是一些公司统计接口占用时长更在意，此时表现更友好
ps:长时间的连接通信，在一些公司可能会触发接口过慢警告，非常麻烦，因此单次http一直同步等待后端影响的实现也在此列
对于此交互，有如下步骤：
- 前端请求接口后端返回二维码标识，然后轮询登录状态的接口，假设2s，1分钟算过期
- 轮询登录接口过程发现已经关联登录，后端会返回登录结果，结束
其他硬件设备通信(不稳定，不推荐，特殊场景可能有奇效)
不太推荐，算是一个特殊情况的开拓思维的，就举一个蓝牙例子吧
假设都有蓝牙，通过蓝牙通信，直接将用户的令牌通过蓝牙传递过去，直接就登录成功了，缺点是两端蓝牙通信，对于不太了解的会花费更多时间，当前其他硬件通信也是一样的(特殊场景有奇效)
最后
就介绍到这里吧，实际上可能还有其他方案，就不一一介绍了，主流就这些了，欢迎提出，要是有更好的，这边也会继续编辑更新出来😄