用户注册与登录的设计是个老话题了，今天来点新鲜的。
一、传统招数
目前主流的用户登录设计主要有4种：
- 账号密码登录
- 手机短信登录
- 社交账号登录
- 自有 APP 扫码登录
账号密码这种方式最为古老也最长青，当然，缺点也是挺明显的。最大的问题当然是无法判断账号的真实性，因为一个人可以注册多个账号。
后来，为了让注册用户更真实，大多数网站选择了手机短信验证码的方式。这种方式就好多了，用户也觉得方便，就是有点费钱。人品不好遇到机器人刷验证码，那费得更厉害，以至于后来发短信验证码前都要先来一遍图形验证码(Captcha)，为了省钱降低了不少体验。
而社交账号登录一开始只是为了解决用户体验的问题，毕竟它比账号密码登录要方便多了。长期以来，它都是一种备用方案作为前面两种方案的补充，如果要验证用户身份的真实性，还是要结合手机短信验证码来做手机绑定。
自有 APP 扫码登录不必多说，这是一个拥有强粘性用户的选择。普通的 SaaS 在获客阶段此种方式不可取，但在进入成交使用阶段后，还是可以大量采用的。
二、微信公众号方案
我今天所说的「高性价比的 SaaS 系统用户注册与登录设计」，算是半个标题党吧，因为这不是一个全新的方案，它是基于微信公众号来实现的。方案的前提是建立在用户没有安装你的产品 APP，甚至是刚刚了解你的产品，在网站上准备注册试用的时候，触发注册行为的入口是在 Web 上（非移动端场景）。它概括起来要实现三个要点：
- 高用户互动触达率（你找得到用户，用户找得到你）
- 低成本（省钱，最好免费，短信费都不想出）
- 不牺牲用户体验（甚至某些体验比传统方式更好）
要实现这几点，内容比较多，我打算用一个系列来记录。这个系列每一篇文章都解决了一个场景的问题，可以作为独立方案使用，最后合在一起，就是一个完整的可以马上用的方案。
声明一下，这些方案中，并非都是我原创，我也看到很多网站在多年前就已经在采用其中的一些方法，但是网上并没有人给出具体的技术实现，我会在文章里给出这些技术实现的细节。当然，整体方案中仍然有很大一部分——尤其是后面的几篇文章，会介绍一些目前没有人采用或者很少人采用了但并没有公布在网上的方法。
三、场景描述
今天先来解决用户互动触达率的问题，也是不少网站已经在采用的「让用户关注公众号替代微信扫码用户授权(OAuth 2)登录」的方案，它的优点是仅使用一次扫码，就实现了注册、登录和用户身份绑定，并可以通过公众号下发消息，再次触达用户。
场景一：用户注册
用户在网站上准备注册时，从用户视角来看，步骤是这样的：
- 用户点击「注册/登录」按钮；
- 页面展示一个二维码，并提示用户「使用微信扫描二维码」；
- 微信扫码后，进入「公众号关注」页，用户手动点击「关注」；
- 公众号返回消息「注册成功」；
- 电脑页面显示「注册成功」并成功登录，跳转到登录后页面。
看起来步骤不少，但仔细看看用户的实际操作，只有「扫码」和「关注」两个动作，和传统的 OAuth 2 扫码授权登录时的动作是一样多的，只是把「确定授权」换成了「关注」。
有的网站仍然采用了「验证码」的思路（我不推荐），在第 2 步时，电脑网页会出现一个验证码输入框并提示用户扫码获取验证码，在第 4 步时微信会发出一个「验证码」，用户第 5 步时在电脑端填入。这种方式需要用户的操作更多，但给用户的感觉会更温和，更像是一个用户接收验证码的过程而不是一个刻意引导用户关注公众号的过程。
不要小看了这个「关注公众号」的过程，它是比「短信」和「邮件」更能与用户发生连接的地方。只这一个优点，就是传统注册方式无法比拟的了。同时，由于微信的加持，也可以在这个过程中和用户授权登录一样，拿到用户的头像、昵称、性别、地区等信息，用于完善用户的信息。
场景二：用户登录
用户在注册成功之后，下一次登录时的步骤更是减少到只需要一个「扫码」的步骤：
- 用户点击「注册/登录」按钮；
- 页面展示一个二维码，并提示用户「使用微信扫描二维码」；
- 用户微信扫码，公众号返回消息「登录成功」；
- 电脑端显示「登录成功」并跳转到登录后页面。
这个体验，怕是比「微信授权登录」还简单。
四、技术实现
接下来我要介绍这个方案的技术实现细节。以下是该方案的功能时序图，请完成阅读和理解：
方案中在等待用户微信扫码时，电脑端网页和服务器之间有一个等待并保持通信的过程，这个过程既可以采取由网页端发起轮询，也可以用 WebSocket 建立长连接。由于业务逻辑比较简单，这里我推荐采用客户端轮询的方式。
API接口
以网页端采用轮询方式为例，服务端提供的接口一共有3个，2个给前端调用，1个用作微信公众号平台的回调（也可以在已有回调地址上增加功能）：
/login-start
#(给前端)获取登录二维码#请求参数：无
#响应结果：服务端生成的「唯一请求参数」和二维码地址
/check-login
#(给前端)获取登录成功状态
#请求参数：上一个接口返回的「唯一请求参数」
#响应结果：等待扫码 或 登录成功 或 二维码已超时
/wx-service-callback
#(在微信公众号平台注册的回调地址) 注册成功后返回消息
#请求参数：微信公众号平台回调的XML数据
#响应结果：XML格式的公众号消息` </pre>
数据库
服务端首先要在数据库创建一个数据表，用于存放「访问参数」以及其状态与过期时间。为了性能考虑，可以将访问参数放入 Redis 缓存，并设置对应的过期时间。
服务
在服务端已经实现微信公众号接口调用的情况下（即 accessToken 已经拿到），服务端要实现的对应的主要服务也有3个，以下是实现逻辑的文字描述，实际开发中应该根据项目自身的结构重新分拆、组织文件，编写接口与实现：
/* 获取登录二维码
* 参数：无
* 返回：
* LoginProcess.qrcodeUrl 微信公众号接口返回的二维码链接
* LoginProcess.requestCode 唯一请求参数
*/
LoginProcess startLoginProcess() {
// 1. 生成「唯一请求参数」，放入数据库和缓存，并设置过期间
// 唯一请求参数有3个状态：未验证、已验证、已过期
// 2. 用「唯一请求参数」调用微信公众号「生成带参数的二维码」接口生成二维码
// 3. 返回二维码链接 及 唯一请求参数
}
/* 获取登录结果
* 参数：唯一请求参数
* 返回：
* 登录过程结果
*/
String checkLoginProcess(String requestCode){
// 1. 查询唯一请求参数状态及是否过期
// 2. 如果已过期，则更新唯一请求参数状态为「已过期」，并返回 二维码已过期
// 3. 如果状态为 未验证 时，返回 等待扫码
// 4. 如果状态为 已验证 时，执行登录逻辑，并删除唯一请求参数，返回 登录成功
}
/* 处理微信公众号平台回调（如果用户未注册将创建用户）
* 参数：微信用户 openId，唯一请求参数
* 返回：返回给微信公众号的消息
*/
String weixinCallback(String wxOpenId, String requestCode) {
// 1. 如果该微信 openid 的用户已存在，表示用户已注册
// 1.1 更新唯一请求参数状态为「已验证」
// 1.2 向微信公众号平台返回消息「登录成功」
// 2. 如果该微信 openid 的用户已不存在，表示尚未注册
// 2.1 如果用户未注册，则从微信请求用户基本信息
// 2.2 创建用户
// 2.3 更新唯一请求参数状态为「已验证」
// 2.4 向微信公众号平台返回消息「注册成功」
}
}
五、总结
今天介绍的以引导用户关注微信公众号的方式完成注册的方法，已经是一个成熟的方案，有很多网站也已经在使用这种方式了。我认为它最大的优点就是加强了和用户的连接，用户注册后，即可以使用微信的「客户消息」接口向用户推送多条消息；也可以利用服务号的优势后续持续的为用户服务。
本系列的下一篇，我会讲一讲如何利用微信代替手机短信验证实名手机的方案和技术实现，如果你感兴趣的话，请持续关注「SaaS 产品派」接下来的系列文章。
