258资源分享网

下图是小程序官方文档中的登录时序图。此图涵盖了前后端，详细讲解了包括登录态的生成，维护，传输等各方面的问题。

发起网络请求的流程图

具体到业务开发过程中的前端来说，我认为上图还不够完整，于是我画了下面这张以前端逻辑为出发点的、包含循环的流程图。 我认为前端每一次发起网络请求，跟后台进行数据交互，都适用于下图的流程： 

hasChecked： 用一状态标识本生命周期内是否执行过wx.checkSession，判断该标识，若否，开始执行wx.checkSession，若是，进入下一步

wx.checkSession()： 调用接口判断登录态是否过期，若是，重新登录；若否，进入下一步

wx.checkSession()是小程序提供的检测登录态是否过期的接口，生命周期内只需调用一次即可。用户越久未使用小程序，用户登录态越有可能失效。反之如果用户一直在使用小程序，则用户登录态一直保持有效。具体时效逻辑由微信维护，对开发者透明

wx.getStorage(session)： 尝试获取本地的session。如果之前曾经登录过，则能获取到；否则，本地无session

wx.login()： 小程序提供的接口，用于获取code（code有效期为5分钟）

wx.request(code)： 将code通过后台提供的接口，换取session

wx.setStorage(session)： 将后台接口返回的session存入到localStorage，以备后续使用

wx.request(session)： 真正发起业务请求，请求中带上session

parse(data)： 对后台返回的数据进行预解析，若发现登录态失效，则重新执行登录；若成功，则真正获取到业务数据拓展小程序网络请求的能力

只要遵循上图的流程，我们就无需在业务逻辑中关注登录态的问题了，相当于把登录态的管理问题耦合到了发起网络请求当中。 一般情况下，我们程序设计都会遵循模块解耦的原则，尽可能将模块颗粒化到最小。这导致可能有些同学认为模块耦合不是好事情，但是我认为这是要分情况的：

小程序区别与传统的H5，不支持cookies，在代码层级上讲，这无形中就给登录态的管理增加了复杂度：cookies会在H5的每个请求中自动带上，但小程序的请求却每次都需要手动带上登录态参数

小程序区别于基于公众号登录的H5来说，又存在一定的优势：登录授权时并不需要多次的页面跳转（Oauth），也正因为如此，小程序的请求在登录态失效时，需要具备重新登录并自动重试请求的能力（无页面刷新感，用户甚至都不能感知到进行了重新登录）

以上两点虽然是登录态管理的问题，但从另外一个角度去理解，我更认为它是小程序网络请求的能力问题，所以，我认为通过拓展小程序网络请求能力来实现登录态的自动管理是非常合适的。通用组件——weRequest

一个通过拓展wx.request，从而实现自动管理登录态的组件。 先来看看怎么使用：

var weRequest= require('../weRequest'); // 初始化配置 weRequest.init({ // 关于配置内容，将在后文详述 // 此处暂时省略... }) // 发起请求 weRequest.request({ url: 'order/detail', data: { id: '107B7615E04AE64CFC10' }, success: function (data) { // 省略... } })

引入weRequest组件

初始化组件配置

就像使用wx.request那样去使用它自动带上登录态参数

我们来看看执行上面代码的DEMO效果： 

可以看到，通过weRequest发出的请求，将会自动带上登录态参数。 对应的流程为下图中红色的指向： 
没有登录态时，自动登录

那如果当前小程序并没有登录态的情况又会如何呢？ 接下来我们来看看本地无登录态情况下的模拟：