小程序 登录 设计 第1篇
登录的时候我们需要接收前端传入的手机号和密码，通过手机号和密码来和数据库进行验证，因为我们的密码已经是加密了，我们先需要写一个云函数单独验证一下密码
输入如下代码
回到API方法里，选择我们的云函数，输入入参
小程序 登录 设计 第2篇
登录在英文中是 「login」，对应的还有 「logout」。而登录之前，你需要拥有一个账号，就要 「register」（or sign up）。
话说一开始的产品是没有登录/注册功能的，用的人多了就慢慢有了。出于产品本身的需求，需要对「用户」进行身份识别。
在现实社会中，我们每个人都有一个身份ID：身份证。当我到了16岁的时候，第一次去公安局领身份证的时候，就完成了一次「注册」行为。然后我去网吧上网，身份证刷一下，完成了一次「登录」行为。
那么对于虚拟世界的互联网来说，这个身份证明就是「账号+密码」。
常见的登录/注册方式有：
账号密码注册
在互联网的早期，个人邮箱和手机覆盖度小。所以，就需要用户自己想一个账号名，我们注册个QQ号，就是这种形式。
邮箱地址注册
千禧年之后，PC互联网时代快速普及，我们都创建了属于自己的个人邮箱。加上QQ也自带邮箱账号。由于邮箱具有个人私密性，且能够进行信息的沟通，因此，大部分网站开始采用邮箱账号作为用户名来进行注册，并且会在注册的过程中要求登录到相应邮箱内查收激活邮件，验证我们对该注册邮箱的所有权。
手机号码注册
在互联网普及之后，智能手机与移动互联网发展迅猛。手机也成为每个人必不可少的移动设备，同时移动互联网也已经深深融入每个人的现代生活当中。所以，相较于邮箱，目前手机号码与个人的联系更加紧密，而且越来越多的移动应用出现，采用手机号码作为用户名的注册方式也得到了广泛的使用。
到了 2020 年，微信用户规模达 12 亿。那么，微信账号，起码在中国，已成为新一代互联网世界的「身份标识」。
而对微信小程序而言，天然就能知道当前用户的微信账号ID。微信允许小程序应用，能在用户无感知的情况下，悄无声息的「登录」到我们的小程序应用中去，这个就是我们经常称之为的「静默登录」。
其实微信小程序的登录，跟传统 Web 应用的「单点登录」本质是一样的概念。
单点登录：在 A 站登录了，C 站和 B 站能实现快速的「静默登录」。
微信小程序登录：在微信中，登录了微信账号，那么在整个小程序生态中，都可以实现「静默登录」。
由于 Http 本来是无状态的，业界基本对于登录态的一般做法：
cookie-session：常用于浏览器应用中
access token：常用于移动端等非浏览器应用
在微信小程序来说，对于「JS逻辑层」并不是一个浏览器环境，自然没有 Cookie，那么通常会使用 access token 的方式。
小程序 登录 设计 第3篇
微信官方提供的登录方案，总结为三步：
前端通过 () 获取一次性加密凭证 code，交给后端。
后端把这个 code 传输给微信服务器端，换取用户唯一标识 openId 和授权凭证 session_key。（用于后续服务器端和微信服务器的特殊 API 调用，具体看：微信官方文档-服务端获取开放数据）。
后端把从微信服务器获取到的用户凭证与自行生成的登录态凭证（token），传输给前端。前端保存起来，下次请求的时候带给后端，就能识别哪个用户。
如果只是实现这个流程的话，挺简单的。
但要实现一个健壮的登录过程，还需要注意更多的边界情况：
收拢 () 的调用：
由于 () 会产生不可预测的副作用，例如会可能导致session_key失效，从而导致后续的授权解密场景中的失败。我们这里可以提供一个像 () 的方法，掌握 () 控制权，对其做一系列的封装和容错处理。
调用的时机：
通常我们会在应用启动的时候（ () ），去发起静默登录。但这里会由小程序生命周期设计问题而导致的一个异步问题：加载页面的时候，去调用一个需要登录态的后端 API 的时候，前面异步的静态登录过程有可能还没有完成，从而导致请求失败。
当然也可以在第一个需要登录态的接口调用的时候以异步阻塞的方式发起登录调用，这个需要结合良好设计的接口层。
以上讲到的两种场景的详细设计思路下文会讲到。
并发调用的问题：
在业务场景中，难免会出现多处代码需要触发登录，如果遇到极端情况，这多处代码同时间发起调用。那就会造成短时间多次发起登录过程，尽管之前的请求还没有完成。针对这种情况，我们可以以第一个调用为阻塞，后续调用等待结果，就像精子和卵子结合的过程。
未过期调用的问题：
如果我们的登录态未过期，完全可以正常使用的，默认情况就不需再去发起登录过程了。这时候我们可以默认情况下先去检查登录态是否可用，不能用，我们再发起请求。然后还可以提供一个类似 ({ force: true })的参数去强行发起登录。
1. 应用启动的时候调用
因为大部分情况都需要依赖登录态，我们会很自然而然的想到把这个调用的时机放到应用启动的时候（ () ）来调用。
但是由于原生的小程序启动流程中， App，Page，Component 的生命周期钩子函数，都不支持异步阻塞。
那么我们很容易会遇到 发起的「登录过程」在 的时候还没有完成，我们就无法正确去做一些依赖登录态的操作。
针对这种情况，我们设计了一个状态机的工具：status
基于状态机，我们就可以编写这样的代码：
2. 在「第一个需要登录态接口」被调用的时候去发起登录
更进一步，我们会发现，需要登录态的更深层次的节点是在发起的「需要登录态的后端 API 」的时候。
那么我们可以在调用「需要登录态的后端 API」的时候再去发起「静默登录」，对于并发的场景，让其他请求等待一下就好了。
以 作为 () 封装的「网络请求层」，做一个简单的例子：
当自定义登录态过期的时候，后端需要返回特定的状态码，例如：AUTH_EXPIRED 、 AUTH_INVALID 等。
前端可以在「网络请求层」去监听所有请求的这个状态码，然后发起刷新登录态，再去重放失败的请求：
那么如果并发的发起多个请求，都返回了登录态失效的状态码，上述代码就会被执行多次。
我们需要对 () 做一些特殊的容错处理：
请求锁：同一时间，只允许一个正在过程中的网络请求。
等待队列：请求被锁定之后，调用该方法的所有调用，都推入一个队列中，等待网络请求完成之后共用返回结果。
熔断机制：如果短时间内多次调用，则停止响应一段时间，类似于 TCP 慢启动。
示例代码：
我们从上面的「静默登录」之后，微信服务器端会下发一个 session_key 给后端，而这个会在需要获取微信开放数据的时候会用到。
而 session_key 是有时效性的，以下摘自微信官方描述：
翻译成简单的两句话：
session_key 时效性由微信控制，开发者不可预测。
可能会导致 session_key 过期，可以在使用接口之前用 检查一下。
而对于第二点，我们通过实验发现，偶发性的在 session_key 已过期的情况下， 会概率性返回 true
社区也有相关的反馈未得到解决：
小程序解密手机号,隔一小段时间后,checksession:ok,但是解密失败
有效，但是解密数据失败
checkSession判断session_key未失效，但是解密手机号失败
所以结论是：可靠性是不达 100% 的。
基于以上，我们需要对 session_key 的过期做一些容错处理：
发起需要使用 session_key 的请求前，做一次 操作，如果失败了刷新登录态。
后端使用 session_key 解密开放数据失败之后，返回特定错误码（如：DECRYPT_WX_OPEN_DATA_FAIL），前端刷新登录态。
示例代码：