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