系统设计 017： Session 与 Cookie

系统设计 017： Session 与 Cookie

• 一、🌐 Session：服务器端的「身份档案」
• • 🔐 Session Key 有多安全？
  • 🔄 Session 是怎么诞生的？
• 二、🍪 Cookie：浏览器里的「随身令牌」
• • 📌 Cookie 的关键特性
  • 🎫 超形象比喻
• 三、🔗 完整流程：一次登录，全程通行
• 四、❓ 三个灵魂问题，彻底吃透 Session
• • 1. Session 过期后，服务器会立刻删吗？
  • 2. 单设备登录 vs 多设备登录，区别在哪？
  • 3. Session 适合存在哪里？
• 五、📌 核心总结

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

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

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

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

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

• Expire At：会话过期时间戳

🔐 Session Key 有多安全？

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

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

🔄 Session 是怎么诞生的？

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

Cookie 是什么？

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

📌 Cookie 的关键特性

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

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

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

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

🎫 超形象比喻

把登录比作进入会场：

• Session Table = 后台登记本

• Session Key = 你的入场牌

• Cookie = 你挂在胸前的牌套

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

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

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

四、❓ 三个灵魂问题，彻底吃透 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 登录、身份验证、会话管理的大门钥匙。不管是前端、后端、测试，都能在这套逻辑里找到自己的设计依据💡。