Cookie 与 Session 的工作流程--含可视化流程图

目录

一、如果没有 Cookie 和 Session，世界会怎样？

1️⃣ 首先你要知道：HTTP 是“失忆”的

2️⃣ 如果真的一直这样，会发生什么？

二、Cookie：贴在你身上的“便利贴”

1️⃣ Cookie 是什么？

2️⃣ Cookie 的工作流程（完整可视化过程）

🔍 第一次访问时（你还没任何身份标识）

🔁 再次访问时（浏览器会自动带着 Cookie）

3️⃣ Cookie 的优点与缺陷

三、Session：服务器的小本子

1️⃣ Session 到底是什么？

2️⃣ Session 为什么离不开 Cookie？

四、Session 的完整工作原理（核心！！）

🔐 登录瞬间，到底发生了什么？

🔁 后续每一次请求（身份验证过程）

五、Cookie + Session 的黄金搭档关系

六、常见关键细节（很多人都会踩坑的点）

🔸 Cookie 里不会存真正的用户信息

🔸 Session 不是一定存在内存

🔸 Cookie 可能被禁用

七、10 年大厂高频真题（含生活化答案）

✅ 题目 1：为什么 Cookie 不能存敏感信息？

✅ 题目 2：Session 一定依赖 Cookie 吗？

✅ 题目 3：分布式系统 Session 怎么办？

✅ 题目 4：Session vs JWT 最大区别？

✅ 题目 5：Cookie 被禁用怎么办？

八、最近10年大厂常考题目及答案

考题 1：Cookie 和 Session 的区别与联系是什么？（阿里 2021、字节 2023）

考题 2：Cookie 有哪些安全属性？分别解决什么问题？（腾讯 2022、美团 2024）

考题 3：分布式系统中，Session 如何实现共享？有哪些方案？（阿里 2023、字节 2025）

考题 4：如果浏览器禁用了 Cookie，Session 还能使用吗？如何实现？（美团 2021、京东 2023）

考题 5：a.baidu.com和b.baidu.com如何共享 Cookie？（字节 2020、阿里 2025）

一、如果没有 Cookie 和 Session，世界会怎样？

1️⃣ 首先你要知道：HTTP 是“失忆”的

HTTP 协议有一个非常硬核的特性：

👉无状态（Stateless）——服务器不会记住你是谁

用生活比喻：

你走进便利店买水 → 出门 → 5 秒后再进来 → 店员依然当你是陌生人。

这就是 HTTP。

2️⃣ 如果真的一直这样，会发生什么？

• 购物车永远记不了东西

• 登录每刷新一次页面就得重新输密码

• 银行网站根本无法工作

所以，我们必须给“失忆的服务器”加点记忆能力。

👉于是 Cookie 和 Session 应运而生。

二、Cookie：贴在你身上的“便利贴”

1️⃣ Cookie 是什么？

专业定义：

Cookie 是服务器发送到浏览器并由浏览器保存的一小段数据，每次请求会自动带回给服务器。

人话版本：

服务器给你贴了张便利贴，说：
“以后再来，把这张带上，我就知道是你了。”

2️⃣ Cookie 的工作流程（完整可视化过程）

🔍 第一次访问时（你还没任何身份标识）

🔁 再次访问时（浏览器会自动带着 Cookie）

3️⃣ Cookie 的优点与缺陷

优点：

• 浏览器自动携带

• 机制简单

• 非常适合存少量身份标识

致命缺点：

❌ Cookie 在客户端，用户能看到、能删、甚至能改

这意味着：

• 不安全

• 不能直接存敏感信息

👉 于是Session 登场了。

三、Session：服务器的小本子

1️⃣ Session 到底是什么？

专业定义：

Session 是服务器为每个用户维护的一份“会话状态数据”。

生活比喻：

服务器有一本小本子，记着：
“这个用户是谁，登录了吗，有什么权限，正在干什么。”

2️⃣ Session 为什么离不开 Cookie？

很多人误解：

“用 Session 就不需要 Cookie 了吧？”

错！真正真相是：

👉Session 不把数据放 Cookie，只把“钥匙（SessionID）放 Cookie”。

四、Session 的完整工作原理（核心！！）

🔐 登录瞬间，到底发生了什么？

🔁 后续每一次请求（身份验证过程）

五、Cookie + Session 的黄金搭档关系

一句专业总结：

Cookie 负责“编号”，Session 负责“内容”。

一句生活总结：

• Cookie 像：寄存柜的取件牌

• Session 像：柜台后面的真实包裹

📌 取件牌丢了 → 还可以人工找，但麻烦
📌 包裹没了 → 你拿号码也没用

六、常见关键细节（很多人都会踩坑的点）

🔸 Cookie 里不会存真正的用户信息

只存：SessionID / Token / Key

🔸 Session 不是一定存在内存

• 小系统：内存

• 大厂：Redis / Session 集群 / 共享 Session

🔸 Cookie 可能被禁用

此时：

• URL 重写

• Header 自定义

• JWT 替代

七、10 年大厂高频真题（含生活化答案）

✅ 题目 1：为什么 Cookie 不能存敏感信息？

专业回答：
Cookie 在客户端，可被查看、篡改，并且存在 XSS 攻击威胁。

生活比喻：
就像把银行卡密码写在钱包外壳上。

✅ 题目 2：Session 一定依赖 Cookie 吗？

专业回答：
不是必须，可以通过 URL 重写、Header，但 Cookie 是最主流方式。

生活比喻：
你可以刷卡进门，也可以人工登记。

✅ 题目 3：分布式系统 Session 怎么办？

专业回答：
Session 共享（Redis）、Session 同步、或干脆改用 JWT 无状态方案。

生活比喻：
连锁超市共享会员系统，而不是每家店各一本。

✅ 题目 4：Session vs JWT 最大区别？

专业回答：
Session 有状态（服务器保存），JWT 无状态（信息自包含在 Token 里）。

生活比喻：
Session = 商家账本
JWT = 印着你信息的身份证

✅ 题目 5：Cookie 被禁用怎么办？

专业回答：
Session 机制失效，需要 URL 传递、Header、或改 Token 架构。

生活比喻：
进出小区不能刷卡 → 每次都人工登记。

八、最近10年大厂常考题目及答案

以下是阿里、腾讯、字节、美团等大厂近10年高频面试题

考题 1：Cookie 和 Session 的区别与联系是什么？（阿里 2021、字节 2023）

专业答案：

区别：

① 存储位置：Cookie 在客户端（浏览器），Session 在服务器端；

② 安全性：Cookie 易被篡改 / 窃取（需通过 HttpOnly/Secure 等属性增强安全），Session 数据在服务器，安全性更高；

③ 存储容量：Cookie 通常≤4KB / 域名，Session 无固定限制（取决于服务器存储）；

④ 过期策略：Cookie 可通过 Expires/Max-Age 自定义过期（默认随浏览器关闭），Session 依赖服务器配置（如超时自动失效）；

⑤ 交互方式：Cookie 每次请求自动携带，Session 通过 Session ID 关联（通常存于 Cookie）。

联系：

① Session 依赖 Cookie 传递 Session ID，二者协同实现 HTTP 状态跟踪；② Cookie 可独立使用（如存储用户偏好），Session 不可独立使用（需依赖 Session ID 传递）。

通俗解释：

区别：① 存放位置：Cookie 是你手里的会员卡（客户端），Session 是店里的会员档案（服务器）；

② 安全性：会员卡容易丢 / 被改（Cookie），档案锁在柜子里（Session）更安全；

③ 容量：会员卡只能写少量信息（4KB），档案本可以写很多内容；

④ 过期：会员卡可以设置有效期（Cookie），档案超过 30 分钟没人用就自动作废（Session）；⑤ 使用方式：你每次去都要带会员卡（Cookie 自动携带），档案要通过会员卡编号查找（Session 依赖 Session ID）。

联系：

① 没有会员卡（Cookie），店员找不到你的档案（Session）；

② 会员卡可以单独用（比如存积分），但档案不能单独用（必须要编号）。

考题 2：Cookie 有哪些安全属性？分别解决什么问题？（腾讯 2022、美团 2024）

专业答案：

Cookie 的核心安全属性及作用：

① HttpOnly：禁止客户端 JavaScript 读取 Cookie，解决 XSS 攻击窃取敏感 Cookie（如 Session ID）的问题；

② Secure：仅在 HTTPS 协议下发送 Cookie，解决 HTTP 连接中 Cookie 被中间人窃听的问题；③ SameSite：控制跨站请求是否发送 Cookie，取值 Strict（跨站不发送）、Lax（仅顶层导航发送）、None（允许发送，需配合 Secure），解决 CSRF 攻击问题；

④ Domain/Path：限制 Cookie 的生效域名和路径，避免 Cookie 被无关路径或子域滥用，缩小安全风险范围。

通俗解释：

Cookie 的安全属性就像给会员卡加了各种安全限制：

① HttpOnly：会员卡标注 “员工专用，顾客不能看详情”，防止别人（XSS 攻击）偷看到卡上的编号；

② Secure：会员卡标注 “仅店内使用，禁止带出店外”，防止在外面（HTTP 连接）被别人抢走；③ SameSite：会员卡标注 “仅限本人使用，禁止转借”，防止别人（CSRF 攻击）用你的卡冒名消费；

④ Domain/Path：会员卡标注 “仅本连锁门店生鲜区使用”，避免别的店（子域）或别的区域（路径）滥用你的卡。

考题 3：分布式系统中，Session 如何实现共享？有哪些方案？（阿里 2023、字节 2025）

专业答案：

分布式系统中 Session 共享的核心问题：用户请求可能被负载均衡分发到不同服务器，单机存储的 Session 无法跨节点共享，导致用户 “明明登录了却被要求重新登录”。

常见方案：

① Session 复制：集群中每个服务器将本地 Session 复制到其他节点，优点是实现简单、用户无感知，缺点是节点增多后复制开销指数级增长，不适合大规模集群；

② Session 绑定（Sticky Session）：通过负载均衡将用户固定到同一服务器，优点是实现成本低、性能好，缺点是扩展性差，节点宕机导致 Session 丢失；

③ 集中式存储：将 Session 存储在独立的共享组件（如 Redis、Memcached），所有服务器通过 Session ID 从集中存储中获取 Session 数据，优点是扩展性好、支持高并发，缺点是增加外部依赖，需保证存储层高可用，是目前主流方案；

④ Token 方式（无状态 Session）：用 JWT 等 Token 替代 Session，服务器不存储 Session 数据，Token 包含用户信息并签名，客户端每次请求携带 Token，优点是服务端无状态、天然支持水平扩展，缺点是 Token 一旦签发无法轻易撤销，刷新机制较复杂。

通俗解释：分布式系统就像连锁便利店，每个门店（服务器）都有自己的档案柜（单机 Session），顾客（用户）可能去不同门店，导致档案无法共享。

解决方案：

① Session 复制：每个门店把顾客档案复印一份发给其他门店，优点是不用额外设备，缺点是门店多了复印太费时间；

② Session 绑定：让顾客每次都去同一个门店，优点是简单、快，缺点是这个门店关门了（服务器宕机），顾客的档案就没了；

③ 集中式存储：所有门店共用一个中央档案库（Redis），不管顾客去哪个门店，都去中央档案库查档案，优点是门店可以随便加、档案不会丢，缺点是需要单独维护中央档案库；

④ Token 方式：不用档案库，给顾客发一个带签名的凭证（Token），凭证上写着顾客信息，每个门店只要验证凭证的签名就知道顾客身份，优点是不用维护档案库、门店可以无限加，缺点是凭证发出去后不能随便收回，需要定期换。

考题 4：如果浏览器禁用了 Cookie，Session 还能使用吗？如何实现？（美团 2021、京东 2023）

专业答案：浏览器禁用 Cookie 后，Session 仍可使用，核心是通过其他方式传递 Session ID。

常见实现方式：

① URL 重写：将 Session ID 拼接在 URL 末尾，格式为 “URL;jsessionid=xxx”，服务器接收请求时从 URL 中解析 Session ID；

② 表单隐藏字段：在表单中添加隐藏字段<input type="hidden" name="jsessionid" value="xxx">，提交表单时将 Session ID 传递给服务器；

③ 自定义请求头：通过 AJAX 请求的自定义头（如 X-Session-ID: xxx）传递 Session ID。

注意事项：

① URL 重写需对所有 URL 编码，且静态页面无法使用；

② 表单隐藏字段仅适用于表单提交场景；

③ 自定义请求头需前端配合，适用范围有限；

④ 这些方式安全性和用户体验均不如 Cookie，现在很少使用，更推荐用 Token 认证替代。

通俗解释：浏览器禁用 Cookie 就像顾客丢了会员卡（不能存储 Session ID），但还是可以通过其他方式证明身份：

① URL 重写：店员把顾客的档案编号写在购物袋上（URL 末尾），顾客下次来的时候带着购物袋，店员从购物袋上找编号；

② 表单隐藏字段：店员把档案编号写在一张纸条上，放在顾客的购物车里（表单隐藏字段），顾客结账时把纸条一起交给店员；

③ 自定义请求头：顾客每次来的时候主动告诉店员自己的档案编号（自定义请求头）。

这些方式的缺点：

① 购物袋上的编号容易被别人看到（URL 重写不安全）；

② 纸条只能在结账时用（表单场景有限）；

③ 主动说编号太麻烦（自定义请求头）；

④ 所以现在更推荐用电子凭证（Token）替代。

考题 5：a.baidu.com和b.baidu.com如何共享 Cookie？（字节 2020、阿里 2025）

专业答案：实现同主域下不同子域共享 Cookie 的核心是设置 Cookie 的 Domain 属性。

具体步骤：

① 服务器在 Set-Cookie 响应头中设置 Domain=.baidu.com（注意前面的点），表示该 Cookie 适用于baidu.com及其所有子域（a.baidu.com、b.baidu.com等）；

② 确保 Cookie 的 Path 属性设置为 /（表示整个域名下所有路径生效）；

③ 子域a.baidu.com和b.baidu.com的请求都会自动携带该 Cookie，从而实现共享。

注意事项：

① Domain 属性不能设置为跨主域（如将baidu.com的 Cookie 设置为 Domain=.google.com是无效的），受同源策略限制；

② 共享的 Cookie 建议设置 HttpOnly、Secure 等安全属性，避免被滥用。

通俗解释：a.baidu.com和b.baidu.com就像百度连锁的两家门店（子域），要让顾客的会员卡（Cookie）在两家店通用：

① 店员在发卡时标注 “全百度连锁门店通用”（Domain=.baidu.com），而不是 “仅限 a 店使用”（默认 Domain=a.baidu.com）；

② 同时标注 “全门店所有区域可用”（Path=/）；

③ 这样顾客拿着这张卡去 b 店，店员也能识别，实现会员卡共享。

注意：

① 不能把百度的会员卡标注 “谷歌门店通用”（跨主域无效），只能在同一连锁品牌（同主域）内共享；

② 共享的会员卡也要加安全限制（HttpOnly/Secure），避免被滥用。

总结

1. Cookie 与 Session 核心差异在于存储位置和状态性，Session 依赖 Cookie 传递 ID，二者协同实现 HTTP 状态跟踪；
2. Cookie 的安全属性（HttpOnly/Secure/SameSite 等）是抵御 XSS/CSRF 等攻击的关键，Domain/Path 可控制 Cookie 生效范围；
3. 分布式 Session 共享的主流方案是集中式存储（Redis），禁用 Cookie 时可通过 URL 重写等方式传递 Session ID，但更推荐 Token（JWT）方案；
4. 同主域子域共享 Cookie 的核心是设置 Domain=. 主域名，且需遵循同源策略，同时搭配安全属性保障安全。