一种策略是在服务端专门开一个刷新令牌的接口，另一种是通常的业务接口里就附带判断“即将过期”的功能，然后自动在返回时带上新令牌。

以前一直在用后者，但是发现前者的也很多。刚看到个说法是当客户端并发请求时可能会造成生成一堆新的token返回给前端。（问题大吗？如此小概率的时间尽情让它生也没事吧）

后者或许还有个弊端是判断是否“即将过期”，会增加一些开销。而如果选用前者，这部分开销就由客户端承担了。

前者的弊端是，当刷新间隔小的时候，那个刷新接口就会调用很频繁，增加很多开销。后者在普通的业务请求里就包含了更新token功能，当然比业务通信和刷新token通信分开调用更能节约网络资源。

如果间隔长，那么前者没啥问题，很清爽，如果间隔短呢，是不是后者更好？减小了刷新接口的通信开销？

所以是不是应该两者并用根据实际情况取舍？

以上是问题一。

然后网上还看到一种长短令牌的策略，大意是登陆成功后生成一长一短（过期时间长短不同）两个token，如果短的过期而长的没过期，就调用刷新令牌的接口，用长令牌当token去重新获取一对长短token。感觉很画蛇添足。你客户端是能拿到jwt的过期时间的，自己判断一下距离过期还有多久不就行了吗？但“科普”这策略的博文也有好几篇，不知道是有啥我没考虑到的原因还是天下文章一大抄。
有个推测，或许是因为发明或推广这套策略的同行们不知道客户端也能从jwt里拿到过期时间？
这套策略的好处是降低泄露风险？但是你在刷新令牌的请求中带个刷新token专用的密文也是一样的效果吧。即每次刷新后服务端根据用户身份信息生成一个密文保存在客户端，平时业务请求用不上，只有刷新时才带上，同样能降低被网络嗅探的风险。这在安全性方面不就和长令牌一样么，逻辑更简单还省开销（你完全不需要通过发短token被拒来发现自己的短token过期，这是完全不必要的通信开销），服务端也不用为了长短令牌再增加一套jwt验证机制出来，原本的jwt验证该怎样还是怎样，因为token没过期，而密文验证功能放业务逻辑里即可。

或者刷新token的接口，直接用不对称加密+临时秘钥的策略来做？那就特别安全了，就不太确定开销是否值得，不知道大家在实际工作中如何取舍。