阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 mp.weixin.qq.com/s?__biz=MzU4MDUyMDQyNQ==&mid=2247568776&idx=2&sn=efc82aeff1aba18b657098b57e817f37&poc_token=HLu6vmmjsrzUZDpnTuHDCz0J1XocVeLpPJrl4lSB 「null」欢迎转载，保留摘要，谢谢！

• 一句话先说清楚
• Cookie：浏览器里的小纸条
• Session：服务端的记事本
• Token：自带身份证的通行证
• 三者对比
• 面试高频追问

---

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

这道题面试出现频率极高，但大多数回答要么只能说出”Cookie 在客户端、Session 在服务端”就卡住了，要么把三者的关系搅成一锅粥。核心在于搞清楚它们不在同一个维度上——Cookie 是存储/传输机制，Session 是服务端状态管理，Token 是无状态认证方案。

一句话先说清楚

Cookie = 浏览器存的小数据片段，每次请求自动带上；Session = 服务端存的会话状态，靠 Cookie 里的 SessionID 关联；Token（JWT）= 自包含的身份凭证，服务端不存状态，验签即可。

维度	Cookie	Session	Token（JWT）
存哪	浏览器	服务器（内存/Redis）	客户端（localStorage/Cookie）
有状态？	无	有（服务端要存）	无（自包含）
安全性	较低（明文、易窃取）	较高（数据在服务端）	较高（签名防篡改）
跨域	受同源策略限制	需额外处理	天然支持
分布式	—	差（需共享 Session）	好（无状态）
移动端	不友好	不友好	友好

选型口诀：单体小系统 → Session + Cookie；分布式/微服务 → Token；移动端/跨域 → 必须 Token。

Cookie：浏览器里的小纸条

流程很简单：① 浏览器首次请求，没有 Cookie；② 服务器通过 Set-Cookie 响应头写入；③ 浏览器存下来；④ 之后每次请求自动带上。

关键属性：

属性	干什么
HttpOnly	禁止 JS 读取，防 XSS
Secure	仅 HTTPS 传输
SameSite	跨站限制，防 CSRF
Max-Age	过期时间
Domain/Path	作用范围

局限：单个最大 4KB、每域最多约 20 个、明文存储、每次请求都带增加流量。

Session：服务端的记事本

① 用户登录，服务器创建 Session 对象，生成唯一 SessionID；② 通过 Set-Cookie 把 SessionID 返给浏览器（Java 里叫 JSESSIONID）；③ 后续请求自动带上这个 Cookie；④ 服务器根据 SessionID 查到对应的用户状态。

本质上 Session 依赖 Cookie 来传递 SessionID——Cookie 是”信封”，SessionID 是”信”，Session 是服务端的”档案柜”。

分布式环境下 Session 最头疼的就是共享问题：

方案	优劣
粘性 Session	简单，但负载不均、单点故障
Session 复制	同步开销大，不推荐
Redis 集中存储	推荐，快且支持分布式
数据库	持久化好，性能差

Token：自带身份证的通行证

① 用户登录，服务器用密钥生成 JWT 返回；② 客户端存在 localStorage 或 Cookie 里；③ 后续请求在 Authorization: Bearer <token> 头里带上；④ 服务器验签即可，不查任何存储。

JWT 三段结构（用 . 分隔）：

• Header：算法 + 类型（HS256 / JWT）
• Payload：用户数据（用户ID、角色、过期时间等），Base64 编码不是加密，别放敏感信息
• Signature：对前两段签名，防篡改，客户端无法伪造

优势：无状态、跨域友好、移动端适配、不需要 Session 存储。

硬伤：签发后无法主动失效——不像 Session 可以直接删。

三者对比

面试高频追问

Q1：Token 泄露了怎么办？

三种方案：

• 黑名单：失效 Token 存 Redis，验证时检查。缺点是引入了状态。
• 短有效期 + Refresh Token：Access Token 15 分钟过期，Refresh Token 7 天。踢人时让 Refresh Token 失效。
• 版本号：Token 里带版本号，改密码/踢人时更新版本号，验证时比对。

Q2：JWT 存 Cookie 还是 localStorage？

方案	优点	风险
Cookie + HttpOnly + SameSite	防 XSS	需防 CSRF
localStorage	灵活、无大小限制	XSS 可窃取

Web 端推荐 Cookie + HttpOnly；移动端存本地存储。

Q3：Session 和 Cookie 什么关系？

Session 依赖 Cookie 来传递 SessionID（也可以 URL 重写，但几乎没人用）。Cookie 是传输层，Session 是服务端存储层。

Q4：为什么分布式系统不用 Session？

Session 是有状态的——用户状态存在服务器上，集群环境下要么 Session 复制（开销大），要么粘性路由（负载不均），要么集中存储（多一层依赖）。Token 天然无状态，加机器就行。