cookie session和token的区别

1. 核心概念

机制	本质	存储位置	生命周期
Cookie	客户端存储的小型文本数据	浏览器	可设置过期时间（如7天）
Session	服务端存储的用户会话状态	服务器内存/数据库	用户关闭浏览器或超时失效
Token	无状态的加密身份凭证（如JWT）	客户端（LocalStorage等）	取决于过期时间或主动撤销

2. 工作原理对比

(1) Cookie

• 流程：

1. 1. 服务端通过Set-Cookie响应头下发Cookie →
   2. 浏览器自动在后续请求的Cookie头中携带 →
   3. 服务端验证Cookie内容。

• 特点：

• • 每次请求自动附加，可能引发 CSRF攻击。
  • 大小限制（约4KB），不可跨域（受同源策略限制）。

(2) Session

• 流程：

1. 1. 服务端创建Session ID →
   2. 通过Cookie或URL参数传递给客户端 →
   3. 客户端后续请求携带Session ID →
   4. 服务端查询Session存储（如Redis）验证状态。

• 特点：

• • 服务端存储压力大（高并发时需分布式Session）。
  • 默认依赖Cookie传递Session ID。

(3) Token（如JWT）

• 流程：

1. 1. 用户登录后服务端生成Token（含用户信息+签名） →
   2. 客户端保存Token（LocalStorage/内存） →
   3. 每次请求在Authorization头中手动添加Token →
   4. 服务端验证签名并解码Token。

• 特点：

• • 无状态：服务端不存储Token，适合分布式系统。
  • 可跨域，但需防 XSS攻击（Token被恶意脚本窃取）。

3. 安全性与适用场景

对比项	Cookie	Session	Token
安全性	低（易CSRF）	中（依赖Session ID安全）	高（需防XSS）
扩展性	差（同源限制）	中（需共享Session存储）	优（天然支持分布式）
适用场景	简单状态保持（如语言偏好）	传统Web应用（如电商购物车）	前后端分离/API认证（如移动端）

4. 通俗比喻

• Cookie：超市会员卡（自动出示，但可能被伪造）。
• Session：银行柜台号牌（服务端记录你的业务状态）。
• Token：加密门票（自带身份信息，无需查后台）。

5. 如何选择？

• 需要兼容老系统/简单状态 → Cookie+Session
• 需要跨域/无状态架构 → Token（JWT）
• 敏感操作（如支付） → Session + CSRF Token

总结：三者本质是不同维度的身份管理方案，现代系统常组合使用（如JWT+HttpOnly Cookie双重防护）。