面试官：既然 JWT 这么好，为什么大厂还在用 Session？

面试官问："现在都 2026 年了，登录鉴权是不是该全切到 JWT 了？"

很多人会不假思索地点头："当然！JWT 无状态、可扩展、跨域方便，Session 早该被淘汰了。"

如果你这么回答，恭喜你，掉坑里了。

这时候面试官通常会补一刀："那如果用户手机丢了，或者改了密码，你怎么把旧的 JWT 立即作废？"

这一问，往往能把 90% 的候选人问懵。

这篇文章就来聊聊：为什么被吹上天的 JWT，在很多大厂的核心业务里，反而不如"老土"的 Session？

看懂本质差异

在撕逼之前，先对齐一下概念。

Session 方案（类似于"会员卡 + 账本"）：

1. 用户登录，服务端给一个 sessionId（会员卡号）。
2. 服务端在 Redis 或内存里存一份记录（账本）：sessionId_123 => { user_id: 1, role: 'admin' }。
3. 每次请求，服务端查账本，确认有效才放行。
4. 核心特点：服务端有状态（Stateful），控制权在服务端。

JWT 方案（类似于"现金"）：

1. 用户登录，服务端根据用户信息生成一串加密字符串（钞票）。
2. 钞票上写着：{ user_id: 1, role: 'admin', expire: '2027-01-01' }。
3. 服务端不存记录，只负责发钱和验钞。
4. 每次请求，服务端解密验钞，没过期就是真的。
5. 核心特点：服务端无状态（Stateless），控制权在客户端（只要没过期，就能用）。

JWT 的致命死穴：我想封杀你，但做不到

回到开头的面试题："怎么把旧的 JWT 立即作废？"

在 Session 方案里，这太简单了。 你手机丢了？客服后台点一下"下线"，服务端把 Redis 里的 sessionId 删了。下次那个手机再发请求，查不到记录，直接拒绝。秒级生效。

但在 JWT 方案里，服务器是不存状态的。 Token 发出去了，就像泼出去的水。只要还在有效期内（比如 2 小时），哪怕你把服务器重启了、把用户密码改了，拿着旧 Token 的黑客依然能畅通无阻。

这时候你会想各种补救办法，但你会发现，每个办法都很尴尬：

1. "那我把过期时间设短点？比如 5 分钟？"

那用户每 5 分钟就得重新登录一次？体验爆炸。 你说搞个 Refresh Token 自动续期？那 Refresh Token 也是 Token，它不需要作废吗？如果 Refresh Token 被偷了，黑客能无限续杯，岂不是更危险？

2. "那搞个黑名单（Blacklist）？"

用户注销时，把这个 Token 记到 Redis 黑名单里。每次请求都查一下是不是在黑名单。打脸时刻：兄弟，你既然都要查 Redis 了，为什么不直接用 Session？ JWT 的最大优势就是"无状态、不查库"，你现在每秒几万次请求都要查黑名单，那 JWT 的性能优势还在哪？

为什么大厂（特别是金融/支付）偏爱 Session？

除了"无法废止"这个硬伤，JWT 还有几个隐性成本，大厂算得很精：

1. 续签（Renewal）问题

Session 续签是无感的。只要你一直在操作，服务端就在 Redis 里顺手把你的过期时间往后延。 JWT 里的过期时间是写死在 Payload 里的。想续签？必须发一个新的 JWT 给你。前端得写一堆拦截器逻辑：发现快过期了 -> 拿着旧 Token 换新 Token -> 重发请求。复杂度的天平，从后端倾斜到了前端。

2. 带宽占用

Session ID 只有 32 个字节。 一个包含基本信息的 JWT，动不动就几百个字节。如果你的 Token 放在 Header 里，每次 HTTP 请求都要多带几百字节的数据。对于像淘宝、微信这种亿级流量的入口，光是这多出来的流量成本就是一笔巨款。

3. 数据实时性

JWT 里的信息是"快照"。 你刚登录时是普通会员，生成了 JWT。下一秒你充钱成了 VIP。 但你手里的 JWT 写的还是"普通会员"。除非你重新登录，或者服务端在验证 Token 后再查一次库（又回到了查库的老路），否则你的 VIP 权益无法即时生效。 Session 每次都查 Redis，天然保证数据是最新的。

那 JWT 到底有什么用？

把 JWT 贬得一文不值也不对。存在即合理，JWT 在以下场景是绝杀：

1. 微服务/服务间调用（Machine-to-Machine）

A 服务调 B 服务，不用维持长连接会话。发一个短期的 JWT，B 服务解密验证签名就知道是谁调的，效率极高。

2. 单次授权 Token

比如"重置密码链接"、"邮箱验证链接"。 发一个 JWT 放在 URL 里，有效期 10 分钟。用户点开，验签通过，准许改密码。用完即废，不需要维持状态。

3. 不想/不能做服务端存储

比如一些简单的工具类网站，没钱买 Redis，只想撸个单机版 Node.js，那 JWT 是真香。

面试怎么答？

简洁版（30 秒）：

JWT 最大的优势是无状态，但也正是它的劣势。因为无状态，所以服务端无法主动废止 Token（比如用户改密、被盗号场景）。要解决这个问题通常需要引入 Redis 做黑名单，这就违背了 JWT 无状态的初衷。 相比之下，Session + Redis 方案虽然有状态，但能做到精细化的权限控制和实时踢人下线。对于复杂的 C 端业务，Session 的安全性和控制力更好；而 JWT 更适合微服务间的授权或一次性验证。

进阶版（1 分钟，带架构思考）：

技术选型没有银弹，只有取舍。 Session 的本质是"控制" ：服务端掌握绝对控制权，适合对安全性要求高、需要实时管理用户状态的场景（如电商、银行）。缺点是需要维护存储组件（Redis），有扩容成本。 JWT 的本质是"交换" ：用计算（CPU 验签）换存储（内存/Redis）。适合服务间通信，或者对即时性要求不高的应用。 如果很多大厂还在用 Session，往往是因为他们的基础设施（Redis 集群）已经足够强大，相比于 JWT 带来的"无法废止"风险，他们更愿意承担存储成本来换取绝对的安全控制权。

最后总结一句：不要为了用新技术而用新技术。如果你的业务需要"此时此刻把这个讨厌的用户踢出去"，请老老实实拥抱 Session。