系统设计 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 是怎么诞生的？
用户提交账号密码 → 登录请求到达服务器
验证通过 → 服务器新建一条 Session 记录
生成唯一 Session Key + 绑定 User ID + 设置过期时间
把Session Key通过 HTTP 响应返回给浏览器
二、🍪 Cookie：浏览器里的「随身令牌」
Cookie 是什么？
它是浏览器的本地键值对存储，像一个小型哈希表，专门存放来自服务器的标记信息。
📌 Cookie 的关键特性
按域名隔离：A 站的 Cookie 不会带到 B 站
自动携带：每次向该网站发请求，浏览器会自动带上全部 Cookie
体积越小越好：数据越大，请求越臃肿、传输越慢🚶♂️
所以：Cookie 只存最关键的身份标记——Session Key，绝不存敏感信息。
🎫 超形象比喻
把登录比作进入会场：
Session Table = 后台登记本
Session Key = 你的入场牌
Cookie = 你挂在胸前的牌套
只要戴着牌，保安（服务器）一看便知你已授权，无需再查身份证。
三、🔗 完整流程：一次登录，全程通行
登录 → 服务器生成 Session，返回 Session Key
浏览器把 Session Key 存入 Cookie
后续每一次请求 → 自动带上 Cookie
服务器拿到 Session Key → 查询 Session Table
验证未过期 → 取出 User ID → 读取用户信息
保持登录状态，流畅访问✅
这就是我们一次登录、长期有效的底层逻辑。
四、❓ 三个灵魂问题，彻底吃透 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 登录、身份验证、会话管理的大门钥匙。不管是前端、后端、测试，都能在这套逻辑里找到自己的设计依据💡。
