1. 存储位置与机制
| 类型 | 存储位置 | 依赖关系 | 特点 |
|---|---|---|---|
| Cookie | 客户端（浏览器） | 由服务器通过Set-Cookie响应头设置，自动随请求发送 |
大小受限（约4KB），可设置过期时间；存在安全风险（如CSRF攻击）。 |
| Session | 服务端（服务器内存/数据库） | 依赖Cookie中的Session ID与服务端数据关联 |
用户状态存储在服务端，安全性更高；但服务器需维护Session数据，高并发时可能影响性能。 |
| Token | 客户端（如LocalStorage） | 由服务端生成并返回，客户端手动在请求头（如Authorization）添加 |
无状态（服务端不存储），可自定义存储位置（如Header、URL参数）；无跨域限制，适合分布式系统（如JWT）。 |
2. 安全性对比
| 类型 | 安全风险 | 防护措施 |
|---|---|---|
| Cookie | - CSRF攻击（跨站请求伪造） - XSS窃取Cookie内容（若未设置HttpOnly） |
- 设置SameSite属性限制跨站发送 - 标记HttpOnly防止JS访问 - 使用Secure仅HTTPS传输 |
| Session | - Session劫持（若Session ID泄露） - 服务端存储压力大（可能被攻击者耗尽资源） |
- 定期清理过期Session - 结合IP/User-Agent验证 - 加密Session ID |
| Token | - XSS窃取Token（若存储不当） - Token泄露后无法快速失效（需依赖黑名单或短有效期） | - Token加密签名（如JWT的签名机制） - 存储于非持久化位置（如内存） - 设置合理过期时间 |
3. 使用场景
| 类型 | 适用场景 | 示例 |
|---|---|---|
| Cookie | - 简单的用户状态保持（如登录态） - 需要服务端自动管理的小型数据（如语言偏好） | 电商网站的购物车ID存储 |
| Session | - 对安全性要求高的场景（如支付系统） - 需要服务端完全控制用户状态的系统 | 银行系统登录后的会话管理 |
| Token | - 前后端分离架构（如SPA应用） - 跨域/分布式系统（如微服务API鉴权） - 无状态身份验证（如移动端APP） | JWT用于用户登录后访问API资源 |
4. 核心区别总结
| 维度 | Cookie | Session | Token |
|---|---|---|---|
| 存储位置 | 客户端 | 服务端 | 客户端 |
| 通信方式 | 自动随请求发送 | 依赖Cookie中的Session ID |
手动添加到请求头/参数 |
| 跨域支持 | 受同源策略限制（需CORS） | 同Cookie | 无限制（可手动传递） |
| 服务端压力 | 低（数据在客户端） | 高（需存储所有Session数据） | 低（无状态） |
| 扩展性 | 受限（大小和安全性） | 依赖服务端扩展 | 高（适合分布式系统） |
| 典型应用 | 会话管理、跟踪用户行为 | 敏感操作的身份验证 | API鉴权、移动端身份验证 |
5. 面试回答技巧
- 简明回答 ：
"Cookie由服务端设置，存储在浏览器，自动随请求发送；Session数据在服务端，通过Session ID关联；Token（如JWT）由服务端生成，客户端存储并手动发送，无状态且适合分布式系统。" - 结合场景 ：
"在单页面应用（SPA）中，常用Token实现无状态鉴权，避免Cookie的跨域限制；而传统Web应用可能用Session管理敏感会话。" - 安全补充 ：
"Cookie需防范CSRF（如设置SameSite），Token需防范XSS（避免LocalStorage存储敏感数据）。"