Cookie-Session-Token区别#

关系：

• 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）

浏览器现状（2026）：

• Chrome/Edge 对未声明 SameSite 的 Cookie 默认按 Lax 处理（Firefox、Safari 未默认 Lax，所以要显式声明）；SameSite=None 必须同时带 Secure。
• 第三方 Cookie：Safari、Firefox 默认拦截；Chrome 2025 年已放弃淘汰计划和独立选择弹窗，默认仍允许（无痕模式默认拦截），用户可在设置里关闭。依赖第三方 Cookie 的跨站登录方案不可靠。

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 + HttpOnly Cookie 依然简单可靠（可随时注销）；JWT 更适合跨服务传递身份、移动端/开放平台 API 这类不方便用 Cookie 或需要无状态校验的场景，常见做法是短期 Access Token + 可吊销的 Refresh Token。

追问方向：

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

易错点：

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