面试官：既然 JWT 这么好，为什么大厂还在用 Session？
面试官问："现在都 2026 年了，登录鉴权是不是该全切到 JWT 了？" 很多人会不假思索地点头："当然！JWT 无状态、可扩展、跨域方便，Session 早该被淘汰了。" 如果你这么回答，恭喜你，掉坑里了。 这时候面试官通常会补一刀： 这一问，往往能把 90% 的候选人问懵。 这篇文章就来聊聊：为什么被吹上天的 JWT，在很多大厂的核心业务里，反而不如"老土"的 Session？ 在撕逼之前，先对齐一下概念。 Session 方案（类似于"会员卡 + 账本"）： JWT 方案（类似于"现金"）： 回到开头的面试题："怎么把旧的 JWT 立即作废？" 在 Session 方案里，这太简单了。 但在 JWT 方案里，服务器是不存状态的。 这时候你会想各种补救办法，但你会发现，每个办法都很尴尬： 那用户每 5 分钟就得重新登录一次？体验爆炸。 用户注销时，把这个 Token 记到 Redis 黑名单里。每次请求都查一下是不是在黑名单。 除了"无法废止"这个硬伤，JWT 还有几个隐性成本，大厂算得很精： Session 续签是无感的。只要你一直在操作，服务端就在 Redis 里顺手把你的过期时间往后延。 Session ID 只有 32 个字节。 JWT 里的信息是"快照"。 把 JWT 贬得一文不值也不对。存在即合理，JWT 在以下场景是绝杀： A 服务调 B 服务，不用维持长连接会话。发一个短期的 JWT，B 服务解密验证签名就知道是谁调的，效率极高。 比如"重置密码链接"、"邮箱验证链接"。 比如一些简单的工具类网站，没钱买 Redis，只想撸个单机版 Node.js，那 JWT 是真香。 简洁版（30 秒）： JWT 最大的优势是无状态，但也正是它的劣势。因为无状态，所以服务端无法主动废止 Token（比如用户改密、被盗号场景）。要解决这个问题通常需要引入 Redis 做黑名单，这就违背了 JWT 无状态的初衷。 相比之下，Session + Redis 方案虽然有状态，但能做到精细化的权限控制和实时踢人下线。对于复杂的 C 端业务，Session 的安全性和控制力更好；而 JWT 更适合微服务间的授权或一次性验证。 进阶版（1 分钟，带架构思考）： 技术选型没有银弹，只有取舍。 Session 的本质是"控制" ：服务端掌握绝对控制权，适合对安全性要求高、需要实时管理用户状态的场景（如电商、银行）。缺点是需要维护存储组件（Redis），有扩容成本。 JWT 的本质是"交换" ：用计算（CPU 验签）换存储（内存/Redis）。适合服务间通信，或者对即时性要求不高的应用。 如果很多大厂还在用 Session，往往是因为他们的基础设施（Redis 集群）已经足够强大，相比于 JWT 带来的"无法废止"风险，他们更愿意承担存储成本来换取绝对的安全控制权。 最后总结一句： ⚡️ 别把时间浪费在低效复习上 很多人复习抓不住重点。作为过来人，我分析了100+份大厂面试记录，将 Go/Java/AI 的核心考察点、高频题、易错点 浓缩进了一份 PDF。 不搞虚的，全是干货。 加我微信：wangzhongyang2025，备注 【面经】 免费发你，立即纠正你的复习方向，把时间用在刀刃上。
"那如果用户手机丢了，或者改了密码，你怎么把旧的 JWT 立即作废？"看懂本质差异
sessionId（会员卡号）。sessionId_123 => { user_id: 1, role: 'admin' }。{ user_id: 1, role: 'admin', expire: '2027-01-01' }。JWT 的致命死穴：我想封杀你，但做不到
你手机丢了？客服后台点一下"下线"，服务端把 Redis 里的 sessionId 删了。下次那个手机再发请求，查不到记录，直接拒绝。秒级生效。
Token 发出去了，就像泼出去的水。只要还在有效期内（比如 2 小时），哪怕你把服务器重启了、把用户密码改了，拿着旧 Token 的黑客依然能畅通无阻。1. "那我把过期时间设短点？比如 5 分钟？"
你说搞个 Refresh Token 自动续期？那 Refresh Token 也是 Token，它不需要作废吗？如果 Refresh Token 被偷了，黑客能无限续杯，岂不是更危险？2. "那搞个黑名单（Blacklist）？"
打脸时刻：兄弟，你既然都要查 Redis 了，为什么不直接用 Session？
JWT 的最大优势就是"无状态、不查库"，你现在每秒几万次请求都要查黑名单，那 JWT 的性能优势还在哪？为什么大厂（特别是金融/支付）偏爱 Session？
1. 续签（Renewal）问题
JWT 里的过期时间是写死在 Payload 里的。想续签？必须发一个新的 JWT 给你。前端得写一堆拦截器逻辑：发现快过期了 -> 拿着旧 Token 换新 Token -> 重发请求。复杂度的天平，从后端倾斜到了前端。2. 带宽占用
一个包含基本信息的 JWT，动不动就几百个字节。如果你的 Token 放在 Header 里，每次 HTTP 请求都要多带几百字节的数据。对于像淘宝、微信这种亿级流量的入口，光是这多出来的流量成本就是一笔巨款。3. 数据实时性
你刚登录时是普通会员，生成了 JWT。下一秒你充钱成了 VIP。
但你手里的 JWT 写的还是"普通会员"。除非你重新登录，或者服务端在验证 Token 后再查一次库（又回到了查库的老路），否则你的 VIP 权益无法即时生效。
Session 每次都查 Redis，天然保证数据是最新的。那 JWT 到底有什么用？
1. 微服务/服务间调用（Machine-to-Machine）
2. 单次授权 Token
发一个 JWT 放在 URL 里，有效期 10 分钟。用户点开，验签通过，准许改密码。用完即废，不需要维持状态。3. 不想/不能做服务端存储
面试怎么答？
不要为了用新技术而用新技术。如果你的业务需要"此时此刻把这个讨厌的用户踢出去"，请老老实实拥抱 Session。