[面试题] Cookie、Session、Token 的区别是什么？

📖 版块 A：知识讲解版 (温故知新)

1. Cookie：存储在客户端浏览器的一段文本。它有大小限制（通常 4KB），会随着 HTTP 请求自动携带并发送给服务器。它是 Session 和 Token 的常见载体。

2. Session：存储在服务器端的会话数据。服务器通过标识符（SessionID）来识别用户。通常依赖 Cookie（JSESSIONID）来传递标识符。它是“有状态”的认证方式。

3. Token：令牌，是服务器签发的一段加密字符串。最常见的是 JWT（JSON Web Token）。它由客户端保存，请求时放在 Header 中。它是“无状态”的认证方式，服务器不需要存储会话信息。

4. 核心区别点：

   • 存储位置：Cookie/Token 在客户端，Session 在服务端。
   • 安全性：Session 相对安全，但易受 CSRF 攻击；Token 只要不泄露，防篡改性强。
   • 可扩展性：Session 在分布式环境下需要做同步或 Redis 共享；Token 天然支持分布式。

🎤 版块 B：面试实战版 (高手逐字稿)

Q：Cookie、Session、Token 的区别是什么？

💬 高手逐字稿：

关于 Cookie、Session 和 Token，我理解它们本质上都是为了解决 HTTP 协议“无状态”的问题，但在实现细节和适用场景上有很大不同。

首先是 Session 和 Cookie 的组合。这是最传统的有状态管理方式。服务器在验证完用户信息后，在内存里开辟一块空间存 Session，并把 SessionID 通过 Cookie 返给浏览器。这种方式的优点是服务端可以完全控制会话，比如强制踢人下线。但痛点也非常明显：一是水平扩展困难，多台机器部署时必须做 Session 同步或者搞 Redis 集中存储，否则请求打到另一台机器就“掉线”了；二是容易受到 CSRF 攻击。

然后是 Token（令牌）。这是一种无状态的认证方案。服务器不存储任何会话信息，而是将用户信息、权限、有效期等打成一个包，用秘钥签名后发给客户端（比如 JWT）。客户端每次带上这个 Token，服务器只负责解密验证签名。这种方案最大的优势就是天然适配分布式和微服务架构，服务器压力小。

这里其实涉及到一个经常被忽略的细节，就是“注销”操作的权衡。

在 Session 架构下，注销非常简单，把服务器端的 Session 删掉就行。但在纯 Token 架构下，因为服务器不存状态，即使客户端把 Token 删了，只要 Token 没过期，它在全网依然是有效的。

为了解决这个问题，我们在实际生产中通常会采用“混合方案”：虽然使用 Token，但会在 Redis 里维护一个黑名单，或者给 Token 设置一个较短的有效期，配合 Refresh Token 机制来兼顾安全性和扩展性。

总的来说，如果是传统的单体管理后台，用 Session 开发效率最高；如果是高并发的互联网 App 或者微服务架构，Token 几乎是必然的选择。