一. 前言
1.关于JWT的Token过期问题,到底设置多久过期？
(1).有的人设置过期时间很长，比如一个月，甚至更长，等到过期了退回登录页面,重新登录重新获取token，期间登录的时候也是重新获取token，然后过期时间又重置为了1个月。这样一旦token被人截取，就可能被人长期使用，如果你想禁止，只能修改token颁发的密钥，这样就会导致所有token都失效，显然不太可取。
(2).有的人设置比较短，比如10分钟，在使用过程中，一旦过期也是退回登录页面，这样就可能使用过程中经常退回登录页面，体验很不好。
2. 这里介绍一种比较主流的解决方案---双Token机制
(1).访问令牌：accessToken，访问接口是需要携带的，也就是我们之前一直使用的那个，过期时间一般设置比较短，根据实际项目分析，比如：10分钟
(2).刷新令牌：refreshToken，当accessToken过期后，用于获取新的accessToken的时候使用，过期时间一般设置的比较长，比如：7天
3.获取新的accessToken的时候, 为什么还需要传入旧accessToken，只传入refreshToken不行么？
仔细看下面的解决思路，只传入refreshToken也可以，但是传入双Token安全性更高一些。
二. 解决方案
1. 登录请求过来，将userId和userAccount存到payLoad中，设置不同的过期时间，分别生成accessToken和refreshToken，二者的区别密钥不一样，过期时间不一样，然后把 生成refreshToken的相关信息存到对应的表中【id，userId，token，expire】，一个用户对应一条记录（也可以存到Redis中，这里为了测试，存在一个全局变量中）， 每次登录的时候，添加或者更新记录，最后将双Token返回给前端，前端存到LocalStorage中。
2. 前端访问GetMsg获取信息接口，表头需要携带accessToken，服务器端通过JwtCheck2过滤器进行校验，验证通过则正常访问，如果不通过返回401和不通过的原因，前端在Error中进行获取,这里区分造成401的原因。
