引入
HTTP 请求本身是无状态的：服务器处理完一次请求后，不会天然记住下一次请求和上一次请求属于同一个用户。登录、购物车和权限信息却要求跨请求保持状态，因此需要 Session 这样的会话机制。
正文
定义
Session 是服务器为一组相关请求保存的会话状态。客户端通常只保存一个 Session ID，服务器根据这个 ID 查找对应的会话数据。
基本流程
- 用户登录并提交凭证。
- 服务器验证成功后创建会话。
- 服务器把 Session ID 返回给客户端，通常放在 Cookie 中。
- 后续请求携带 Session ID，服务器据此恢复用户状态。
- 用户注销或会话过期后，服务器删除或拒绝该会话。
Session 与 Cookie 的区别
| 对比项 | Session | Cookie |
|---|---|---|
| 主要存储位置 | 服务器端 | 客户端 |
| 客户端通常保存 | 会话标识 | 键值数据本身 |
| 适合保存 | 登录状态、临时业务状态 | 标识、偏好、会话 ID |
| 主要风险 | 服务端存储与扩展成本 | 泄露、伪造、跨站请求携带 |
Session 不是天然安全的。Session ID 被窃取后，攻击者可能冒充用户，因此应配合 HTTPS、HttpOnly、Secure、合理的 SameSite 和会话过期策略。
常见问题
- Session 固定攻击：登录前后的 Session ID 未更新，攻击者可能提前植入并复用该 ID。登录成功后应重新生成会话标识。
- 多实例部署失效：会话只存在单台服务器内时，请求切换实例可能找不到状态。可以使用共享存储，或采用经过设计的无状态认证方案。
- 注销不彻底：只清除浏览器 Cookie 不足以保证会话失效，服务端也应使对应 Session ID 失效。
引出
Session 适合服务端需要主动控制会话生命周期的场景。若系统更重视跨服务传递身份信息，可能会使用 Token，但这并不意味着可以忽略过期、撤销和存储安全问题。