其實我更想聊標題的前半部分，後半部分只是拉出來做典型的。
簡歷上寫上一句，“熱衷於學習新技術”，孬管是不是真的，至少加分項是可以有的。
再看看標題，我是來搞笑的？
學習與使用，兩回事
學習側重於新技術的HOW、WHAT、Where（其實實際過程中很多時候後兩個是忽略的）
使用側重於。。。。。填坑！
開始我們的主題
標題寫的，為什麼？
在我看來
除非你是真的知道新技術到底解決了怎樣的問題
除非你很清楚新技術有什麼優點和缺點
或者至少你要知道新技術是用於什麼場景的
你再用新技術也不遲，否則，就慢慢填坑！
否則，就是為了時髦買了條帶洞的內褲卻發現洞的位置不對還得再買一條正常的內褲！
JWT，拉出來當典型
為了避免被噴成篩子，三連劃重點
JWT本身沒有錯！
JWT本身沒有錯！
JWT本身沒有錯！
無狀態沒有錯！
無狀態沒有錯！
無狀態沒有錯！
我們聊的JWT對標的是 Session ，不是 Cookie
我們聊的JWT對標的是 Session ，不是 Cookie
我們聊的JWT對標的是 Session ，不是 Cookie
錯的是什麼？是盲目使用
在座各位有多少人能準確回答出上一節的三個問題？
- 你真的知道JWT到底解決了怎樣的問題？
- 你很清楚JWT有什麼優點和缺點？
- 你知道JWT是用於什麼場景的？
給自己一個靠譜的答案，你為什麼要用JWT？
我百度谷歌搜尋了一下，發現用 JWT 的文章真的是少數，用 Identity 和 Session 的文章很多，這超出了我的預料
為什麼身邊的專案包括群友公司的專案全是 JWT？
JWT 與登入
JWT 的核心是無狀態、自驗證、無中央伺服器，有超時時間等機制，我們所實現的登入功能，本質上是一個狀態保持的機制，要保持，就會有斷開的需求，JWT 能實現斷開嗎？不能。
JWT 的核心應用場景根本不是狀態保持！
https://www.baidu.com/s?wd=jwt會話保持&rsv_spt=1&rsv_iqid=0x9d65b70000004423&issp=1&f=8&rsv_bp=1&rsv_idx=2&ie=utf-8&tn=baiduhome_pg&rsv_enter=1&rsv_dl=tb&rsv_sug3=11&rsv_sug1=10&rsv_sug7=100&sug=jwt%E4%BC%9A%E8%AF%9D%E4%BF%9D%E6%8C%81%20%E5%88%B7%E6%96%B0&rsv_n=1&rsv_t=576d%2BK65G9Uk60klbPpQEAyfnAnSKdDcE476BRPqSajtXpQkE0rXpLQDtHtdE8AvX51v&rsv_sug2=0&rsv_btype=i&inputT=4864&rsv_sug4=4864
百度早已有了不要用JWT做狀態保持的文章，這根本就不是一回事！
JWT 的核心在於不需要中央伺服器的驗證，它可沒說驗證狀態要保持啊。是的，超時時間的機制確實很像狀態保持，但是因為 JWT 無狀態的特性，它難以實現狀態保持的完整功能。
比如說，我想續期，怎麼辦？
有的同學說了，舊KEY作廢發個新KEY，作廢的KEY儲存在記憶體當中
你這和“我為了潮流買了個有洞的內褲結果發現外面還得再套一個內褲才不冷”有啥區別呢？
沒錯，這位同學的方案就是大家的方案，可是，這麼明顯的問題（不是JWT的問題），你為什麼還要堅持JWT？
堅持JWT的重點就是無狀態，然而作廢的KEY儲存在記憶體中不就又回到了有狀態嗎？你為什麼還要堅持JWT？
大哥們推薦JWT的理由
我所知道的理由如下。無狀態這條就不用說了：
- 不走 Cookie，移動端沒有 Cookie
- 比 Cookie 更安全，CSRF攻擊
這兩條都有一個相同的問題，不用 JWT 就非得用 Cookie？
JWT 對標的解決方案是 Session，不是 Cookie
有人說 Session 就是基於 Cookie 的。
那麼，Cookie 是基於什麼的？基於 HTTP 頭的
JWT呢？不還是 HTTP 頭嗎？
都是從頭裡讀的，我改一下不從 Cookie 欄位讀不就行了？
有人又說，這不麻煩啊，現成的JWT方案很多，拿過來就用。
那麼，出問題的時候你是加班到十點還是第二天第一個人打卡？
再者，Session 不見得沒有方案，老外那幫人天天可是閒得慌。
JWT 的應用場景
這麼說，JWT是。。。。廢物？
哎別噴我啊你看完再噴呀。。。。。
我一直在找 JWT 的應用場景，但是除了三高（高併發、大資料、高可用）場景之外，我是真沒找到合適的。。。
但是谷歌還是有大神，有位大神表示下面這個場景適用於 JWT
郵箱連結驗證
這功能大家都知道，向使用者郵箱發個連結，要求這個連結在5分鐘之內點選來驗證郵箱有效性，這個場景用 JWT 再適合不過了，量身定作的。
其他的，我是真不知道有啥場景。
不要再一切皆 JWT了
JWT 本身沒有錯，錯在所有的專案全是 JWT。
JWT 場景之一是用於解決使用者量併發量較大時，中央伺服器無法及時響應請求的問題，Redis 在資料量達到一定程度後，QPS會大幅度降低，可是，這個量級是多少？至少幾百萬起步吧，我沒試過。
各位看官你先把你的專案的日活使用者量搞到幾百萬再說好不好，日活幾百萬距離幾百萬併發還差得遠呢。