我觉得把 Token 放在 Header 里更好一些

前后分离的基本都这么做了吧

我的观点：

1. 事情该怎么做就怎么做，不是因为迎合写不好代码的人，而改变这件事本来的样子；
2. 自动刷新并返回 token 这件事，论坛里面有帖子，你可以自行实现，但是我不觉得这是一个正确的事情，也不会写在教程里面。服务端做好自己该做的事情，每个接口的作用都很明确，为什么要主动给客户端刷新一个 token？为什么一个过期了的 token 可以请求成功？难道没有安全问题？
3. 时间信息接口已经返回了，客户端在调用请求之前就可以判断当前的 token 是否可用，过期了就先刷新。

@liyu001989

• 第 2 个问题，我觉得这样做不会增加或减少安全性。
• 第 3 个问题，客户端按照过期时间去判断 token 是没问题的，但是依然无法避免在 token 到期的时候把一个请求变成了两个请求，多增加了一个刷新 token 的请求。尤其是在 token 过期时间过短的情况下，用户会感觉每过一会，网络请求就会稍微慢一次。这个问题客户端要解决就很麻烦的，除非设置一个任务在到期之前主动后台去刷新一次 token。

• 你觉得没有安全问题，就按你的想法做。使用过期 token 能够请求到结果，在我这里是不能接受的；
• 对于 app 可以在每次打开，唤醒等这些时候触发一次 token 检测。几个小时慢一次，不过几百毫秒，这是个问题，不过这不会成为我主动刷新 token 的理由。

@liyu001989

• 我的意思是，在 JWT_REFRESH_TTL 时间内，超过 JWT_TTL 时间的 token，不管是手动刷新还是自动刷新，都不会增加和减少安全性，当然肯定也不能是已经被刷新后失效的 token。

另外有个问题想请教一下，我理解的 token 是不需要在服务端进行存储的，在服务端使用时解码后验证签名无误后直接取 id 这样去用。但是昨天想了想，如果不做存储的话，很难理解服务端是如何判断在 JWT_TTL 时间内旧 token 已经被刷新导致失效了。

感谢答复以及教程 :pray:

所以说了这么多你理解我的意思不？

token 不能主动刷新，自动刷新会带来安全问题，手动刷新和自动刷新是有区别的。

不保存，刷新后加入黑名单，放缓存里面

@liyu001989 我先记下，后面慢慢理解