05 - 两条路线怎么选：对比与决策

前两章把 Session 和 JWT 两条路线讲透了。这一章把它们摆在一起正面 PK，帮你在真实项目里做选择。

先给结论，免得你看完一堆对比还是拿不定主意：

绝大多数普通 Web 项目，Session（存 Redis）就是最省心的选择。 JWT 真正的主场是：多端（App/小程序）、跨服务、以及不方便用 Cookie 的场景。 很多成熟系统其实是两者混用——这才是高手的做法。

一张核心对比表

用一句话记住核心权衡

整张表其实就是一个此消彼长的权衡：

Session：状态放服务端
    → 服务端"管得住"（好退出、好踢人、好控制）
    → 但服务端"背负担"（要存储、要共享、扩展麻烦一点）

JWT：状态放客户端
    → 服务端"很轻松"（不存储、好扩展、多端友好）
    → 但服务端"管不住"（发出去的证收不回，退出登录头疼）

“管得住” vs “很轻松”，这就是两条路线的灵魂差异。 你要哪个，取决于你的场景更看重什么。

一个简单的选择流程

你的系统是什么样？
        │
        ├─ 纯浏览器访问的传统 Web（管理后台、内部系统、普通网站）
        │      → 用 Session + Redis，简单可控，别折腾 JWT
        │
        ├─ 主要是 App / 小程序 / 前后端完全分离、还可能跨域
        │      → 用 JWT，放请求头，多端统一
        │
        ├─ 微服务架构，请求要在多个服务间流转
        │      → 倾向 JWT（每个服务能独立验签，不必都去查同一个 Session 库）
        │
        └─ 又要 JWT 的扩展性、又要能随时踢人下线
               → 两者混用：JWT 做无状态验证 + Redis 存一份"黑名单/在线表"兜底
                 （鱼和熊掌兼得，但复杂度上升，见第 07、09 章）

为什么说”混用才是常态”

你可能会想：“既然 JWT 退出难，那我加个 Redis 黑名单不就行了？” ——对，这正是很多大厂的真实做法。但请意识到一件事：

一旦你给 JWT 配了 Redis（黑名单 / 在线状态）
        │
        ▼
它就不再是"纯无状态"了——每次请求又要查一次 Redis
        │
        ▼
你其实是在"用 JWT 的形式，做了一部分 Session 的事"

这不是坏事，反而说明：没有银弹，只有权衡。你是在”扩展性”和”控制力”之间，按业务需要调一个平衡点。理解了这一点，你就不会陷入”到底哪个更好”的无谓争论——答案永远是”看场景”。

一个常见误区，务必避开

❌ 误区：“JWT 更先进/更安全，所以我应该抛弃 Session 全用 JWT。”

这是新手最容易犯的错。JWT 不是 Session 的升级版，它们是两种权衡不同的方案。盲目上 JWT 的人，往往会在”用户改密码后旧 token 还能用""退出登录后 token 还有效""要强制某人下线却做不到”这些问题上栽跟头（全是第 07 章的内容）。

如果你只是做一个普通的、浏览器访问的系统，Session + Redis 往往是更稳、更省心的选择。 不要为了”显得高级”而给自己挖坑。

小结

• 核心权衡一句话：Session 让服务端”管得住”，JWT 让服务端”很轻松”。
• 普通浏览器 Web → Session + Redis；App/小程序/跨域/微服务 → JWT。
• 想兼得扩展性和控制力 → 混用（JWT + Redis 黑名单），代价是复杂度上升，且不再纯无状态。
• 别信”JWT 更先进”这种话，没有银弹，只有场景。
• 选型的关键问题就一个：你的业务更需要”控制力”还是”扩展性/多端友好”？

理论部分到此结束。下一章我们进入最精彩的实战篇——把前面所有零件串起来，完整地”放一遍电影”：一个用户从登录到退出，服务端到底经历了什么。

上一章 ← 04 - 路线 B：Token + JWT ｜ 下一章 → 06 - 完整例子：一次登录到退出的旅程 ｜ 回到 README 目录