Cookie 和 Session 的主要区别有哪些？

1. 引言：医院就诊卡与病历系统的启示

想象一下你去医院看病。第一次挂号时，医院给你一张就诊卡（Cookie），上面只印着你的卡号。而医院庞大的**病历系统（Session）**里，对应这个卡号存着你的完整档案——姓名、病史、检查结果、处方。之后每次去，你只需出示就诊卡，医生就能从系统里调出你的全部信息。如果医院有多家分院（分布式系统），只要所有分院都能访问同一套病历系统，你的就诊卡照样通用。

这张“就诊卡”与“病历系统”的配合，正是 Cookie 与 Session 在 Web 世界中的真实写照。它们共同解决了 HTTP 协议天生的“健忘症”——让服务器能在多次请求中认出你是谁。

本文将从一个后端架构师的视角，带你彻底搞懂 Cookie 与 Session 的本质区别、工作原理，以及在分布式架构下的演进方案。

2. 前置知识：HTTP 的“健忘症”

在深入具体技术之前，我们先理解一个核心问题：为什么需要 Cookie 和 Session？

HTTP 协议在设计之初是为了传输静态文档，它有一个重要特点——无状态（Stateless）。这意味着每次请求都是独立的，服务器不会记住这次请求的任何信息，更不会知道两次请求是否来自同一个用户。

想象一下，你在购物网站加了一本书到购物车，然后刷新页面——服务器已经忘了你是谁，更不会记得你的购物车内容。这显然不现实。于是，Web 开发者们需要一种机制，让服务器能“记住”用户。Cookie 和 Session 正是为了解决这个问题而诞生的。

3. Cookie：客户端的“就诊卡”

3.1 是什么？

Cookie 是一种存储在客户端（通常是浏览器）的、容量有限的文本文件。它以键值对的形式存储数据，并由服务器通过 HTTP 响应头发送给浏览器。浏览器会按照一定的规则保存这些 Cookie，并在后续请求中自动携带。

3.2 为什么需要它？

Cookie 的核心价值在于：它让服务器有能力在客户端“存放”一个身份标识，并确保这个标识能在后续请求中被自动送回。它是实现“有状态”交互的基础工具。

3.3 怎么工作？

Cookie 的工作流程非常清晰：

1. 服务器生成：用户首次访问时，服务器在 HTTP 响应头中添加 Set-Cookie 字段。
2. 浏览器存储：浏览器解析响应头，将 Cookie 保存到本地。
3. 自动携带：此后，浏览器每次向同一域名发起请求时，都会在请求头中自动加上 Cookie 字段，携带之前存储的所有 Cookie。
4. 服务器读取：服务器从请求头中读取 Cookie，识别用户身份。

HTTP 报文示例：

// 服务器响应
HTTP/1.1 200 OK
Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure

// 后续请求
GET /user/profile HTTP/1.1
Cookie: sessionId=abc123

3.4 特点与限制

4. Session：服务端的“病历系统”

4.1 是什么？

Session 是服务端为每个用户会话独立创建的数据存储空间。它通常以键值对的形式存储在服务器的内存、数据库或专用缓存中。每个 Session 对应一个唯一的 Session ID，这个 ID 通常通过 Cookie 传递给客户端。

4.2 为什么需要它？

Cookie 存储在客户端，存在两个天然缺陷：一是容量有限，二是数据暴露在外。对于敏感信息（如登录状态、用户身份），放在客户端既不安全也不够用。Session 将这些数据保存在服务端，客户端只保留一个“钥匙”（Session ID），既安全又能承载复杂数据结构。

4.3 怎么工作？

Session 的工作流程同样清晰：

1. 创建 Session：用户首次访问时，服务器创建一个 Session 对象，生成唯一的 Session ID。
2. 传递 Session ID：服务器通过 Set-Cookie 将 Session ID 写入客户端 Cookie（默认 Cookie 名称为 JSESSIONID）。
3. 携带 Session ID：后续请求中，浏览器自动携带该 Cookie。
4. 定位数据：服务器根据 Session ID 找到对应的 Session 对象，读取或更新其中的数据。

// Java Servlet 示例
HttpSession session = request.getSession(); // 获取或创建 Session
session.setAttribute("userId", 1001);       // 存入数据
String userId = (String) session.getAttribute("userId"); // 读取数据

4.4 Session ID 的传递方式

虽然最常见的是通过 Cookie 传递，但 Session ID 也可以通过其他方式传递：

4.5 特点与限制

5. 核心对比：一张表看懂差异

6. 知识扩展：分布式架构下的 Session 共享

6.1 问题：Session 丢失

在单机部署中，Session 存储在应用服务器的内存中，没有问题。但在分布式架构中，用户的请求可能被负载均衡到不同的服务器。如果用户在 A 服务器登录，Session 存在 A 的内存中，下次请求被转发到 B 服务器时，B 没有该用户的 Session，用户就会“被踢下线”。

6.2 解决方案

方案一：请求精确定位（Nginx ip_hash）

通过负载均衡器（如 Nginx）的 ip_hash 策略，将来自同一 IP 的请求始终分配到同一台服务器。优点：实现简单，无需改动代码。缺点：服务器宕机会导致该服务器上的所有用户 Session 丢失；不够灵活，无法动态扩缩容。

方案二：Session 复制

让所有服务器之间互相复制 Session，保持一致性。Tomcat 等 Web 容器支持这种方案。优点：对应用透明。缺点：随着服务器增加，复制成本呈指数级上升，不适合大规模集群。

方案三：集中式 Session 存储（业界主流）

将 Session 从应用服务器中抽离，存放在一个共享的存储中间件中，所有服务器统一从这里读写。最常用的中间件是 Redis。

// Spring Boot + Spring Session + Redis 配置示例
spring.session.store-type=redis
spring.redis.host=localhost
spring.redis.port=6379

优点：

• 服务器无状态，可任意扩缩容
• Redis 读写性能极高，支持持久化
• 对应用代码基本无侵入

缺点：

• 需要额外维护 Redis 集群
• 每次请求都要访问 Redis，增加少量网络延迟

方案四：无状态 Token（JWT）

完全不依赖服务端存储，将用户信息加密后放入 Token 中，由客户端保存。服务器只负责验证 Token 的签名。

优点：彻底无状态，天然适合分布式。缺点：Token 一旦签发无法主动失效（需等待过期或维护黑名单），Token 体积可能较大。

6.3 选型建议

7. 常见误区与安全实践

误区一：Session 比 Cookie 安全，所以完全不用 Cookie

正解：Session 依赖 Cookie 传递 Session ID，这个存储 Session ID 的 Cookie 必须设置 HttpOnly（防 XSS）、Secure（仅 HTTPS）、SameSite（防 CSRF）等安全属性，才能保证整体安全。

误区二：禁用 Cookie 后 Session 就无法使用

正解：可通过 URL 重写传递 Session ID，但存在安全风险且体验差，生产中不推荐。

误区三：Session 数据存得越多越好

正解：Session 数据会占用服务器内存，高并发时应只存储必要的用户标识，其他数据通过数据库或缓存按需加载。

安全实践清单

• ✅ 敏感数据 严禁 存入 Cookie，必须存 Session
• ✅ 存储 Session ID 的 Cookie 必须设置 HttpOnly 和 Secure
• ✅ 设置 SameSite=Lax 或 Strict，缓解 CSRF 攻击
• ✅ 分布式环境使用 Redis 集中存储 Session，避免单点内存溢出
• ✅ Session 超时时间不宜过长，一般 20-30 分钟即可

8. 总结

• Cookie 是客户端的轻量级存储，适合存放不敏感的身份标识和用户偏好。
• Session 是服务端的数据仓库，适合存放敏感、临时的用户状态。
• 二者配合：Session ID 通过 Cookie 传递，是 Web 应用的经典组合。
• 分布式演进：面对多节点部署，Spring Session + Redis 提供了优雅的 Session 共享方案；JWT 等无状态 Token 则为微服务架构提供了更轻量的选择。

理解 Cookie 与 Session 的底层原理，不仅是面试的必考点，更是构建安全、可扩展 Web 应用的基石。希望本文能帮你建立起完整的知识体系，在实际项目中做出正确的技术决策。