楼主目测只是看看文档，没有实际经手一个完整的项目

session 只是一个概念，一个记录 client 状态的实现，这个角度来说，JWT 本身也是一种 session。而 HTTP 都是使用 cookie 来实现了，这点谁都一个卵样（极少数使用 URL 的 id 化来实现，然后无法避免一旦有人无意分享了这个 URL，顺便也把自己的登陆状态分享出去了，比如以前新浪微博的手机版，靠 URL 里面的 gsid 参数来识别登陆的状态）。

JWT 只是签名过的 cookie，一个有实现规范的协议而已，事实上就是一个加密的 cookie，保存信息容量有限，无法解决服务端过期的实现（可以服务端记录 JWT id 和 timestamp 做到，不过这样不是又回到服务器 session 的实现了么？）还有就是楼上的持久化劫持的问题，在需要大量保存用户数据（超过 JWT cookie 容量的时候），一样需要服务器侧的支持，此时又退化为服务器侧的 session 了。而 JWT 所说的只保存用户 id，根本就是伪命题，数据回到服务器，只有 id 你一样要根据 id 去数据库或者缓存查一次用户 user 自己的其他信息如 name，mail，这时候又退化为服务器侧的 session 了，完全失去其分布式的初衷

服务器的 session 就是一个随机字符串 id 的 cookie 放客户端，服务器来保存该 id 对应的数据，的确是用分布式 session id 同步的问题。然而，多数时候，session id 的保存都在单独的 redis 服务器上了，不是淘宝那样的存在，几台 redis 足够你刷到数千万用户了，根本没有什么好担心的

说到底，还是 HTTP 这个协议已经决定了你的实现的方法，session 能折腾的方向实在不多。而大多数网站的实现都是服务器端的 session，此时，你就应该好好想一下，JWT 是不是有天生的缺陷。

再者退一万步来说，身份识别和保持这事情，不使用中心化的识别和认证是及其困难的事情，无论现在的各种签名、各种算法，其背后还是有着中心化的担保和识别的。

道理都是简单如此

以上，希望有用