系统设计 017： Session 与 Cookie

在 Web 世界里，登录态保持是绕不开的基础能力，而撑起这一切的，正是服务器端的Session与浏览器端的Cookie。它们像一对默契搭档，让我们只需一次登录，就能全程流畅访问，无需反复输入账号密码。今天就用清晰、好懂的方式，把这对核心概念彻底讲透✨。

一、🌐 Session：服务器端的「身份档案」

Session 是纯服务器端的会话机制，它的载体，是一张专门的Session Table（会话表）。这张表里，只存三件关键数据：

• Session Key（Session Token）：全局唯一的哈希串，相当于用户的临时身份证号

• User ID：标记这条会话属于哪个用户，常做加密处理

• Expire At：会话过期时间戳

🔐 Session Key 有多安全？

它由UUID / GUID这类哈希算法生成，字符集包含大小写字母、数字、下划线、横杠，组合空间大到近乎不可能重复。

哪怕在海量请求下，也不会出现冲突，安全性极高🔒。

🔄 Session 是怎么诞生的？

1. 用户提交账号密码 → 登录请求到达服务器

2. 验证通过 → 服务器新建一条 Session 记录

3. 生成唯一 Session Key + 绑定 User ID + 设置过期时间

4. 把Session Key通过 HTTP 响应返回给浏览器

二、🍪 Cookie：浏览器里的「随身令牌」

Cookie 是什么？

它是浏览器的本地键值对存储，像一个小型哈希表，专门存放来自服务器的标记信息。

📌 Cookie 的关键特性

• 按域名隔离：A 站的 Cookie 不会带到 B 站

• 自动携带：每次向该网站发请求，浏览器会自动带上全部 Cookie

• 体积越小越好：数据越大，请求越臃肿、传输越慢🚶‍♂️

所以：Cookie 只存最关键的身份标记——Session Key，绝不存敏感信息。

🎫 超形象比喻

把登录比作进入会场：

• Session Table = 后台登记本

• Session Key = 你的入场牌

• Cookie = 你挂在胸前的牌套

只要戴着牌，保安（服务器）一看便知你已授权，无需再查身份证。

三、🔗 完整流程：一次登录，全程通行

1. 登录 → 服务器生成 Session，返回 Session Key

2. 浏览器把 Session Key 存入 Cookie

3. 后续每一次请求 → 自动带上 Cookie

4. 服务器拿到 Session Key → 查询 Session Table

5. 验证未过期 → 取出 User ID → 读取用户信息

6. 保持登录状态，流畅访问✅

这就是我们一次登录、长期有效的底层逻辑。

四、❓ 三个灵魂问题，彻底吃透 Session

1. Session 过期后，服务器会立刻删吗？

不会。

服务器用懒惰删除（Lazy Deleting）：

过期记录先留着，等下次该 Key 再来请求，验证超时再清理，不浪费性能。

2. 单设备登录 vs 多设备登录，区别在哪？

• 单设备登录（如微信）

Session Table 增加Device Token，标记当前登录设备。

新设备登录 → 使旧设备 Session 失效 → 旧端自动登出。

• 多设备登录（如 QQ）

不用额外处理。

每个设备生成独立 Session，互不冲突，共用同一个 User ID。

3. Session 适合存在哪里？

• 小站点：可放Memcache等缓存，丢失只需重新登录

• 大型站点：必须存数据库，保证稳定

• 最优方案：数据库 + 前端缓存，兼顾安全与速度⚡

五、📌 核心总结

• Session：服务器的会话档案，存 Key、用户、过期时间

• Cookie：浏览器的令牌盒，只存 Session Key

• 机制：Cookie 带 Key → 服务器查 Session → 保持登录

• 原则：Cookie 轻量化、Session 唯一性、删除懒惰化

理解 Session 与 Cookie，就握住了 Web 登录、身份验证、会话管理的大门钥匙。不管是前端、后端、测试，都能在这套逻辑里找到自己的设计依据💡。