Cookie 是小票，Session 是档案
本例 Cookie 保存编号，Session 保存用户信息。Cookie 也能独立保存主题偏好等内容，不一定对应一个 Session。
Cookie & Session / 从一次登录开始
Cookie 与 Session
区别与原理动画
浏览器凭什么记得你？Cookie 像浏览器收好的一张小票，Session 像服务器保存的一份档案。
用54秒动画看懂登录过程，再逐项拆解 Cookie 参数。
跟着请求，走完一次登录
看请求怎样出发、小票怎样落入浏览器、服务器怎样查档案。
准备播放一次登录的完整旅程 · 54 秒
01
第一次见面，网站不认识你
浏览器发送请求时还没有身份小票，服务器只能把你当作访客。
01 / 06
展开这一幕的 HTTP 报文
GET /account HTTP/1.1 Host: shop.example.com （此时没有 Cookie 请求头）
这是常见的“服务端 Session + 会话 ID Cookie”方案。所有动画都是本地模拟，不读取或设置你的真实 Cookie。
文字版：Cookie 与 Session 怎样完成一次登录？
首次访问：没有 Cookie，身份未知
浏览器首次请求账户页面，没有携带 session_id，服务器只能返回访客内容。HTTP 请求本身不会自动记住用户。
登录验证：服务器创建 Session
服务器验证登录信息后，创建 Session，把用户“小林”与会话编号 sid_demo 关联。档案保存在服务器，可以存于内存、数据库或其他服务端存储中。
保存 Cookie：响应带回会话编号
服务器使用 Set-Cookie: session_id=sid_demo 设置浏览器 Cookie。浏览器保存的是编号，用户档案仍留在服务器。
再次请求：浏览器筛选并携带 Cookie
主机、路径、有效期、传输和 SameSite 等条件允许时，浏览器发送 Cookie: session_id=sid_demo。请求中只有名称和值，不会带回全部 Cookie 属性。
查询 Session：按编号识别用户
服务器验证收到的会话编号，并查询对应的有效 Session。查到小林的档案后，才返回其账户内容；收到 Cookie 本身不能证明登录有效。
Session 过期：Cookie 仍在也需重新登录
服务器 Session 超时后，浏览器里的 Cookie 可能仍然存在，并继续随符合条件的请求发送。服务器查不到有效档案，就要求重新登录；两边的有效期分别控制。
两边的有效期分别计算
Cookie 还在，Session 也可能已经超时。反过来，丢了 Cookie，服务器里的 Session 也不会自动消失。
关掉浏览器，不一定退出
会话 Cookie 的寿命由浏览器会话决定，恢复会话可能把它带回来。网站应在退出时主动让 Session 失效。
那点击“退出登录”时，会发生什么？
服务器作废对应的 Session，再通过 Set-Cookie 让同名、同 Domain 和 Path 的 Cookie 过期。这样浏览器里的小票被清掉，原来的编号也不能再用来登录。
HTTP/1.1 200 OK Set-Cookie: session_id=; Path=/; Max-Age=0; Secure; HttpOnly; SameSite=Lax 服务器：删除或作废 sid_demo 对应的 Session
仅删除浏览器里的 Cookie，并不等于让被复制的会话 ID 立即失效。
Cookie 与 Session 有什么区别？
在本课的服务端 Session 登录方案中，两者通常配合使用。
| 对比项 | Cookie | 服务端 Session |
|---|---|---|
| 保存在哪里 | 浏览器中，由浏览器保存和管理。 | 服务器端，可放在内存、数据库或缓存等存储中。 |
| 保存什么 | 名称与值，以及域、路径、寿命等属性；本例保存会话编号。 | 会话编号对应的用户状态；本例保存小林的登录信息。 |
| 怎样参与请求 | 条件允许时，浏览器将名称和值放进 Cookie 请求头。 | 服务器收到会话编号后，查询并验证对应的会话。 |
| 什么时候失效 | 由 Expires、Max-Age 或浏览器会话决定，也可能被提前清理。 | 由服务端超时、退出登录或主动作废等逻辑决定。 |
| 一定要配合吗 | 不一定；也可以独立保存主题等偏好。 | 会话 ID 常用 Cookie 传递，本课演示这种常见方案。 |
“会话 Cookie”是 Cookie 的一种寿命类型，并不是服务器里的 Session。Cookie 尚未过期，也可能因为 Session 已失效而需要重新登录。
Cookie 参数详解：拆开一条 Set-Cookie
点击任意一段，看看它到底管什么。
Set-Cookie 是服务器的设置指令；浏览器下次发回的 Cookie 请求头只有名称和值，例如 Cookie: session_id=sid_demo，不会附带这些属性。
进阶：Cookie 名称前缀，有哪些额外约束？
| 名称开头 | 支持该前缀的浏览器会要求 |
|---|---|
__Secure- | 安全来源设置，并带 Secure。 |
__Host- | 安全来源、Secure、Path=/，且不能设置 Domain。 |
__Http- | 安全来源、Secure、HttpOnly，要求由 HTTP 设置指令创建。 |
__Host-Http- | 同时满足 __Host- 与 __Http- 的限制。 |
前缀是名称的一部分。后两种较新，浏览器支持不同；服务器仍需检查完整名称并验证会话。前缀不能代替服务端校验。
进阶：开发者工具里的 Size、Priority、Partition Key 呢？
Size 是浏览器显示的大小，并非 Set-Cookie 参数。Priority 是部分实现曾提供的清理优先级提示，Chrome 文档已标为废弃，不作为通用参数推荐。Partition Key 是分区 Cookie 对应的顶层站点等分区信息，不是手写在 Set-Cookie 中的属性。
在 Chrome 中打开开发者工具 → Application（应用）→ Storage（存储）→ Cookies，可以检查 Cookie；Network（网络）中可以对照请求 Cookie 与响应 Set-Cookie。
Cookie 参数实验：保存与发送规则
左边调整，右边立刻解释结果。先试试这几个情境。
浏览器会怎么做？
服务器响应 · 设置指令
当前请求 · 实际携带
最初设置它的页面 · document.cookie
脚本读取结果始终按最初设置它的 HTTPS 同源、匹配路径及分区页面计算；它和当前请求是否携带分别判断。从外站不能直接读取目标网站的 Cookie。
实验只模拟这些选项对应的核心规则，默认请求在允许使用凭据的情境下发出，且没有额外隐私限制。实际跨源 fetch 还要考虑 credentials、CORS 与浏览器策略；SameSite=None 不保证第三方 Cookie 可用。实验只检查当前时刻，不模拟时间流逝。外站设置情境按嵌入资源响应计算。
记住这三件事就够了
小票在浏览器，
档案在服务器。
本课演示的是一种常见登录方案。理解了“谁保存、何时携带、怎样查找”，就不用把 Cookie 和 Session 当成两个孤立名词。
- 登录：服务器创建 Session，用 Set-Cookie 发来会话 ID。
- 再访问：浏览器先按 Cookie 规则筛选，再把名称和值放进请求头。
- 识别：服务器验证 ID 并查询有效 Session；有 Cookie 不等于一定登录。
继续查阅 · 内容核对于 2026-11-06
HTTP Cookie 标准 ↗SameSite 讲解 ↗CHIPS 分区 Cookie ↗Set-Cookie 参数参考 ↗Chrome 开发者工具 ↗← 返回技术动画在你的浏览器里，慢慢把原理看清。