来自：

推荐一个程序员编程资料站：

http://cxyroad.com

副业赚钱专栏：https://xbt100.top

2024年IDEA最新激活方法

后台回复：激活码

CSDN免登录复制代码插件下载：

CSDN复制插件

以下是正文。

---

大家好，我是小路。

最近在技术社区看到一个挺经典的问题：

面试的时候说 Token 放 Redis，被面试官嘲笑不懂 JWT，该怎么回应？

这个问题之所以经常吵起来，本质不是技术对错，而是“你站在架构哪一层在说话”。

01 | 面试官在问“理念”，你在说“工程”

很多争论一开始就不在一个频道上。

面试官说 JWT 是无状态，你为什么还要用 Redis？

听起来是在聊架构优雅性，本质是在考你对设计理念的理解。

但实际落地工程里，问题往往不是“优不优雅”，而是：

这个用户能不能被踢下线
这个 token 能不能立刻失效
这个账号被封了系统怎么处理

如果你只讲“无状态”，那确实很漂亮。

但系统一旦进入真实业务，状态这个东西是绕不开的。

02 | JWT的理想很丰满，现实是“无法撤回”

JWT的核心卖点是无状态。

服务端不存 session，token 自带信息，验证签名即可。

听起来很完美。

问题是：它有一个致命特性。

一旦签发，无法主动失效。

比如：

用户密码被盗
管理员封号
用户点击退出登录
多端登录互踢

这些在真实系统里都是高频需求。

但纯 JWT 的逻辑是：

发出去就只能等过期。

这在产品语境里基本等于不可接受。

03 | Redis存在的意义，不是“存Token”，而是“控制状态”

很多人被嘲笑的点，其实是误解了一件事：

Redis不是在替代 JWT，而是在补 JWT缺失的那一块能力。

比如：

踢人下线
黑名单机制
登录状态管理
多端登录控制
滑动过期

这些本质都是“状态管理”。

而 Redis 做的事情很简单：

给无状态系统补一个状态层。

04 | 真正的工程解法，从来不是二选一

现实系统里，JWT 和 Redis 通常不是对立关系，而是组合关系。

常见结构是：

JWT负责身份携带
Redis负责状态控制

比如：

JWT里存 userId + 签名
Redis里存 token 状态或 tokenId

请求来了：

先验签 JWT
再查 Redis 判断是否被吊销

这样做的核心不是“优雅”，而是“可控”。

05 | 面试里最容易翻车的点：把设计当教条

很多人被怼，其实不是技术不行，而是表达方式太“教科书”。

比如只说：

JWT是无状态，所以不需要Redis

这句话在理论上没错，但在工程上是缺了一半。

更成熟的表达应该是：

JWT适合做身份传递
Redis适合做状态管理
实际系统通常会结合使用

面试官真正想听的，是你有没有意识到：

系统设计永远是在权衡，而不是在背概念。

06 | 为什么“存Redis”在真实项目里很常见

回到工程现实，会发现一个很简单的事实：

只要系统有“控制用户状态”的需求，就离不开某种中心存储。

Redis只是最常见的一种实现方式。

因为它满足几个关键条件：

访问快
支持TTL
支持分布式
易做黑名单

你可以不用Redis，但你一定要有“状态中心”。

否则系统就会变成：

发出去的token，收不回来。

07 | 面试的正确打开方式：不是反驳，是对齐问题

如果在面试中遇到类似问题，最好的方式不是对抗，而是拆解场景。

可以这样说：

如果系统只需要身份认证，不需要踢人、不需要控制登录状态，那JWT完全可以独立使用。

但如果涉及账号安全、权限控制、强制失效等能力，就必须引入状态存储，比如Redis。

然后再补一句关键点：

所以我们选择的不是JWT vs Redis，而是组合方案。

这句话基本就能把层次拉回来。

08 | 取舍

很多技术争论，看起来是在争对错，其实是在争前提条件。

JWT不是高级，Redis也不是低级。

一个解决“怎么不存状态”，一个解决“怎么控制状态”。

现实系统永远是在两者之间找平衡。

面试官真正想看的，不是你站哪一边，而是你有没有意识到：

架构从来不是选边站，而是做取舍。

<END>

推荐阅读：

副业赚钱推荐：让你的时间开始变现！

免费体验AI图片生成，就在 Image Generator Hub！

程序员在线工具站：cxytools.com
推荐一个自己写的工具站：https://cxytools.com，专为程序员设计，包括时间日期、
JSON处理、SQL格式化、随机字符串生成、UUID生成、文本Hash...等功能，提升开发效
率。
⬇戳阅读原文直达！                                  朕已阅