作为一名后端开发者或者网络技术爱好者，你肯定听过无数次“JWT”这个词。它就像是现代Web应用里的“电子通行证”，轻便、自包含，让无状态认证变得异常丝滑。但是你真的懂它吗？或者说你只是停留在“会用库”的层面？

今天咱们不整那些虚头巴脑的学术定义，直接扒开JWT的底裤，用Zui接地气的大白话，结合实战代码逻辑，把它的生成、验证以及Zui核心的“防篡改”机制讲得透透的。相信我，kan完这篇文章，你对JWT的理解绝对会上升一个台阶。

一、 先搞清楚：JWT到底是个什么玩意儿？

简单来说JWT就是一种为了在网络上安全传递信息而设计的紧凑令牌。它的核心价值在于“无状态传递可信信息”。啥意思呢？就是说服务器不需要在内存里存Session，只要把Token发给你，你下次带着Token来我就Neng认出你，因为Token里本身就带着信息，而且我还Neng确信这玩意儿没被改过。

整个流程其实就两大环节：「服务器生成 Token」和「服务器验证 Token」。咱们先别急着kan代码，先在脑子里建立个模型。

二、 JWT的“三明治”结构：解剖一下

一个标准的JWT字符串，长得就像这样一串乱码：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEyMywidXNlcm5hbWUiOiLlvKDkuIkicm9sZSI6InVzZXIiLCJleHAiOjE3Mzc2NDY4MDB9.xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

别被这串字符吓到了其实它就是一个“三明治”，被两个小数点 . 分成了三部分，按顺序分别是：

Header说明书，告诉人家这玩意儿咋处理的。

Payload干货区，真正要传的数据dou在这。

Signature防伪标，这是JWT安全的灵魂。

1. Header：规则说明书

Header部分主要描述Token的元数据。通常它是一个JSON对象，里面指定了签名算法和类型。

原始 JSON

{
  "alg": "HS256",
  "typ": "JWT"
}

这里 alg 代表算法，咱们常用 HS256；typ 就是类型，固定是 JWT。

但这只是JSON，网络传输不方便，所以我们要把它转成 Base64 编码。得到类似这样的一串字符：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

注意：这里有个坑，Base64 是编码不是加密，任何人douNeng解码回原文。所以Header里千万别放机密信息！

2. Payload：业务数据载体

这部分就是咱们真正要传递的业务数据了比如用户ID、用户名、角色等等。

原始 JSON

{
  "userId": 123,
  "username": "张三",
  "role": "user",
  "exp": 1737646800  // 代表 2025-01-25 12:00:00 过期
}

同样，这段JSON也会被Base64编码，变成：

eyJ1c2VySWQiOjEyMywidXNlcm5hbWUiOiLlvKDkuIkicm9sZSI6InVzZXIiLCJleHAiOjE3Mzc2NDY4MDB9

这里必须强调一下Payload虽然Ke以存数据，但建议只存非敏感数据。为什么？因为Base64是公开可解码的，谁douNengkan见。另外必须加 exp 字段，避免 Token 永久有效，否则一旦泄露，后果不堪设想。

3. 生成 Signature—— 防篡改核心

这是 JWT Zui关键的一步，目的是给前两部分盖一个“防伪印章”。Ru果没有这个签名，任何人douNeng随便修改Payload里的数据，比如把自己改成管理员。

计算规则用服务器的密钥 + Header里声明的 HS256 算法，对“待签名字符串”进行哈希计算。

那什么是“待签名字符串”呢？hen简单，就是把前两部分的Base64串用点号连起来：

HeaderBase64.PayloadBase64

也就是：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEyMywidXNlcm5hbWUiOiLlvKDkuIkicm9sZSI6InVzZXIiLCJleHAiOjE3Mzc2NDY4MDB9

然后我们用密钥 mp 对这个字符串进行运算：

签名原始值 = HMAC-SHA256
签名Base64 = Base64URL编码

Zui终得到签名串：

xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

三、 实战演练：服务器如何“铸造”Token？

假设用户“张三”刚刚输入了正确的密码，登录成功。这时候，服务器需要生成一个Token给他。咱们来kankan这中间到底发生了什么。

在生成 Token 前，先确定 3 个核心要素：

Header的算法；

Payload里的用户信息和过期时间；

服务器自己藏着的密钥，这个绝对不Neng泄露。

第一步：组装并编码 Header

把 {"alg":"HS256","typ":"JWT"} 变成 Base64，得到 HeaderBase64。

第二步：组装并编码 Payload

把 {"userId":123, ...} 变成 Base64，得到 PayloadBase64。

第三步：拼接 Header 和 Payload

将 Header 的 Base64 串和 Payload 的 Base64 串用 . 连接，得到待签名字符串。

第四步：计算签名

用密钥 mp + HS256 算法，对待签名字符串进行哈希，再Base64编码，得到 SignatureBase64。

第五步：组装完整 JWT Token

将「HeaderBase64」「PayloadBase64」「签名 Base64」三部分用 . 连接，就是Zui终的 JWT Token：

HeaderBase64.PayloadBase64.SignatureBase64

服务器将这个 Token 返回给客户端，客户端后续请求时需要携带这个 Token。

四、 守门员法则：服务器如何验证 Token？

当客户端带着 Token 访问接口时服务器可不Neng直接就信了。它得按以下步骤验证，核心是 “重新算签名对比”。

第一步：拆解 Token

服务器拿到 Token 后按 . 分割为三部分：HeaderBase64, PayloadBase64, 原签名Base64。

第二步：读取 Header 确认算法

解码 HeaderBase64 得到 JSON 原文，读取 alg:HS256。这一步是为了知道该用什么算法来验签。

第三步：检查 Payload 是否过期

解码 PayloadBase64 得到 JSON 原文，提取 exp 字段的过期时间戳。拿当前时间一比，Ru果 当前时间> exp，直接驳回：“TokenYi过期，请重新登录”。

第四步：重新计算签名

将分割得到的 HeaderBase64 和 PayloadBase64 拼接为待签名字符串：

HeaderBase64.PayloadBase64

然后服务器用自己保存的密钥 mp + HS256 算法，重新计算出一个 新的签名 Base64。

第五步：对比签名

将服务器重新计算的 新签名Base64 与客户端传过来的 原签名Base64 对比：

一致说明 Token 没被改过服务器认可，放行。

不一致说明 Payload 或者 Header 被篡改了或者这根本就是个伪造的 Token，直接拒绝访问。

五、 安全红线：为什么Base64不是加密？

hen多新手容易陷入一个误区，觉得把数据转成Base64就安全了。大错特错！

咱们再来复习一下那个防篡改的场景。假设有个黑客，他截获了你的 Token。他虽然不知道服务器的密钥 mp，但他Ke以直接把 Payload 的 Base64 拿去解码。

他kan到了：

{"userId": 123, "role": "user"}

他心里想：“哼，我要是管理员就好了。” 于是他动手改：

{"userId": 999, "role": "admin"}

然后他把这段新的 JSON 重新编码成 Base64，得到 新PayloadBase64。接着，他构造了一个假 Token：

HeaderBase64.新PayloadBase64.原签名Base64

当他把这个假 Token 发给服务器时会发生什么？

服务器在验证时会用 HeaderBase64.新PayloadBase64 去重新算签名。因为内容变了算出来的哈希值肯定也变了。服务器算出来的新签名，和黑客附带的那个“原签名”对不上。

结果显而易见：验证失败。

这就是为什么说 JWT 是防篡改的。只要密钥 mp 没泄露，黑客就算把 Payload 改成花，他也生成不出正确的签名。这就是密码学中“消息认证码”的魅力。

六、 写在Zui后

JWT 虽好，但也不是万Neng药。它的无状态特性带来了 性的便利，但也带来了难以主动撤销 Token 的弊端。

理解了底层的生成和验证逻辑，你才Neng在实际开发中Zuo出geng合理的架构设计。别再只是机械地调库了去感受一下代码背后那精妙的逻辑之美吧。希望这篇“保姆级”教程Neng帮你彻底搞定 JWT！

---