以下是 Cookie、Session、JWT、Token 的横向对比分析，从工作原理、安全性、扩展性、适用场景等维度总结差异：

一、核心概念对比

二、关键差异分析

1.工作原理

• Cookie
• 客户端存储：由服务器通过Set-Cookie头下发，浏览器自动保存并在后续请求中回传。
• 用途：常用于会话管理（如Session ID）、个性化设置（如语言偏好）。
• Session
• 服务端存储：用户登录后，服务器生成唯一Session ID并存储用户数据（内存/数据库），通过Cookie或URL将Session ID返回客户端。
• 验证流程：客户端每次请求携带Session ID，服务端查询Session存储以验证用户身份。
• JWT (JSON Web Token)
• 自包含令牌：由Header（算法）、Payload（数据）、Signature（签名）三部分组成，签名确保数据不可篡改。
• 无状态验证：服务端无需存储Token，仅需验证签名和有效期即可解析用户信息。
• Token (如OAuth Token)
• 授权令牌：客户端通过登录获取Token，后续请求携带Token访问资源。
• 服务端验证：需查询Token存储（如数据库）验证有效性，可能结合OAuth协议实现授权流程。

2.安全性

• Cookie
• 风险：易受CSRF攻击（需配合SameSite属性）、XSS窃取（需HttpOnly标记）。
• 防护：必须启用HTTPS，设置Secure和HttpOnly属性。
• Session
• 风险：Session劫持（若Session ID泄露）、服务端存储压力（集中式Session易成单点故障）。
• 防护：定期清理Session、绑定IP/User-Agent。
• JWT
• 风险：Token泄露后无法主动失效（需短有效期或结合黑名单机制）、密钥泄露风险。
• 防护：使用强签名算法（如RSA）、避免敏感数据存入Payload。
• Token
• 风险：Token泄露导致权限滥用（需HTTPS加密传输）。
• 防护：设置短有效期、支持Token吊销机制。

3.扩展性与性能

• Cookie
• 扩展性：受浏览器大小限制（单个域名约4KB），跨域需CORS配置。
• 性能：自动携带可能增加请求头大小。
• Session
• 扩展性：服务端存储依赖集中式数据库，分布式场景需Session共享（如Redis集群）。
• 性能：高并发时频繁查询Session存储可能成为瓶颈。
• JWT
• 扩展性：无状态设计天然支持分布式系统，Payload可自定义扩展数据。
• 性能：无需查库，签名验证计算开销较低。
• Token
• 扩展性：依赖Token存储的扩展性（如分布式缓存）。
• 性能：每次请求需验证Token有效性，可能增加数据库查询开销。

4.适用场景

• Cookie
• 传统Web应用（配合Session使用）、存储非敏感客户端状态（如主题设置）。
• Session
• 需要服务端维护用户状态的场景（如购物车、登录态管理）。
• JWT
• 无状态API（RESTful）、跨域认证（如单点登录SSO）、移动端/前后端分离架构。
• Token
• OAuth授权场景（第三方登录）、微服务间鉴权、移动端API访问。

三、总结与选择建议

实际开发中，常结合使用：

• Cookie + Session：传统Web应用。
• JWT + HTTPS：现代前后端分离架构。
• OAuth Token + JWT：第三方授权与无状态API。