Cookie-Session-Token区别 • 面试知识库

高基础

一句话答案#

Cookie 存客户端（自动发送），Session 存服务端（依赖 Cookie 传 SessionID），Token 无状态自包含（JWT）。

核心要点

维度	Cookie	Session
存储位置	客户端（浏览器）	服务端（内存/Redis/DB）
安全性	较低（可被 JS 读取，可篡改）	较高（存在服务端）
大小限制	~4KB	无限制（受服务器内存限制）
生命周期	可持久化（Expires/Max-Age 设置）	默认浏览器关闭则失效；服务端可设超时
跨域	Cookie 有 Same-Site 限制	Session ID 通过 Cookie 携带，同样有跨域问题
扩展性	不依赖服务器，天然分布式	多服务器需要 Session 共享（Redis）

关系：

Session 通常通过 Cookie 传递 Session ID
用户第一次请求 → 服务端创建 Session → 将 Session ID 写入 Cookie
后续请求 → 浏览器自动携带 Cookie（含 Session ID）→ 服务端查找对应 Session

Cookie 的安全属性：

HttpOnly：禁止 JS 读取（防 XSS 盗 Cookie）
Secure：只在 HTTPS 下传输
SameSite=Strict/Lax/None：控制跨站请求是否携带 Cookie（防 CSRF）

plaintext

面试回答（2分钟版）

Cookie、Session 和 Token 是三种不同的用户状态管理机制。Cookie 是存储在客户端浏览器中的小段数据，每次请求时自动随 HTTP 头发送给服务端，大小限制约 4KB，可以设置过期时间实现持久化。安全方面可以通过 HttpOnly 防止 JS 读取、Secure 限制 HTTPS 传输、SameSite 控制跨站发送防 CSRF。Session 存储在服务端，用户首次访问时服务端创建 Session 对象并生成唯一的 SessionID，通过 Cookie 传递给客户端，后续请求携带 SessionID 服务端查找对应 Session 获取用户信息。Session 的问题是分布式部署时需要做 Session 共享，通常用 Redis 集中存储。Token 是无状态的认证方式，最典型的是 JWT，它将用户信息编码在 Token 本身中，服务端只需要验签不需要存储状态，天然支持分布式。但 JWT 的缺点是无法主动注销，只能等过期，且 Token 体积比 SessionID 大。实际选型上，传统单体应用用 Session，微服务和前后端分离架构用 JWT Token 更合适。

追问与易错

追问方向：

“Token 存在哪里？LocalStorage 还是 Cookie？”→ 推荐存 httpOnly Cookie 防 XSS，存 localStorage 方便但可被 JS 读取有 XSS 风险
“JWT 能做到注销吗？”→ JWT 本身无法主动注销（无状态），变通方案：短过期时间 + 服务端维护黑名单（Redis 存已注销的 Token）
“CSRF 和 XSS 分别怎么防？”→ CSRF 用 CSRF Token + SameSite Cookie；XSS 用输出转义 + CSP + httpOnly Cookie 防止脚本窃取

易错点：

❌ Token 比 Cookie 更安全——取决于存储和传输方式
❌ Session 已经过时了——微服务场景仍广泛使用

Cookie-Session-Token区别#

一句话答案#