本文的前提是建立在假定你已經熟知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