不懂就问，请教一下前端无感刷新 token 到底有没有意义？

在技术网站看到过无数次前端无感刷新 token 的文章，一直很费解，为啥要刷新 token 呢？那前端给 token 刷新了，token 还有啥意义呢？

文章给出的原因是，用户正操作着呢，token 突然过期，跳登录页用户体验不好。

实现步骤：
accessToken 简称 at ，refreshToken 简称 rt
1. rt 有效期长，at 有效期短
2. at 过期了拿 rt 换 at ，重新请求

疑问：
1. 既然 rt 长期有效，直接用 rt 有啥问题
2. 如果从安全考虑，rt 被抓包拿了，也没辙呀
3. 既然后端知道用户操作了，如果是非异常操作，就自动给 token 延时行不？

不知道该方案具体是为了什么，还请大神们赐教。希望接到类似需求老哥们聊聊

PS：轻喷，心平气和

看到一个银行的实现，accessToken 有效期 2 分钟

针对新的疑问： 1. 不通知； 2. 只能等待过期，所以才设计较短的有效期来一定程度上规避安全风险。

纯粹就是为了性能，和安全性/分布式什么的一点关系都没有。 at 是离线校验，不读数据库。 rt 是在线校验，需要访问数据库。 假设某种业务每个小时访问接口 1000 次，at 有效期 1 个小时。此时每个小时可以省 999 次访问数据库。只有过期的那次才需要刷一下

另一方面。我就在我之前公司 app 上碰到过。无聊的黑客，登陆了就拿着 token 无限制的做任何事。等你发现的时候已经受损失了。如果是双 token 机制，上线的时候就会把访问频率考虑进去。单 token 的，大部分程序员应该实现的就是又不是不能用策略。。防刷？想啥呢。。。

所有用无限期的 token 的时候都一定有过临时 token 。比如后台某个服务/脚本临时用个 token 。。然后时间长了，这个 token 就无法改了，特别的蛋疼。token 就应该是无状态的，一定时间内轮换。不然请用 cookie/session 机制。

类 JWT 场景下，at 是用签名来验证，而不用实际比对数据库。当发生某些需要 revoke token 的场景时，如果 at 的有效期足够短，可以不实现。等到过期校验 rt 时，发现不可用了，再进行退出。

去年实习的时候有在掘金提过类似的问题，也是关于双 token 的意义的。实习公司做的小项目也要上双 token ，到现在仍旧没有一个能够彻底说服我的理由。

安全性考虑，在 JWT 场景，at 有效期不能太久，因为无法踢掉。rt 重新签发，能做一些安全校验。

这个话题展开讲的话内容太多了，简单说就是一切还是要回归到你的业务需求上，rt 存在本身肯定是有意义的