1、会话票据基础概念

聊会话票据之前，我先问大家一个问题：你每次登录一个网站，服务器是怎么记住「你是谁」的？

HTTP 协议本身是无状态的。说白了，服务器处理完你的请求就忘了你。那怎么让它记住呢？靠的就是会话票据。我做了这么多年系统，见过太多因为票据没管好导致线上事故的案例。今天咱们就把这个根基打牢。

什么是会话票据

会话票据，就是客户端和服务器之间用来维持登录状态的凭证。你登录成功后，服务器给你发一张「通行证」，后面每次请求带上它，服务器就知道是你来了。

我习惯把它比作酒店房卡。你办入住（登录），前台给你房卡（票据）。你拿着房卡开门、去健身房、吃早餐，服务员看到房卡就知道你是几号房的客人。不用每次都说一遍「我是张三，住888房」。

常见的票据形式有三种：

• Session ID —— 传统服务端会话，ID 存在 Cookie 里，用户数据放服务端内存或 Redis
• Token —— 自包含的令牌，比如 JWT，用户信息直接编码在令牌里
• 混合模式 —— Session + Token 结合，比如用 Token 做身份，用 Session 存权限缓存

会话票据的生命周期

一张票据从生到死，经历四个阶段。我在项目中踩过不少坑，每个阶段都有要注意的地方。

阶段	说明	常见问题
签发	用户认证成功后，服务端生成票据并返回客户端	签名密钥泄露、票据包含敏感信息
传输	客户端每次请求携带票据，通常放在 Header 或 Cookie	明文传输被截获、CSRF 攻击
验证	服务端收到请求后校验票据的有效性	验证逻辑遗漏、过期票据未及时清理
销毁	用户登出或票据过期后，使其失效	服务端未清除、客户端残留

嗯，这里要注意。生命周期不是越长越好。我见过一个项目把 Token 有效期设成 30 天，结果泄露后被人用了整整一个月才发现。短一点，配合刷新机制，才是正解。

票据的组成结构

咱们拿最流行的 JWT（JSON Web Token）来拆解。一个 JWT 长这样：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

看着像乱码？其实它由三部分组成，用点号分隔。我拆开给你看：

1. Header（头部）

声明令牌类型和签名算法。Base64 解码后：

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

2. Payload（载荷）

存放实际数据，也叫 Claims（声明）。分三类：

• 注册声明：预定义字段，如 iss（签发者）、sub（主题）、exp（过期时间）、iat（签发时间）
• 公共声明：自定义字段，但要在 IANA 注册或使用命名空间避免冲突
• 私有声明：业务自定义字段，比如 userId、role、tenantId

举个例子：

{
  "sub": "user_10086",
  "name": "张三",
  "role": "admin",
  "iat": 1700000000,
  "exp": 1700001800
}

3. Signature（签名）

对前两部分做签名，防止篡改。生成逻辑：

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

服务端用密钥验证签名。只要密钥不泄露，没人能伪造合法的票据。

Session ID vs Token：怎么选？

很多新手问我该用哪种。我直接给对比：

维度	Session ID	Token（JWT）
存储位置	服务端（内存/Redis）	客户端（自包含）
扩展性	需要共享会话存储	天然支持分布式
实时吊销	直接删服务端记录	需要黑名单或短有效期
性能	每次查询存储	本地验证，无 I/O
安全	依赖 Cookie 安全	依赖签名和密钥管理

我个人建议：单体应用或中小项目用 Session ID 省事；微服务、前后端分离、移动端场景，Token 更合适。没有银弹，看场景选。

知识体系总览

下面这张图把本章的核心脉络串起来了。我画图有个习惯，喜欢把关键流程和风险点标清楚，方便后面查漏补缺。

你看，会话票据看似简单，但每个环节都有门道。从选型到生命周期管理，再到结构设计，一步错就可能出大问题。后面几章我会带你深入每个细节，包括怎么安全存储、怎么高效刷新、怎么在分布式环境下保持一致性。

先把基础打牢，后面实战才不慌。