3. Payload 膨胀分析

JWT 令牌的 Payload 是存储声明（Claims）的核心区域，但也是性能问题的重灾区。随着业务迭代，开发人员往往习惯性地向 Payload 中添加字段，导致令牌体积持续增长。一个 512 字节的 JWT 与一个 4KB 的 JWT，在每次 HTTP 请求中带来的网络延迟和解析开销差异巨大。本节将系统分析 Payload 膨胀的三大根源。

3.1 常见冗余字段

许多团队在 JWT 中保留了大量仅在特定场景下使用、甚至完全不必要的字段。下表列出了最常见的冗余字段及其影响：

3.2 用户信息过多导致的体积增长

最常见的膨胀场景是将完整的用户对象序列化后塞入 Payload。一个典型的用户对象可能包含数十个字段，导致令牌体积从几百字节膨胀到数 KB。

以下是一个反面示例：

// ❌ 反面示例：将完整用户对象放入 Payload
{
  "sub": "user_12345",
  "name": "张三",
  "email": "zhangsan@example.com",
  "phone": "13800138000",
  "avatar_url": "https://cdn.example.com/avatars/12345.jpg",
  "department": "技术部",
  "role": "admin",
  "permissions": ["read:user", "write:user", "delete:user", "read:report", ...],  // 50+ 权限
  "last_login": "2025-03-15T10:30:00Z",
  "preferences": { "theme": "dark", "language": "zh-CN", "notifications": true },
  "address": { "city": "北京", "district": "海淀" },
  "metadata": { "source": "sso", "mfa_enabled": true }
}
// 体积估算：约 1.2KB（Base64 编码后约 1.6KB）

优化后的 Payload 应只保留最小必要信息：

// ✅ 优化后：仅保留核心标识和关键属性
{
  "sub": "user_12345",
  "name": "张三",
  "role": "admin",
  "perm_hash": "a3f2b8c1"  // 权限列表的哈希值，用于缓存校验
}
// 体积估算：约 120 字节（Base64 编码后约 160 字节）

3.3 自定义声明滥用

JWT 规范允许自定义声明（Private Claims），但这扇“方便之门”常常导致 Payload 变成“垃圾场”。开发人员倾向于将各种业务数据临时塞入 JWT，而不考虑长期维护成本。

自定义声明滥用的典型模式：

• 临时业务数据： 将一次性的流程状态、临时标识符放入 JWT，导致令牌无法复用。
• 嵌套对象： 在声明中放入 JSON 对象或数组，如 "address": { "city": "北京", "district": "海淀" }，大幅增加体积。
• 冗余权限列表： 将完整的权限树或角色层级直接序列化到 Payload 中。
• 多用途声明： 同一个 JWT 同时用于认证、授权、会话管理、特征标记等多个目的。

下图展示了 Payload 膨胀的三种模式及其对令牌体积的影响：

3.4 膨胀量化与优化目标

为了帮助团队建立明确的优化标准，下表给出了不同规模系统的 Payload 体积优化目标：