一种策略是在服务端专门开一个刷新令牌的接口，另一种是通常的业务接口里就附带判断“即将过期”的功能，然后自动在返回时带上新令牌。
以前一直在用后者，但是发现前者的也很多。刚看到个说法是当客户端并发请求时可能会造成生成一堆新的token返回给前端。（问题大吗？如此小概率的时间尽情让它生也没事吧）
但如果是前者，当刷新间隔小的时候，那个刷新接口会调用很频繁增加很多开销。
如果间隔长，那么前者没啥问题，很清爽，如果间隔短呢，是不是后者更好？减小了刷新接口的通信开销。
或者可以两者并用？
以上是问题一。
然后网上还看到一种长短令牌的策略，大意是登陆成功后生成一长一短（过期时间长短不同）两个token，短的过期长的没过期时就调用刷新令牌的接口，用长令牌当token去重新获取一对长短token。感觉很画蛇添足。你客户端是能拿到过期时间的，自己判断一下距离过期还有多久不就行了吗？但“科普”这策略的博文也有好几篇，不知道是有啥我没考虑到的原因还是天下文章一大抄。
唯一的好处是降低泄露风险？但是你在刷新令牌的请求中带个刷新token专用的密文也是一样的效果吧。（即每次刷新后服务端根据用户身份信息生成一个密文保存在客户端，平时业务请求用不上，只有刷新时才带上，降低被网络嗅探的风险。这在安全性方面不就和长令牌一样么，逻辑更简单还省开销，服务端也不用为了长短令牌再增加一套jwt验证机制出来，原本的jwt验证该怎样还是怎样，因为token没过期，而密文验证功能放业务逻辑里即可）
或者刷新token的接口，直接用不对称加密+临时秘钥的策略来做？那就特别安全了，就不太确定开销是否值得，不知道大家在实际工作中如何取舍。
