Cookie 和 Session：网站为什么能记住你的登录状态

Cookie 和 Session 经常被一起讲，是因为它们都在解决同一个问题：HTTP 请求天然是一次一次来的，服务器收到一个请求，只看这次请求本身，并不会自动知道它和上一次请求来自同一个登录用户。

文中的概括很清楚：Cookie 和 Session 都用于管理用户状态和身份。Cookie 通过在客户端记录信息来帮助确定用户身份；Session 通过在服务器端记录信息来维护用户状态。一个偏客户端，一个偏服务端，两者经常配合使用。

比如用户登录后，服务器不能指望下一次请求“自己记得”这个用户已经登录。它需要一种凭证，让浏览器后续请求能带上身份线索；同时服务端也要有地方保存登录状态、购物车、用户偏好这些会话数据。Cookie 和 Session 就是在这两头配合。

Cookie 是存储在用户浏览器里的小型文本数据。服务器可以在 HTTP 响应头里通过 `Set-Cookie` 创建 Cookie，浏览器收到后把它保存到本地。后续访问同一个符合域名、路径和安全规则的网站时，浏览器会自动把对应 Cookie 放进请求头。

文中提到，Cookie 可以带名称、值和其他参数，比如过期时间、域名、路径等。会话级 Cookie 通常在浏览器关闭后失效；持久 Cookie 则会在设定时间内保留，过期后浏览器不再发送。

Cookie 的优点是简单，浏览器原生支持，请求时自动携带。缺点也明显：它存储在用户浏览器里，容量较小，通常只有几 KB；而且用户可以查看、删除，甚至通过工具修改。敏感明文信息不应该直接放进 Cookie。

Session 是服务器端保存和管理用户状态的机制。用户第一次访问或登录成功后，服务器为这个用户创建一个唯一的 Session ID，并在服务器上开辟一份会话存储。这里可以保存登录状态、购物车内容、临时上下文、用户偏好等信息。

浏览器并不直接拿到完整 Session 数据。更常见的做法是，服务器把 Session ID 通过 `Set-Cookie` 发给浏览器。浏览器后续请求带上这个 ID，服务器再根据 ID 查自己的 Session 存储，判断用户是谁、是否已登录、会话有没有过期。

这就解释了一个常见说法：Cookie 在客户端，Session 在服务端。严格讲，浏览器通常保存的是 Session ID 这把钥匙，真正的会话数据放在服务端。钥匙丢了，服务器就找不到那份状态；服务端会话过期了，钥匙带回来也没用了。

以普通网页登录为例，浏览器先把用户名和密码提交给服务器。服务器校验通过后，在服务端创建一份 Session，里面记录用户 ID、登录状态、过期时间，必要时还会记录权限、购物车或当前上下文。

接着服务器生成一个 Session ID，并通过响应头返回：`Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure`。浏览器保存这个 Cookie。之后用户访问同一站点时，浏览器会自动在请求头里带上 `Cookie: session_id=abc123`。

服务器收到请求后，不是相信 Cookie 里写的所有内容，而是读取其中的 Session ID，再去服务端 Session 存储里查。查到了、没过期、状态有效，就认为用户已登录；查不到或过期，就让用户重新登录。

资料 从几个角度对比了两者。第一是存储位置：Cookie 数据在浏览器，Session 数据在服务器。第二是容量：Cookie 容量小，Session 容量取决于服务器资源和存储方案。第三是安全性：Cookie 用户可见、可改，Session 数据在服务端，更不容易被客户端直接篡改。

传输方式也不同。Cookie 会在符合条件的 HTTP 请求中自动发送到服务器，所以 Cookie 太大，会增加每次请求的头部体积。Session 本身不随请求传输，通常只传一个 Session ID。真正的数据查找发生在服务器内部。

不过 Session 也不是没有成本。服务端要保存状态，就要消耗内存、缓存或数据库资源。单机服务可以把 Session 放内存里，分布式服务就要考虑共享 Session、集中存储、粘性会话，或者干脆改成 Token/JWT 这类无状态方案。

很多初学者会犯的错误，是把用户 ID、手机号、角色、余额甚至密码明文放进 Cookie。这样做很危险。Cookie 在浏览器端，用户能看到，也能通过浏览器的 Network 面板或脚本尝试修改。即使做了编码，也不等于加密。

比较稳的做法是只在 Cookie 里放会话标识或经过签名的有限信息。服务端收到后必须校验合法性，不能只因为 Cookie 写着 `role=admin` 就让用户拥有管理员权限。权限、余额、订单归属这类关键判断，一定要以服务端可信数据为准。

常见安全属性也要用上。`HttpOnly` 可以减少 JavaScript 读取 Cookie 的风险，降低 XSS 窃取会话的概率；`Secure` 要求 Cookie 只通过 HTTPS 发送；`SameSite` 可以限制跨站请求自动携带 Cookie，缓解一部分 CSRF 风险。

已有内容提到服务器会为每个会话设置超时时间。用户长时间没有活动，会话自动过期，Session 数据被清除。这个机制很重要，因为服务端资源有限，也因为登录态不应该无限期有效。

过期时间不能只看方便。时间太短，用户经常被踢回登录页；时间太长，账号在公共电脑或被盗 Cookie 的情况下风险更高。实际系统常见做法是会话有固定最长有效期，同时根据用户活动刷新短期过期时间。

退出登录时，也不能只让浏览器删 Cookie。更稳的做法是服务端同时删除或失效对应 Session。否则攻击者如果已经拿到旧 Session ID，理论上仍可能在服务端 Session 未过期前继续使用。退出登录的意义，是让这把钥匙立刻失效。

单机应用里，Session 放本机内存就能跑。但服务一旦变成多台机器，问题就来了：用户第一次请求打到 A 机器，Session 存在 A；下一次请求被负载均衡打到 B，B 查不到 Session，就会误以为用户没登录。

常见解决办法有几种。第一是粘性会话，让同一个用户尽量固定打到同一台机器。第二是集中式 Session，把会话放到 Redis、数据库或专门的会话服务里，多台应用服务器都能查。第三是使用签名 Token，让服务端不保存完整会话状态，靠校验 Token 判断身份。

每种方案都有取舍。粘性会话简单，但机器故障或扩缩容时不够灵活；集中式 Session 好管理，但依赖缓存或存储可用性；Token 易于横向扩展，但撤销、续期和权限变更要设计好。理解 Cookie 和 Session，是理解这些登录架构的起点。

如果用户登录后马上掉线，先看响应里有没有 `Set-Cookie`，浏览器有没有保存，后续请求有没有带上 Cookie。域名、路径、SameSite、Secure、HTTPS、跨域请求配置，都可能影响 Cookie 是否被保存和发送。

如果只有部分用户异常，要看是否和浏览器策略、第三方 Cookie 限制、无痕模式、跨域嵌入有关。如果只在多机环境偶发，要看 Session 是否共享，负载均衡是否改变了请求落点，服务端 Session 存储是否有超时或淘汰。

如果用户明明退出了还像没退出，要看服务端 Session 是否真正删除，Cookie 是否清掉，前端缓存是否展示了旧状态。登录态问题经常跨浏览器、HTTP 头、服务端存储和前端状态管理，别只盯一个地方。

如果被问 Cookie 是什么，可以说：Cookie 是浏览器保存的小型文本数据，服务器通过 `Set-Cookie` 写入，浏览器后续请求会按域名、路径和安全规则自动携带，常用于会话标识、偏好设置和状态传递。

如果被问 Session 是什么，可以说：Session 是服务端保存用户会话状态的机制。服务器生成 Session ID，把它通常通过 Cookie 发给浏览器；浏览器后续带回 Session ID，服务器据此查找登录状态、购物车或临时上下文。

如果被问区别，就按存储位置、容量、安全性和传输方式讲：Cookie 在客户端、容量小、每次请求自动携带、可被查看和篡改；Session 在服务端、容量取决于服务器资源、客户端一般只传 Session ID、安全性更高但会占用服务端资源。