Cookie、Session、Token：Web 认证三剑客的区别与选择

在 Web 开发中，用户认证是必不可少的功能。你可能经常听到 Cookie、Session、Token 这三个词，它们看起来都在做“记住用户”这件事，但到底有什么区别？什么时候该用哪个？今天我们就来聊聊这三位“认证三剑客”。

Cookie：浏览器的小笔记本

Cookie 是什么？

Cookie 是浏览器存储在客户端的一小段文本数据，就像浏览器随身携带的一个小笔记本。每次访问网站时，浏览器都会把这个小笔记本里的相关内容带上，网站也能往里面写新的内容。

核心特点：

• 存储位置：客户端（浏览器）
• 存储容量：通常限制在 4KB 左右
• 生命周期：可设置过期时间，关闭浏览器后仍可保留
• 自动携带：每次 HTTP 请求自动附带相关 Cookie

工作原理：

当用户登录成功后，服务器会通过响应头 Set-Cookie 把用户信息写入 Cookie。之后的每次请求，浏览器都会自动在请求头 Cookie 中带上这些信息，服务器就能识别用户身份。

1
# 服务器响应
2
Set-Cookie: userId=123; Expires=Wed, 09 Jun 2026 10:18:14 GMT
3

4
# 后续请求自动携带
5
Cookie: userId=123

优缺点：

• ✅ 实现简单，浏览器自动管理
• ✅ 可设置过期时间，实现持久化登录
• ❌ 安全性较低，容易被劫持和篡改
• ❌ 存储容量有限
• ❌ 每次请求都携带，可能影响性能

Session：服务器的小账本

Session 是什么？

Session 是服务器端存储的用户状态数据，就像服务器自己保管的一本小账本。账本上记录了每个用户的会话信息，用 Session ID 作为页码来快速查找。

核心特点：

• 存储位置：服务器端（内存、数据库、Redis 等）
• 存储容量：服务器资源允许范围内，相对较大
• 生命周期：默认会话结束即销毁，可配置超时时间
• 依赖 Cookie：通常通过 Cookie 传递 Session ID

工作原理：

用户登录后，服务器创建一个 Session 对象，生成唯一的 Session ID，通过 Cookie 发送给客户端。后续请求时，客户端只发送 Session ID，服务器根据 ID 找到对应的 Session 数据。

1
客户端                    服务器
2
  |                        |
3
  |--- 登录请求 ----------->|
4
  |                        | 创建 Session
5
  |<-- Set-Cookie: SID ----|
6
  |                        |
7
  |--- 带着SID的请求 ------>|
8
  |                        | 根据 SID 查找 Session
9
  |<-- 响应内容 -----------|

优缺点：

• ✅ 安全性较高，敏感数据存储在服务器
• ✅ 存储容量大，可存储复杂对象
• ✅ 只传输 Session ID，减少网络开销
• ❌ 占用服务器资源
• ❌ 分布式系统需要 Session 共享方案
• ❌ 依赖 Cookie，浏览器禁用 Cookie 则失效

Token：无状态的通行证

Token 是什么？

Token 是一种无状态的用户凭证，就像一张自带防伪标识的通行证。最常见的是 JWT（JSON Web Token），它把用户信息加密编码成一个字符串，客户端自己保管，服务器只需验证真伪。

核心特点：

• 存储位置：客户端保管（Cookie、LocalStorage 等）
• 存储形式：加密签名的字符串（如 JWT）
• 生命周期：通过过期时间字段控制
• 无状态：服务器不存储 Token，只验证签名

工作原理：

用户登录成功后，服务器用密钥生成一个带签名的 Token，包含用户信息和过期时间。客户端保存 Token，后续请求时在 Authorization 头携带 Token，服务器验证签名和解码数据即可识别用户。

1
# JWT 结构示例（Base64 编码）
2
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.  # Header（算法信息）
3
eyJ1c2VySWQiOiIxMjMiLCJyb2xlIjoiYWRtaW4ifQ.  # Payload（用户数据）
4
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c  # Signature（签名验证）

优缺点：

• ✅ 完全无状态，服务器无需存储，易于扩展
• ✅ 跨域友好，适合前后端分离架构
• ✅ 多端适配，Web、移动端、小程序通用
• ✅ 可携带用户信息，减少数据库查询
• ❌ Token 较大，每次请求都要携带
• ❌ 无法主动失效，只能等待过期
• ❌ Token 泄露风险高，需配合短期有效期

三剑客对比速查表

实战场景：如何选择？

传统单体 Web 应用 → Session

适合传统的服务器端渲染应用，用户量不大，单台服务器足够。Session 实现简单，安全性好，是经典的选择。

前后端分离架构 → Token

适合 Vue、React 等前端框架配合 API 后端。Token 无状态、跨域友好，天然契合前后端分离的开发模式。

移动端、小程序 → Token

iOS、Android、小程序等移动端应用无法使用 Cookie，Token 是唯一可行的选择。

分布式微服务 → Token

多服务器集群、微服务架构下，Session 共享复杂，Token 的无状态特性天然支持分布式部署。

简单场景、临时数据 → Cookie

如果只是存储一些非敏感的用户偏好设置（如语言、主题），Cookie 就足够了，无需 Session 或 Token 的复杂性。

最佳实践建议

1. 安全优先：任何方案都要配合 HTTPS，防止传输过程被窃听
2. 敏感数据：密码、支付信息等永远不要存 Cookie，Session 或 Token 也只存 ID
3. 短期有效期：Token 设置较短的过期时间（如 2 小时），配合 Refresh Token
4. 安全存储：Token 存储建议优先用 HttpOnly Cookie，避免 XSS 攻击
5. 防御 CSRF：Cookie 方案配合 CSRF Token，Session 方案验证 Referer 头

结语

Cookie、Session、Token 并非互相替代，而是各有适用场景的技术方案。Cookie 是数据容器，Session 是服务器状态管理，Token 是无状态凭证。理解它们的本质区别，才能在项目中选择最合适的认证方案。

认证安全是系统安全的基石，没有完美的方案，只有最适合的选择。根据项目架构、用户规模、安全需求，选择最适合的“剑客”，守护好用户的每一次访问。