Cookie
为什么需要 Cookie
HTTP 是无状态协议，每次请求相互独立，服务器默认无法判断两次请求是否来自同一用户。同时，浏览器出于安全限制，不允许 JavaScript 直接读写本地文件系统。因此，浏览器引入 Cookie 机制，将少量数据存储在浏览器端，请求时自动发送给服务器，以此实现状态保持。
认证流程详解
最常见的应用场景是登录认证。
服务器 浏览器 服务器 浏览器 2. 验证用户名密码 3. 匹配成功， 生成 sessionId + session 对象 存入内存哈希表 5. 浏览器保存 Cookie --- 后续请求 --- 7. 通过 sessionId 识别用户身份 1. 发送登录请求（用户名、密码） 4. Set-Cookie: sessionId=xxxx 6. 请求 + Cookie: sessionId=xxxx 8. 返回用户相关数据
Session 对象
- 存储在服务器端，通常是一个键值对结构。
- 保存当前会话的用户信息，如
userId、username、登录时间、权限等。 - 客户端看不到 Session 的具体内容，只能拿到对应的 sessionId。
SessionId
- 会话的唯一标识，由服务器生成。
- 生成要求：长度足够（通常 128 位以上），使用密码学安全随机数，防止被猜测或遍历。
- 本身不包含业务数据，只是一把"钥匙"。
Cookie 传递
- 服务器通过响应头
Set-Cookie下发 sessionId。 - 浏览器收到后自动存储，后续相同域名的请求自动在请求头
Cookie中携带。 - 这个携带过程由浏览器自动完成，代码无需手动拼接。
过期机制
- Cookie 可通过
Max-Age（相对时间，单位秒）或Expires（绝对时间）设置有效期。 - 过期后浏览器自动删除，下次请求不再携带，服务器视为未登录。
- 服务器端 Session 通常也设置过期时间（如 30 分钟无操作则失效），二者共同控制会话的生命周期。
安全相关配置
| 属性 | 作用 | 建议 |
|---|---|---|
HttpOnly |
禁止 JavaScript 读取 Cookie | 必须设置，防 XSS 窃取 |
Secure |
仅在 HTTPS 下传输 Cookie | 生产环境必须设置 |
SameSite |
控制跨站请求是否携带 Cookie | 设为 Lax 或 Strict，防 CSRF |
示例响应头：
Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=86400注销处理
用户退出登录时，需要同时做两件事：
- 服务端：销毁对应的 Session 对象，使该 sessionId 失效。
- 浏览器端 ：删除对应 Cookie（可通过设置
Max-Age=0覆盖）。
只清除前端 Cookie 而不销毁 Session，攻击者仍可能利用已泄露的 sessionId 完成认证。
分布式环境注意事项
单机部署时 Session 存储在服务器内存中；多机部署时，需使用共享存储方案：
- Redis（最常用）：集中存储 Session，所有服务器共享读写。
- 数据库：读写压力较大，一般不推荐。
- 粘性会话（Sticky Session）：负载均衡将同一用户始终路由到同一台机器，有单点故障风险，不推荐。