Session ✨

• 为什么 Cookie 不够用（背景与问题）
• Session 是什么（概念与术语）
• 会话流程
• Cookie 与 Session 对比（面试高频）
• 会话销毁与过期

要点速览

• 会话状态保存在服务器，通过 sessionid 与客户端关联；客户端使用 Cookie 携带标识。
• 敏感数据（验证码、权限标记、用户权限列表等）不应存入 Cookie；使用 HttpOnly/SameSite/Secure 提升安全。
• 典型流程：创建会话 → Set-Cookie 返回 sessionid → 后续请求携带 → 服务端验证/读写 → 过期或销毁。
• 常见实现：单机内存（开发）、Redis（生产横向扩展）；配合负载均衡需会话共享或粘性会话。
• 防护重点：避免会话固定与劫持；合理设置过期、清理策略；跨域场景配合 CORS 与凭证。

为什么 Cookie 不够用（背景与问题）

Cookie 保存在客户端，易被窃取或篡改，且空间与类型受限。如下场景常见误用：

为什么验证的工作要在前端进行？

前端提前对验证码进行基础校验，本质是 “过滤明显无效的请求”，避免这些操作占用后端资源、同时减少用户等待时间，提升用户体验。后端仍旧需要进行最终校验。

若将验证码等敏感数据直接写入 Cookie，攻击者可伪造请求或窃取 Cookie 后绕过验证。

不要在 Cookie 中存储敏感数据

• 切勿在 Cookie 中存储验证码、权限令牌的明文、用户隐私信息。
• 优先使用服务器端会话保存敏感状态，并通过 sessionid 建立关联。

Session 是什么（概念与术语）

• Session：服务器端维护的会话状态，本质是一个键值对容器（会话存储），生命周期通常较短。
• sessionid：标识某一客户端会话的随机 ID，通过 Set-Cookie 下发至浏览器，后续请求自动携带。
• Cookie：浏览器端存储键值对；在本场景用于仅携带 sessionid 标识，而不承载敏感业务数据。

会话流程

客户端与服务端围绕 sessionid 的交互：客户端首次访问 → 服务端创建会话 →Set-Cookie 返回 sessionid→ 后续请求自动携带 → 服务端读取会话。

Cookie 安全属性

• HttpOnly：防止前端脚本读取，降低 XSS 下的会话窃取风险。
• SameSite=Lax/Strict：减轻 CSRF；登录态建议至少 Lax。
• Secure：仅在 HTTPS 下传输 Cookie，生产环境必须开启。

Cookie 与 Session 对比（面试高频）

对比项	Cookie	Session
存储位置	浏览器端	服务器端
类型限制	字符串为主	任意结构（对象/列表等）
空间限制	单域约 4KB	受存储介质限制（内存/Redis）
安全性	易被读取/篡改	服务端控制、访问受限
典型用途	标识（如 sessionid）、偏好设置	认证/授权态、验证码、购物车、临时状态

选型建议

• 登录态使用 Session 管控，Cookie 仅承载 sessionid；若需前后端分离的无状态模式，可改用 JWT，并配合短期刷新令牌与服务端黑名单。

会话销毁与过期

• 过期时间：服务端记录 expiresAt，当客户端长时间不携带 sessionid 访问，超时后自动清除会话。
• 主动注销：客户端调用退出接口，服务端删除会话并清除 Cookie（Max-Age=0）。
• 清理任务：定期扫描过期会话，避免内存膨胀；分布式场景使用集中式存储（Redis）统一过期策略。

会话固定与劫持防护

• 登录后重新生成新的 sessionid 并失效旧 ID，降低会话固定攻击风险。
• 开启 HttpOnly/Secure/SameSite，并限制可接受的 Origin/Referer；配合 CSRF 防护与 XSS 防护。