了解一下的原理和工作流程和完整的协作流程有哪些

其实把流程捋清楚了也很简单，题主说到了返回用户的Token信息。在大多数情况下Token和Cookie的作用是一样的，用来保存用户的某一些状态。Cookie一般由浏览器或者客户端自动维护失效状态，服务端也可以根据请求头中的Cookie信息来判断用的某一些状态的合法性，例如登录状态。那么Token就不一样了，它不是Http协议中定义的东西，所以客户端和浏览器都没有对它进行一个规范的实现，因此它由服务端软件和客户端软件来根据自身需求来各自实现，一般服务端会采用标准化的JWT(JSON Web Token)。Token的好处也是显而易见的，比如可以轻松跨域、解耦性更强、对移动端更加友好等……

了解原理

要想真正的搞懂题主的问题，一定要对Token的工作原理和完整的协作流程有一个清晰的认知，因此咱们先来大致了解一下Token的原理和工作流程。

服务端有一个管理Token的缓存类，我们暂且把它叫做TokenCache。说到缓存无非就是增加、删除和查询，再加上一些类似LRU的算法做优化，当客户端登录后服务端会根据当前用户的属性生成一个加密的Token，然后缓存到这个TokenCache中登录token无效，当客户端请求某个接口时，服务端首先会检查客户端是否携带了Token，然后检查Token是否在TokenCache中以验证有效期，最后根据算法解密Token做一些权限逻辑判断。注：这只是一个笼统的过程，很多服务端语言不完全如是。

下面用几个具有代表性的场景配合几张图来说明客户端和服务端的协作流程。不用登录就可以成功请求；也就是不管是否携带了Token，不管Token是否有效就可以正常请求，比如App首页：

2. 需要登录后才可以成功请求，但是用户并没有登录时；没有登录时请求时服务端会返回类似401这样的状态码登录token无效，表示客户端需要登录后才能正常请求：

3. 当客户端进行登录操作时；当客户端在第2步检测到服务端返回无效登录状态时，先应该判断用户是否登录过了，如果用户没有登录客户端应该跳转到登录页面让用户登录：

4. 需要登录后才可以成功请求，并且用户已经正常登录后；这种场景下客户端应该携带了Token，而且Token是有效的：

5. 当用户登录后，过长时间没有请求任何接口，例如登录App就从未打开过，此时服务端保存的Token可能已经失效了，服务端也会返回类似401这样的状态码：

这种场景往往很难查错，往往也是客户端和服务端同学互相甩锅的地方，这一点也是题主提出的问题，当Token失效后到底该怎么办？

解决方案

到这一步我们该总结一下出现问题的两个地方了，除了用户正常点击登录按钮去登录外，有两个地方需要客户端程序自动处理需要登录这个状态。在上述第2步和第5步都会出现登录失效的状态。在此先给出一些比较常见的处理建议：当接口响应401时，客户端应该先检查用户是否已经登录过了。

如果用户没有登录过，客户端程序应该跳转到登录页面让用户登录后再操作。

如果用户登录过，客户端程序应该自动替用户登录，然后再重新请求之前响应401的接口。

第2步很简单，对于第3步就显得有一点复杂了，其实也并不复杂，只是有一部分客户端开发者遇到这个问题时会想，那么多接口请求，难道每一个接口我都需要这样做吗？其实客户端只需要在上面几张图的HttpProcessor处插入一段业务即可，大概流程是这样的：

根据上图中的步骤，我们把插入业务这一段叫做业务拦截器，下面我用伪代码做个示例。

1. 这是负责请求服务端的Http类：

2. 这是插入业务的核心，业务拦截器：

3. 这是处理失效时跳转和其它一些通用业务的HttpManager封装

4. 调用的时候也就很简单了，释放天性咯

总结

现在来总结一下题主的问题，当用户登录后应该加密后保存用户帐号密码，当请求接口时接受到Token失效状态，此时应该检查用户是否登录过，也就是检查是否有保存用户帐号密码，如果没有登录过则直接跳转登录页面让用户登录，如果用户登录过则使用已经保存的帐号密码尝试登录一次，登录成功则重新请求之前返回登录失效状态的接口，如果登录失败则跳转登录页面让用户登录。其中没有登录过跳转登录页面和拦截状态后登录失败跳转登录页面其实最终是一个步骤了，因为客户端只是插入了一段业务而已。