首先明確：JWT = JSON WEB TOKEN 那麼就很簡單了，Token=令牌，JWT=含有json信息的令牌 用一個形象一點的例子解釋一下Token和JWT的區別與聯繫： 以前醫生開藥單，都是用的龍飛鳳舞的特殊簡寫，你只有把這個藥方拿到指定的取藥處，取藥人根據藥方結合腦中的對照表，就知道這個 ...
首先明確：JWT = JSON WEB TOKEN 那麼就很簡單了，Token=令牌，JWT=含有json信息的令牌 用一個形象一點的例子解釋一下Token和JWT的區別與聯繫： 以前醫生開藥單，都是用的龍飛鳳舞的特殊簡寫，你只有把這個藥方拿到指定的取藥處，取藥人根據藥方結合腦中的對照表，就知道這個藥方代表著什麼意思了。 這就是普通的token，即token本身並沒有實際信息，token代表著什麼意思需要到伺服器端進行對照。 現在醫生開藥單都是電腦開單，藥名什麼的都非常清晰，拿著藥單去哪裡都能看懂，無需任何對照。 這就是jwt，即token本身攜帶了信息，無需到指定的藥房，也無需對照就能知道token代表的信息。 通過這個偽例子，用一句話總結一下token和jwt的區別：jwt是自身包含認證信息的特殊token。 1、token 在傳統的項目中，登錄成功後主要有下邊幾個動作： 後端生成session存儲在資料庫中（一般是Redis） 將session返回給前端，前端將session保存到cookie 後續請求都攜帶sessionID，則後端根據sessionID去資料庫中校驗當前請求是否合法
其中這個sessionID其實就是實際意義上的通行證、令牌，也就是我們常說的Token。
但是我們發現，sessionID一般都是用UUID直接生成的本身沒有實際意義，這個Token代表的信息必須與緩存資料庫中存儲的session信息進行對比才能知道對應的認證信息。
2、jwt
在現在的多數項目中，業務更加複雜，介面鑒權的頻次也越來越高，為了減少和緩存資料庫的數據交換，更多人選擇使用jwt，這樣直接校驗jwt本身即可明確當此請求的主體，無需和Redis中的信息進行對照即可完成鑒權。
jwt的生成和解析都有固定的演算法，裡邊包含了頭信息、載荷信息和簽名，通過指定的解析方法就可得到jwt中的載荷信息，從而判斷當前的請求是誰發起的、請求是否超期等等信息。
