目录
复盘双token方案在项目中的实际应用
前言
笔者需要实现token的无感刷新，具体点说就是假设用户一直在使用，就会无感给用户的token进行刷新，不需要到点强制让用户重新登录，只有用户长时间不使用的情况下，过了设定时间后才强制用户登录
方案
现在有两个可选的方案：
- token+redis
将token的过期时间放在redis中进行维护 - 双token
将token分为长短两个token：access_token和refresh_token。access_token的过期时间短，比如2小时，平时调用接口的时候只需要带上这个token做验证就行了；refresh_token的过期时间长，比如7天，当access_token过期时，如果refresh_token没有过期，那么就带上它去访问token的刷新接口，返回新的长短token，达到无感刷新的效果，如果refresh_token过期了，提示用户重新登录（长token跟session的作用差不多）
两个方案的优劣：
前者的优势在于实现起来只需要后端改一下就好了，前端几乎不需要做改动，这种方案容易理解，做起来也比较简单，这是传统的做法；劣势在于对redis的依赖，如果redis挂了，系统就登录不了了，有条件配置redis集群的当我没说
后者的优势：1)去除了对redis的依赖 2)短token可以防止被截获后无休止使用，长token又可以保证活跃用户不用一直登录 3)安全性更高，长token只有在第一次获取和刷新短token时才会在网络中传输，暴露的风险小很多；劣势：对前端的改动比较大，前端改动需要处理一些额外的并发问题比较麻烦
方案2前端如何改造的参考文章：
https://blog.csdn.net/u010952787/article/details/121655780
https://blog.csdn.net/m0_48468380/article/details/121577011
https://blog.csdn.net/long99920/article/details/124638211
https://juejin.cn/post/7035280102636126244
实现的结果
后端由笔者完美实现，前端则是由公司的同事去实现，然后，今天做复盘的时候，去翻了一下前端的代码，发现在刷新token的时候，前端并没有做二次请求(参考上面的文章，短token过期的请求应该被缓存起来，然后做二次请求)，也没有处理并发问题(同一时间大量请求的短token过期，应该设置一把锁，只有一个请求去刷新长短token，剩下的同样缓存起来，后续挨着重新请求)，只是简单的加一把锁去刷新长短token，本次请求和后续请求全部丢掉，不重新请求，仅此而已，就是下面的效果：
不翻不知道，一翻吓一跳，额滴神呀，加油，咱复盘到这了，已经很棒啦。