腾讯技术研发工程师 rileycai 原创
对于小程序开发者而言，如何标识一个用户的登录状态？
微信团队提供 2 种标识方式：OpenId 和 UnionId。每个用户在同一个小程序内拥有唯一的 OpenId 和 UnionId，该 2 项 ID 仅限于标记用户登录状态，不涉及任何用户头像、昵称、手机号等隐私信息。只要用户再次进入小程序，开发者仍然能够标识用户的登录态，例如大家在使用防疫健康码过程中，登录态标识能够实现无需每次手动登录，便利使用流程。作为登录态标识方式，通过 wx.login 实现 静默登录 成为小程序开发过程中不可缺少的业务场景。然而，这项小程序开发的 “必选题” 需要什么 “解题技巧” ？你是否已经掌握？以下内容详细分享静默登录的那些事儿——
静默登录原理是什么
静默登录方式主要是通过以下 3 个步骤完成：
小程序端调用 wx.login() 获取临时登录凭证 code ，并回传到开发者服务器
服务器端调用 auth.code2Session 接口，换取用户唯一标识 OpenId 和会话密钥 sessionKey，关联生成自定义登录态 auth-token，并为每一位用户分配唯一的用户 id (uid)，初始化用户信息
开发者服务器将根据用户标识生成的自定义登录态 auth-token 和用户信息返回给小程序端，小程序接收并存储到本地
如何应用静默登录
Step 1: 启动时调用 authLogin.login
如果每次启动小程序都重新发起静默登录，必然阻塞部分核心业务请求。因此只要保证登录态仍然有效，当用户再次进入小程序时，就无需发起静默登录流程。
登录态有效的判断依据有两点：一是本地 storage 中是否存在 auth-token；二是调用 wx.checkSession 判断 sessionKey 是否过期。
当用户启动小程序时，主要有以下 4 种场景：
根据场景，封装 login 函数供小程序启动时 onLaunch 生命周期调用。如下图所示，判断本地是否存在 auth-token 以及 sessionKey 是否过期，如果存在且未过期，则将状态机状态扭转到成功，返回 Promise.resolve()。否则，发起静默登录流程。
Step 2: 发起请求时调用 authLogin.refreshLogin
小程序启动后，发起静默登录请求。具体流程如下：
请求拦截器需要进行如下操作：
判断该请求是否需要鉴权：请求发起时，拦截请求，判断请求是否需要添加 auth-token。如不需要，直接发起请求。如需要，执行第二步
判断是否需要发起静默登录：判断 storage 中是否存在 auth-token。如不存在，发起「刷新登录」
请求头部添加 auth-token：添加 auth-token，发起请求
响应拦截器则进行如下操作：
状态码为 AUTH_FAIL：服务端返回 code 为 “鉴权失败”，触发这种情景有 2 个原因：一是接口需要鉴权，但是发起请求时未携带 auth-token；二是 auth-token 过期。这时将上一次请求携带的 auth-token 与本地存储的 auth-token 比较。如果不一致，表示登录态已经刷新，直接重新发起请求；如果一致，发起刷新登录，拿到新的 auth-token 后重新发起请求，用户无感知该过程
状态码为 USER_WX_SESSIONKEY_EXPIRE：服务器返回 code 为 “用户登录态过期”。因此需要重新发起静默登录，等待用户重新点击授权按钮获取新的加密数据，然后发起新的解密请求
状态码为其它：比如 Success 或者其他业务请求错误的情况，不进行拦截，返回 response 让业务代码解析
需要注意的是，每个业务请求被拦截时，都会触发 authLogin.refreshLogin 来发起静默登录，但是理想状态下，静默登录请求只需要发起一次。建议使用 Promise 单例模式或者单任务队列模式进行优化，只发起一次静默登录请求，请求成功返回时所有被挂起的请求能够正常发起。
Step 3: 等待静默登录结果调用 authLogin.waitAuth
在具体的实践中，某些业务场景需要等待静默登录请求结果，从而拿到用户信息，比如是否授权登录等等。因此有必要封装一个 authLogin.waitAuth 方法供业务方调用等待静默登录结果。
静默登录流程几乎是小程序开发都会遇到的业务场景。从启动、请求发起到等待结果，每种实现方法大同小异。后续还可以基于云函数、promise 单例模式、单任务队列模式进行优化，不断满足小程序用户体验。
