无标题文档
来源：无标题文档
（开头镜头：手持白板笔，面对PPT封面，表情夸张）
家人们！有没有面试时被问JWT注销失效，直接卡壳的？🙋♂️** 上周我粉丝面试字节，面试官一句“为什么JWT注销后还能访问接口”，他直接懵了！今天花5分钟，从问题本质到4种落地方案，讲得明明白白，面试能吹，项目能用，结尾还送PPT和详细文章！**
（转场：点击PPT第2页，手指指向“冲突本质”）
先搞懂核心坑：为啥JWT注销了还能用？很简单！JWT验证只看俩事儿——签名对不对、有没有过期，根本不管你是不是注销了！就像电影票，只要没过期、是真票，检票员就放行，不管你是不是转卖的～ 这就是无状态的双刃剑！
（转场：翻到黑名单方案页，画个红圈）
那咋解决？先给中小规模的同学上福利——黑名单机制！就像公司门禁，员工离职了，把工牌号拉进黑名单，下次刷就不好使了～ 注销时把Token存Redis，接口请求时先查黑名单，实现简单，成本超低，QPS1万以内闭眼用！
（转场：滑动到双Token页，手势比划“两个”）
但如果是高并发、分布式系统，查黑名单太慢咋办？别急！双Token机制来救场～ 一个短期访问令牌（5分钟），一个长期刷新令牌（7天）！访问令牌过期了，用刷新令牌换新手牌，注销时直接删了刷新令牌，旧牌过期自动失效，性能直接拉满！
（转场：点击微服务方案页，表情严肃）
如果是大规模微服务，几十上百个服务咋统一管理？第三个方案：令牌撤销中心！就像小区物业总部，不管哪个楼栋要禁用门禁，统一报给总部，所有大门同步生效～ 支持批量封号、跨服务协同，QPS5万以上闭眼冲！
（转场：翻到自定义声明页，手指点版本号）
还有批量失效场景！比如公司裁员、平台封号，要一次性禁用一批账号咋办？自定义声明安排！给每个用户加个“版本号”，注销时版本号+1，旧Token的版本对不上，直接拒绝访问，一键禁用，操作贼简单！
（转场：回到总结页，手持表格）
最后划重点！记不住复杂的，就看这张表：中小规模用黑名单，高并发用双Token，微服务用撤销中心，批量失效用自定义声明～ 核心就是：JWT不管业务状态，我们加个“业务开关”就行！
（结尾镜头：凑近镜头，手势比心）
想要这份PPT完整版+详细实现代码的同学，评论区扣“JWT”，我直接私发给你！🙌** 关注我，下期讲Redis缓存穿透解决方案，面试又多一个加分项！咱们评论区见～**