从“记住我”到 Web 认证：Cookie、JWT 和 Session 的故事

1. 初识 HTTP：一场没有记忆的对话

小明最近开发了一个旅游网站，每天有很多用户访问。但他发现了一个问题：
用户登录后，刷新一下页面就得重新登录？！😨

他百思不得其解，为什么网站不能记住用户的登录状态？

这时，他的师兄告诉他：

“这是因为 HTTP 是无状态的，每次请求都是全新的，服务器根本不知道你是谁。”

小明恍然大悟，但随之而来的新问题是——如何让服务器记住用户的身份呢？

---

2. Cookie：网站的“记忆” 🍪

师兄介绍了第一种解决方案：Cookie。

💡 Cookie 是存储在浏览器中的一小段数据，它可以在每次请求时自动携带到服务器，让服务器识别用户身份。

小明的实现方式：

1. 用户登录成功后，服务器生成一个

   Set-Cookie
   

   响应头，把用户身份信息存到 Cookie 里：

   Set-Cookie: user=12345; Expires=Wed, 21 Oct 2025 07:28:00 GMT
   

2. 之后每次请求，浏览器都会自动带上 Cookie：

   Cookie: user=12345
   

3. 服务器检查 user=12345，发现是小明，返回登录后的页面。

🌟 Cookie 的优点：

• 服务器无须存储会话信息，完全由客户端管理。
• 支持不同域名的访问控制（如 www.example.com 和 api.example.com 共享 Cookie）。

⚠️ 但 Cookie 有几个明显的缺陷：

• 安全性低：存储在客户端，容易被篡改或盗取（可以使用 HttpOnly 限制 JS 访问）。
• 存储空间有限：单个 Cookie 不能超过 4KB，大量数据存不下。
• 每次请求都会携带，影响带宽和性能。

小明想了想，发现 Cookie 存在安全性问题，不太适合存储敏感信息，比如登录凭证。于是，他又去了解新的方案。

---

3. Session：服务端的“记忆” 🎯

师兄又介绍了另一种方案：Session。

💡 Session 通过在服务器端存储用户信息，并用一个唯一的 Session ID 让用户“自报家门”。

小明的实现方式：

1. 用户登录成功后，服务器生成一个

   Session ID

   （如

   abc123
   

   ），并存储用户信息：

   session.setAttribute("user", "小明");
   

2. 服务器通过

   Set-Cookie
   

   把

   Session ID
   

   发送给浏览器：

   Set-Cookie: session_id=abc123; HttpOnly
   

3. 之后用户的请求会带上 session_id=abc123，服务器查找对应的用户信息，返回登录页面。

🌟 Session 的优点：

• 更安全：用户信息存储在服务器，不会暴露在客户端。
• 可以存储更大的数据，不像 Cookie 受 4KB 限制。

⚠️ 但也有缺点：

• 占用服务器资源：每个用户都需要服务器存储 Session，会增加内存和数据库的压力。
• 无法跨域：不同域名下的 Session 不能共享。

小明发现，Session 解决了 Cookie 的安全问题，但如果用户量大，Session 可能会占用太多服务器资源。
于是，他又去探索更轻量级的身份认证方案。

---

4. JWT：让用户自己带着“身份证” 🔑

这时，小明听说了一种无状态的身份认证方式——JWT（JSON Web Token）。

💡 JWT 是一种基于 Token（令牌）的身份认证机制，用户登录后，服务器返回一个加密的 Token，之后用户只需带上这个 Token 进行身份认证，服务器不需要存储 Session。

小明的实现方式：

1. 用户登录成功后，服务器生成一个

   JWT Token

   ：

   {"userId": 12345,"exp": "2025-12-31T23:59:59Z"
   }
   

   服务器用

   密钥

   对它进行加密并返回给用户：

   Authorization: Bearer eyJhbGciOiJIUzI1NiIsIn...
   

2. 之后用户每次请求时，把 JWT 放入

   Authorization
   

   头里：

   Authorization: Bearer eyJhbGciOiJIUzI1NiIsIn...
   

3. 服务器用密钥解密 JWT，验证其有效性，然后解析出 userId=12345，继续处理请求。

🌟 JWT 的优点：

• 无状态，适用于分布式系统：服务器不需要存储 Session，适合微服务架构。
• 支持跨域访问：不像 Cookie 受 Same-Origin Policy 限制，JWT 可以放在 Authorization 头里，跨域传输。
• 可携带额外信息：可以嵌入用户角色、权限等信息，减少数据库查询。

⚠️ 但 JWT 也有缺点：

• 一旦被泄露，无法撤销（Session 可以在服务器端删除）。
• Token 过大，每次请求都带上 JWT，会占用带宽。

小明发现，JWT 适合无状态的微服务架构，但如果只是在单体应用里，Session 可能更适合。

---

5. Cookie vs Session vs JWT 总结 📊

方案	存储位置	适用场景	安全性	服务器压力	是否支持跨域
Cookie	客户端	轻量级存储，如用户偏好	❌ 易被篡改	✅ 低	⚠️ 受 Same-Origin 限制
Session	服务器	传统 Web 应用，单体架构	✅ 安全	❌ 高（需存 Session）	❌ 不能跨域
JWT	客户端	分布式系统、微服务	⚠️ 需保护 Token	✅ 低（无状态）	✅ 支持

---

6. 最终选择：用对工具才是关键！ 🔥

小明终于明白了：

• 简单存储 👉 用 Cookie
• 单体应用的用户认证 👉 用 Session
• 微服务、移动端 API 认证 👉 用 JWT

他兴奋地优化了自己的旅游网站，并根据需求选择了合适的身份认证方式。😃

---

📌 你学到了什么？

✅ HTTP 是无状态的，需要额外机制记住用户身份。
✅ Cookie 存储在客户端，适用于轻量级数据存储，但不适合存敏感信息。
✅ Session 存储在服务器，更安全，但占用资源，不支持跨域。
✅ JWT 是无状态的 Token 认证方式，适用于分布式系统，但需要妥善管理 Token。

博客主页: 总是学不会.