Session vs JWT：架构选型终极指南

这是面试和架构设计中最经典的问题。为了能一眼看懂，这里将它们的区别总结为 “核心逻辑”、“优缺点对比” 和 “选型建议” 三个部分。

一、 核心逻辑的区别（一句话总结）

• Session (引用传递)：“数据在服务端，你只拿个号。”
  • 浏览器拿着 Session ID（钥匙），去服务器的 内存/数据库（柜子）里查数据。
  • 核心特点： 有状态（Stateful）。
• JWT (值传递)：“数据在你手上，我只负责验真伪。”
  • 浏览器拿着 JWT（写满信息的工牌），服务器 不查数据库，只用 密钥 验算一下签名（盖章）是不是真的。
  • 核心特点： 无状态（Stateless）。

二、 详细对比表（建议收藏）

三、 深度解析：三大“痛点”抉择

1. 分布式扩展性（JWT 的杀手锏）

• Session 的痛： 如果你有 100 台服务器，用户连到服务器 A 登录了，下次连到服务器 B，B 不认识他。必须搞一个 Redis 集群来存放所有人的 Session，增加了系统复杂度。
• JWT 的爽： 100 台服务器都不用存数据，只要它们手里拿着**“同一把密钥”**。用户拿着 JWT 找谁都能验证通过。微服务架构首选 JWT。

2. “踢人”与撤销（Session 的杀手锏）

• 场景： 用户手机丢了，想强制退出登录；或者管理员想封禁违规账号。
• Session： 管理员在服务器删掉这个人的 Session 记录。下一秒骗子拿着手机刷新页面，直接报错“请登录”。秒级生效。
• JWT： 无能为力。因为 JWT 发出去就像**“覆水难收”**。只要 JWT 还没过期（比如设置了 7 天），骗子就能一直用。
  • 补救办法： 搞个“黑名单”存 Redis（这又变回 Session 模式了，尴尬）。

3. 数据隐私

• Session： 数据在服务器保险箱里，非常安全。
• JWT： 数据（Payload）只是 Base64 编码，没有加密！ 任何人拿到 JWT 都能解码看到里面的内容（比如用户 ID、昵称）。千万不能在 JWT 里放密码或敏感信息。

四、 总结与选型建议

1. 什么时候用 Session？

• 传统单体应用（如企业内部管理系统，OA）。
• 对安全性要求极高（如银行、金融系统），必须能实时封号。
• 用户量不大，且没有大量的移动端/小程序需求。

2. 什么时候用 JWT？

• 微服务架构（服务特别多，统一认证中心）。
• 移动端 APP、小程序、单页应用 (SPA)（前后端分离）。
• 需要单点登录 (SSO) 的场景。