关于使用JWT我的一些建议及避坑指南（非必须建议别用）

本文的前提是建立在假定你已经熟知jwt和session是什么及相应的工作原理和用法皆有所了解，生产中也有实际的使用。

关于jwt的一些不足之处，可以参考这里：（译）别再使用 JWT 作为 Session 系统！问题重重且很危险。

JWT存在的意义是什么？很显然就是：自包含，去中心化，无状态化！ 这是他存在的核心价值和意义，除去这两点JWT可以说是一无是处！又长又啰嗦。还不安全，动不动就超长，比如我一个项目有500多菜单，我尝试使用jwt，且在payload存入用户角色，比如管理员就有60-100个角色，生成的JWT-TOKEN长度都快赶上一本小说或自传的长度了。哈哈哈哈！当然这是蒙太奇手法，夸张了点！

如果你正在尝试使用JWT构建session方案，我直接告诉你，赶紧放弃！越早越好！JWT 在作为 session 时， 最大的痛苦就是自动续期和指定失效 2 个方面是致命伤。而且无解！不管你用任何方式实现。最终都抛离了jwt存在的本源

最重要的，不要考虑在服务器维护 JWT，比如在服务端维护一个 token 黑名单以实现指定失效这种操作！又或者维护一个refresh_Token列表以实现自动续期。不管你是以任何方法、任何方案都不要尝试！直接放弃！不然最终就变成了为用而用、越搞越复杂，让本身无状态的jwt 变成了有状态，最终失去了jwt存在的意义！倒不如一开始就直接用自定义token 存redis来的又直接又方便又高效！

反过来想想，你倾慕于jwt的无状态化和去中心化，想着不依赖session,可以为所欲为的横向扩展而不用操心session的复制同步和跨域访问问题，但是你又想实现服务器可以管控签发的jwt token 可以做到人走茶凉，注销了就作废这个jwt token.你能做到吗？答案是no.你根本做不到。jwt token中自带的过期时间，让服务端对签发的jwt token彻底失控,你要想实现，你就要在服务器维护黑名单，而且还要各种折腾写redis保存。而且你要实现jwt-token过期后能自动续期，你还要费劲心思。实现refresh Token，access_Token，来加持，将refresh Token存在服务端redis中。。。。。这里省略一万字。不想多说了。都已经用redis了，给前端一个固定不过期的token又或者在redis中保存一个有过期时间的token，每次请求在拦截器中更新redis中token的过期时间难道不香吗？取用户信息的时候直接从token中获取，退出后干掉redis 中的token！不但前端省事后端也省事啊！

不说了。给大家几个连接自己去看看，有这种牢骚的人还不至我一个人

https://blog.csdn.net/KimSoft/article/details/107305108

https://blog.csdn.net/weixin_39612058/article/details/110801369

https://blog.csdn.net/m0_37809141/article/details/86572697

https://blog.csdn.net/qq_32565267/article/details/104651829

https://learnku.com/articles/22616