1. JWT 基础回顾：结构、原理与对比
JWT（JSON Web Token）是目前分布式架构中最主流的无状态认证令牌格式。理解其结构、工作原理以及与 Session 的差异，是后续优化令牌膨胀与缓存策略的前提。
1.1 JWT 结构：三段式令牌
一个 JWT 由 Header、Payload、Signature 三部分组成，以点号 . 分隔，整体格式为：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c| 部分 | 内容 | 示例 |
|---|---|---|
| Header | 令牌类型（typ）与签名算法（alg） | {"alg":"HS256","typ":"JWT"} |
| Payload | 声明（Claims）：用户身份、权限、过期时间等 | {"sub":"123","name":"John","iat":1516239022} |
| Signature | 对 Header + Payload 的签名，防止篡改 | HMAC-SHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret) |
关键认知：Payload 仅做 Base64Url 编码，不是加密。敏感信息（如密码、身份证号）严禁放入 Payload。Signature 只保证数据完整性，不保证机密性。
1.2 JWT 工作原理
JWT 的工作流程分为 签发、传输、验证 三个阶段：
- 签发（Issuance）：用户登录成功后，服务端生成 JWT，将用户标识、角色、权限等声明写入 Payload，使用密钥签名后返回给客户端。
- 传输（Transmission）：客户端将 JWT 存储在 localStorage / Cookie / 内存中，每次请求时通过 HTTP Header
Authorization: Bearer <token>发送给服务端。 - 验证（Verification）：服务端收到请求后，解析 JWT，验证签名是否有效、是否过期、是否被撤销（黑名单场景）。验证通过后，从 Payload 中提取用户信息进行授权。
无状态核心：服务端不存储会话信息，所有用户状态都包含在 JWT 自身。这消除了 Session 存储的数据库/缓存依赖，但也带来了令牌膨胀和无法主动失效的问题。
1.3 JWT 与传统 Session 对比
| 对比维度 | JWT（无状态） | Session（有状态） |
|---|---|---|
| 存储位置 | 令牌自身携带所有信息，服务端不存储 | 服务端存储 Session 数据（内存 / Redis / DB） |
| 扩展性 | 天然支持水平扩展，无需共享存储 | 需要共享 Session 存储（如 Redis）或粘性会话 |
| 主动失效 | 困难，需维护黑名单或缩短过期时间 | 容易，直接删除服务端 Session 即可 |
| 令牌体积 | 随权限声明增加而膨胀（令牌膨胀问题） | 仅传递 Session ID，体积固定 |
| 安全性 | Payload 仅编码不加密，敏感信息需额外加密 | 数据存储在服务端，客户端仅持有 Session ID |
| 跨域支持 | 天然支持跨域（CORS + Bearer Token） | 需配置跨域 Cookie 或额外方案 |
性能陷阱：JWT 的无状态特性在微服务架构中极具吸引力，但权限声明过多会导致令牌体积膨胀到 4KB ~ 10KB 甚至更大。每次请求都携带大令牌，会显著增加网络传输延迟和签名验证开销。这正是本课程后续要解决的核心问题。
1.4 典型应用场景
- 单点登录（SSO）：JWT 作为跨系统认证令牌，一次登录，多系统可用。
- 移动端 / SPA 应用：无 Cookie 依赖，适合 RESTful API 认证。
- 微服务网关：网关验证 JWT 后，将用户信息透传给下游服务。
- 短期授权：如密码重置链接、API 临时访问令牌，利用 JWT 自包含过期时间。