1. 项目概述JWT到底是什么为什么绕不开它做Web开发的人都绕不开登录状态管理这道坎而JWTJSON Web Token几乎已经成了现代前后端分离项目里最通用的解决方案。从我个人的一线开发经验看只要接触过SPA单页面应用、移动端App或者分布式微服务架构JWT基本是逃不掉的基础设施。它解决的痛点非常直白HTTP协议本身是无状态的每次请求都是独立的那服务器怎么知道当前请求是哪个用户发来的传统做法是服务端存Session通过Cookie带Session ID来识别但这种方式在前后端分离、多端登录、水平扩容的场景下会有不少麻烦。JWT的思路则是把用户身份信息经过签名后直接发给客户端后续请求带着这个令牌服务端验签通过就信任它不需要在服务端保存任何会话状态。在实际项目里JWT最常见的落地场景包括用户登录成功后签发令牌、SPA项目里配合验证码完成登录认证、token过期后的自动续签机制、第三方单点登录体系等。它本质上是一个经过签名、可验真、自带过期时间的JSON数据包既可以用在认证场景也可以用于信息交换。我经常用一个生活化的类比来解释这个概念JWT就像一张游乐园的入场手环戴上手环后你可以在园区内自由玩项目工作人员检查手环的防伪标记签名和有效期即可放行不需要每次进项目都去中央系统查你的购票记录。手环上还印着你的基本信息比如是普通游客还是VIP。这篇文章我会从一个实干者的角度把JWT从原理到实战拆开讲清楚包括标准结构的每一段字段含义、登录验证流程怎么落地、token续签怎么做、主流Java和JavaScript生态里怎么选库、以及网上整理出的常见漏洞和防御姿势。不管你是刚入门想搞懂原理的新手还是被线上token问题折磨得头疼的开发者都可以按需跳读。2. JWT结构深度拆解三段字符串背后的设计逻辑2.1 Header、Payload、Signature三段各管什么事一个标准的JWT长这样eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c它用两个点分成三段分别是Header、Payload和Signature。很多人第一次看到这串东西会发懵其实每段都是Base64Url编码后的JSON可以用工具直接解出来看内容并不神秘。Header里一般声明了两件事签名算法和令牌类型。最常用的算法就是HS256对称签名和RS256非对称签名。算法字段很关键后面讲漏洞时会提到算法类型直接决定了验签方式。Payload是承载业务声明的地方官方预留了iss签发者、sub面向的用户、aud接收方、exp过期时间、nbf生效时间、iat签发时间等字段名。除了这些注册声明你也可以放任何自定义数据比如用户ID、角色、昵称等但要注意Payload只是Base64编码不是加密里面任何信息都是透明的绝对不能塞密码、手机号、身份证这类敏感数据。Signature的计算逻辑是将前两段Base64Url内容用点拼起来再用Header里声明的算法配合密钥或私钥做签名。以HS256为例公式是HMAC-SHA256(base64Url(header) . base64Url(payload), secret)。这个签名的作用就是防篡改只要Token里的数据被改了一个字符签名立刻校验失败。2.2 为什么JWT选择Base64Url编码而不是普通Base64这是很多教程不会专门讲的细节但理解了它你对JWT的兼容性设计就通透了。标准Base64编码的结果里可能包含、/、这三种字符在URL参数里它们有特殊含义可能被解码成空格/会改变路径语义在某些框架里会被截断。JWT通常放在HTTP Header的Authorization字段或者URL查询参数里传为了避免这类问题JWT采用了Base64Url变体把替换成-把/替换成_去掉末尾的补齐符。这个设计看着不起眼实际在对接各类网关、代理和日志系统时能省掉一堆转义纠纷。另外需要强调一个面试常踩的坑JWT里的Payload虽然用Base64Url编过码但它跟加密完全是两码事。Base64是一种编码方式是可逆的任何人都能在线解码看到内容。网上有些项目直接把用户密码、密钥或者内部接口地址放进Payload这等于把家钥匙挂在门口。我在代码评审时就见过真实案例某团队把用户的手机号和邮箱明文塞到JWT里做快速展示结果被抓包工具一解码隐私数据全裸奔了。正确做法是Payload里只放不会泄露敏感信息的标识比如用户ID、角色代码需要额外数据时用单独的用户信息查询接口去拿。2.3 签名算法选型HS256和RS256到底怎么权衡算法选择直接关系到系统的安全边界很多事故就是因为选了不合适的算法。HS256是对称签名签发和校验用的是同一个密钥。它的优点是实现简单、性能好适合内部系统、前后端由同一团队把控的单体应用。缺点是密钥一旦泄漏攻击者可以自己伪造任意身份的Token而且在多个服务间做认证时所有服务都得共享同一个密钥密钥的分发和管理会变成安全隐患。RS256是非对称签名用私钥签发、公钥验签。它的优势是服务端只需要保管私钥各业务服务只要拿到公钥就能校验Token适合微服务架构和跨系统认证的场景。私钥泄漏风险更低因为公钥随便分发也没关系。代价是签名和验签的计算开销更大实现时还需要管理密钥对的生命周期。以我多年的项目经验只要是微服务架构直接选RS256如果是小程序单体应用、内部管理后台HS256也够用。但无论选哪种密钥长度必须达标HS256的密钥最好用32字节以上的随机串RS256的私钥至少2048位不要为图省事用短密钥。3. 从0到1实现JWT登录验证与令牌管理3.1 完整登录接口验证码校验、用户认证、令牌签发的标准流程对应热搜词里的“SPA项目开发之jwt验证码实现”和“jwt实现token登录验证”这里我把一个标准的登录链路完整写出来。我的习惯是先把流程画成一条线前端输入账号密码和图形验证码 - 后端先校验验证码 - 再查用户表比对密码 - 通过后签发JWT - 返回给前端保存 - 前端后续请求自动携带。验证码这一步为什么要放在用户认证之前因为验证码的核心价值是防暴力破解和批量撞库。如果先查用户再校验验证码攻击者可以通过报错差异判断账号是否存在而且验证码的校验应该在消耗任何数据库查询资源之前完成能挡住大批自动化请求。我负责过的实际项目中验证码通常存储方式有两种单体项目放Rediskey为captcha:{uuid}值为验证码文本5分钟过期简单的内部项目也可以放内存但集群环境下会有节点不一致问题不推荐。密码校验原则是绝不能存明文也不建议自己发明哈希算法。推荐用BCrypt这类带盐的慢哈希算法校验时用bcrypt.compare(plainPassword, encryptedPassword)进行。这里顺带提醒一句上线项目如果还在用MD5加盐的方式存密码应该尽快迁到BCrypt或Argon2。用户认证通过后签发JWT这个环节有几个参数需要认真设计。标准做法中我一般这么设置过期时间exp普通Web管理后台30分钟到2小时就够如果业务要求长时间保持登录可以配合刷新令牌refresh token实现续期不是简单把token时间拉长。签发时间iat和生效时间nbfiat设为当前时间nbf可以稍微向后偏移一点比如5秒防止多节点时钟不一致导致刚签发就被认为无效。自定义声明放userId、role、tenantId这类用于权限判断的核心标识。注意不要放任何敏感信息。前端拿到Token后的存储策略也是一个老生常谈的争论点localStorage还是Cookie我的建议是如果项目对XSS防护没有十足把握优先用HttpOnly的Cookie存储。localStorage虽然用起来方便但只要页面被注入一段脚本Token就能被直接读走Cookie配合HttpOnly属性后JavaScript读取不到能挡住XSS窃取这一挂。缺点是CSRF防护需要额外处理但用SameSite和CSRF Token基本就能压住风险。3.2 服务端校验与刷新让JWT安全地在请求链路中流转Token签发之后服务端拦截器的常规动作是固定三板斧取Token、验签名、解Payload。取Token时注意从Authorization: Bearer token里剥离Bearer前缀有些前端会把Token放到自定义Header里也见过放URL参数里的做法但不推荐后者因为Token会出现在访问日志中增加泄漏面。验签阶段要防御的重点是算法混淆攻击这个我在后面漏洞部分会专门展开。解Payload后需要做的检查包括exp是否已过期、iss是否匹配、aud是否匹配、用户是否还在有效状态。如果系统里存在封号、踢人下线的需求只靠JWT本身是做不到实时封禁的因为JWT是无状态令牌签发后服务端就失去了召回能力。这时候有三个可选方案一是维护一个黑名单Redis Set存被吊销Token的jti拦截器查一下二是缩短Token寿命减少封禁延迟三是干脆别用JWT做登录态回到Session方案。每种方案各有取舍要根据业务容忍度决定。对应热搜词“jwt实现token续签”我介绍一下目前生产环境最常用的双Token续签机制。这个方案由一对Token组成Access Token负责实际访问资源过期时间短通常15分钟到2小时Refresh Token负责换新Access Token过期时间长7天到30天。当Access Token过期前端拿Refresh Token调刷新接口服务端验证Refresh Token合法后签发新的Access Token。设计时有个细节容易被忽略Refresh Token最好用独立的、更受限的存储和校验逻辑一般也要绑定用户设备和IP信息防止盗用。同时刷新接口要做“Refresh Token只能换一次”的业务约束以拦截重放攻击。如果不想引入双Token也可以用滑动续期Sliding Expiration策略每次请求只要Token剩余时间低于阈值比如不足一半就顺手签发一个新Token返回给前端。这种方案实现简单用户体验也好但缺点是每个低龄请求都会多一次签发开销而且频繁刷新会增加被截获后有效窗口拉长的风险。所以我的建议是安全性要求高的场景用双Token对体验流畅度要求高于安全要求的中后台内部系统可以用滑动续期。3.3 代码实操JavaSpring Boot与JavaScriptNode.js的落地示例Java生态里目前最主流的JWT库是java-jwtAuth0出品和jjwt。这里以Spring Boot 3 jjwt为例写一个最简可用的配置。先引入依赖然后封装一个JwtUtil组件。// 依赖io.jsonwebtoken:jjwt-api:0.11.5, jjwt-impl, jjwt-jackson Component public class JwtUtil { Value(${jwt.secret}) private String secret; Value(${jwt.expire-minutes}) private long expireMinutes; // 生成token public String generateToken(Long userId, String role) { Date now new Date(); Date expiry new Date(now.getTime() expireMinutes * 60 * 1000); return Jwts.builder() .setSubject(String.valueOf(userId)) .claim(role, role) .setIssuedAt(now) .setExpiration(expiry) .signWith(Keys.hmacShaKeyFor(secret.getBytes()), SignatureAlgorithm.HS256) .compact(); } // 解析token异常即非法 public Claims parseToken(String token) { return Jwts.parserBuilder() .setSigningKey(Keys.hmacShaKeyFor(secret.getBytes())) .build() .parseClaimsJws(token) .getBody(); } }这里有几个容易踩的坑signWith的密钥长度如果小于256位jjwt会直接抛异常所以HS256的密钥至少32个字符parseToken方法内部会校验签名和过期时间捕获ExpiredJwtException和JwtException时要区分处理前者走续签流程后者直接返回401。Spring Boot里的拦截器用OncePerRequestFilter或Spring Security的JwtAuthenticationFilter实现即可。核心逻辑是从Header取Token - 调parseToken- 把用户ID塞进SecurityContextHolder- 放行解析失败则直接拒绝。如果Controller里需要获取当前用户可以用AuthenticationPrincipal注入。Node.js生态中最常用的是jsonwebtoken包代码会更简洁一些。生成Token用jwt.sign(payload, secret, { expiresIn: 2h })校验用jwt.verify(token, secret)注意verify抛的错也要按TokenExpiredError和JsonWebTokenError分别处理。Express中间件的大致写法如下const jwt require(jsonwebtoken); function authMiddleware(req, res, next) { const header req.headers.authorization || ; const token header.startsWith(Bearer ) ? header.slice(7) : null; if (!token) return res.status(401).json({ code: 401, msg: 未登录 }); try { const payload jwt.verify(token, process.env.JWT_SECRET); req.user payload; next(); } catch (err) { if (err.name TokenExpiredError) { return res.status(401).json({ code: 401, msg: 登录已过期 }); } return res.status(401).json({ code: 401, msg: 无效Token }); } }无论用哪个语言实现有几个原则是通用的解析Token时不要把异常吞掉后放行每次请求不要重复做高开销的用户库查询优先信任Token里的声明Token里存了角色权限后修改用户角色的操作需要让旧Token失效否则权限变化有延迟生效窗口。4. JWT常见漏洞与攻击面总结这几个坑真的会出事4.1 算法混淆攻击、弱密钥爆破与敏感信息泄露对应热搜词“jwt漏洞总结”和“jwt漏洞”这节必须重点写。JWT的漏洞在网上被总结过很多轮我也在实际渗透测试中见过不少案例挑几个高发的详细分析。第一种是算法混淆攻击Algorithm Confusion原理非常致命。攻击者把Token里Header的alg字段从RS256改成HS256由于很多后端库验签时会信任Header声明的算法服务端就会拿着用于验签的RS256公钥当作HS256的对称密钥来做HMAC签名校验。因为公钥通常是公开的攻击者一旦拿到公钥就能用这个公钥作为HS256密钥伪造任意Token。防御方法很明确服务端验签时写死允许的算法白名单不要信任Header里的alg字段。在jjwt里可以通过parserBuilder().setSigningKey(publicKey)配合显式算法限制来规避。第二种是弱密钥爆破。如果HS256用的对称密钥是一段短字符串比如secret、123456攻击者可以拿到一个合法Token后使用hashcat配合常见密码字典暴力解出签名密钥。一旦密钥被还原等于整个认证体系失守。我之前见过一个线上事故开发图方便把密钥写成了jwt-secret-2023结果上线不到一个月Token就被伪造了。防御办法是使用足够长的随机密钥并定期轮换。第三种是敏感信息泄露。再次强调JWT的Payload是Base64编码的任何人解码即可看到全部内容。常见的错误是把密码、手机号、身份证、银行卡等数据塞进Token被前端console打印或者日志输出后隐患极大。正确姿势是Payload只保留最小必要信息其它数据通过接口按需查询。4.2 Token被盗与重放、过期校验缺失、日志泄漏与弱随机数实际业务中还经常遇到几类问题。第一类是Token被盗后的重放攻击。常见泄露渠道包括XSS脚本窃取、HTTPS降级或被中间人截获、前端源码里硬编码Token、Nginx等网关日志记录了带Token的URL。防御思路是多层叠加强制全站HTTPS、Cookie加HttpOnly和SameSite、敏感操作增加二次校验如支付时再输密码、以及缩短Access Token有效期。第二类是过期校验缺失。有些团队在解析Token时只验证签名不检查exp导致已过期的Token依然能访问系统。这类问题的隐蔽性在于接口响应正常但安全审计一查全是过期Token通过的记录。拦截器里必须在解析Claims后立刻检查exp标准库parser一般都会自带校验但如果你是自己拼Base64解码后再验签很容易漏掉这一步。第三类是弱随机数导致Token可预测。某些老版本库在没有指定安全随机数源的情况下生成的Token序列具有规律性。正常做法是使用标准库的默认安全随机源不要自己用Math.random()生成密钥或多因子值。第四类跟“更新用户登录信息并生成返回jwt令牌”这个热搜词相关用户修改密码、重置密码、踢人下线后旧Token依然有效。这是JWT无状态特性带来的天然痛点。业务上一定要处理的话可以在Redis里维护一个token_version:{userId}的版本号JWT的Payload里也带上这个版本号拦截器比对两者是否一致不一致就拒绝用户改密或踢人时递增版本号即可。这种方案本质上把无状态JWT变成了轻量状态化令牌以很小的代价换来了可控性。4.3 漏洞速查表每一种攻击的防御思路漏洞类型攻击方式核心防御措施算法混淆将alg从RS256篡改为HS256用公钥做对称密钥验签时固定算法白名单不信任Header声明弱密钥爆破用字典穷举HS256对称密钥至少32字节随机密钥定期轮换敏感信息泄露直接Base64解码Payload读取内容Token只放必要标识密文不入Token过期校验缺失使用过期Token访问接口统一拦截器强制校验exp异常分类处理Token重放盗取Token后重复使用HTTPS全覆盖、HttpOnly Cookie、短生命周期、敏感操作二次校验弱随机数预测Token生成规律使用安全随机数源生成密钥和Token用户状态变更后旧Token有效改密/封号后旧Token仍可访问Redis维护token_version或黑名单机制拦截器比对这条速查表建议截图保存。排查线上JWT安全问题的时候按表逐项过一遍基本能覆盖九成以上的隐患。5. 生产环境落地经验JWT 验证码 续签的完整实战5.1 一个真实项目的登录链路复盘我之前在一个中大型电商中台项目里负责认证模块改造正好把JWT验证码双Token续签串成了一个完整闭环。这里把当时的实施思路复盘出来你可以直接当模板参考。登录接口设计如下。前端调用POST /api/auth/login请求体为{ username: ..., password: ..., captchaCode: ..., captchaKey: ... }。服务端处理逻辑按顺序排列根据captchaKey从Redis取值比对captchaCode。不一致直接返回1002 验证码错误同时删除该验证码防止暴力重试。根据用户名查用户表。账号不存在返回统一错误文案不要明确说“用户不存在”避免被撞库利用。校验密码。用BCrypt比对失败则记录失败次数超过阈值后该账号临时锁定15分钟。查询用户状态被封禁账号直接拒绝登录。通过后生成Access Token30分钟过期和Refresh Token7天过期以键值对方式返回给前端。前端拿到双Token后Access Token放在内存变量或HttpOnly Cookie里Refresh Token放在独立Cookie里路径限定为/api/auth/refresh这样能减少Refresh Token被带往业务接口的风险。前端用Axios响应拦截器统一处理401当请求返回401且没有正在刷新时调用/api/auth/refresh换新Token然后把失败的请求重新放行如果刷新接口也失败则跳转登录页。这套方案上线后最大的体验变化是用户挂着页面隔天回来只要Refresh Token没过期操作的瞬间就能静默完成续签基本感觉不到登录态丢失。5.2 续签接口的正确姿势与刷新令牌的安全约束刷新接口是认证体系里一个高危端点设计得不够严谨很容易被攻击者薅羊毛。我建议严格遵循以下几点。第一Refresh Token必须一次性使用。用户在刷新时提交一个Refresh Token服务端校验通过后直接将其加入黑名单然后签发新的Access Token和新的Refresh Token。这样即使Refresh Token被截获攻击者也只能用一次而且用户下一次正常刷新时服务端会识别出Token已被消费可以触发告警。第二Refresh Token要绑定风险因子。至少记录签发时的用户代理User-Agent和IP段刷新时做比对不匹配就要求重新登录。第三刷新接口要有频控。对同一个Refresh Token或同一用户每分钟的刷新次数做上限防止自动化脚本批量重放。第四令牌轮换后的旧Refresh Token立即作废。Redis里可以用key: refresh:{tokenId}存用户ID设置跟Refresh Token相同的过期时间刷新后删除旧记录写入新记录。这个做法的代价是多了一次Redis读写但换来了可控性。5.3 验证码与JWT联动一种轻量的设备绑定思路在SPA项目开发中有开发朋友问过我验证码能不能和JWT做联动达到“人机校验后又免登录”的效果我在实际项目中用过一种轻量方案。验证码校验通过后后端会生成一个一次性captchaToken也是一种短期JWT有效期3分钟把这个Token放到专门的Header里传给前端。前端提交登录请求时同时带上captchaToken服务端验证券码有效率并确认是同一个会话从而降低恶意批量登录的风险。不过这方案的适用场景有限如果项目本身有成熟的滑块验证或行为验证体系集成它的官方服务端校验更加省事。JWT在这里的角色就是给验证码回执做一个防伪造保真的凭证容器确实能省掉一部分会话表设计。6. 性能、单点登录拓展与选型建议6.1 无状态令牌在高并发场景下的性能表现很多架构师选JWT的初衷就是看中它的无状态性。用户在A服务登录后带着Token访问B服务、C服务各个服务只要共享验签公钥即可完成认证不需要每个服务都去Session存储中心查状态。这种设计在横向扩容时特别省心新增一个服务节点不需要同步任何会话数据。但无状态也不是免费的午餐。每次请求都要做一次签名验算如果系统一天有上亿请求这个验签开销会变得不可忽视。我用压测工具实测过在使用RS256时验证签名大约需要0.3到1毫秒使用HS256时通常更快在0.05到0.2毫秒之间。相比查一次Redis的开销0.5到1毫秒JWT验签在性能上并不吃亏。真正需要注意的不是验签本身而是Token解析后的业务查询。比如你的权限模型允许用户在Token签发后改了角色那每次请求还得查库确认角色性能优势就被抵消了。这时候可以考虑把角色直接放进Token但接受变更延迟。如果追求极致性能可以把JWT的验签结果缓存到本地内存或Redis以Token的jti为key缓存解析后的Claims和过期时间TTL设置为Token剩余时间。这样同一Token在有效期内的后续请求直接命中缓存省掉重复验签。不过要小心缓存导致注销延迟在安全性敏感场景下慎用。6.2 用JWT搭单点登录的可行性评估单点登录SSO是JWT应用的高频场景。典型做法是搭一个独立的认证中心用户在该中心登录后认证中心签发一个JWT其它业务系统验签通过即视为已登录。因为JWT自带iss签发者字段业务系统可以校验收到的Token确实是自己的认证中心发的而不是野鸡站点伪造的。但要注意轻量SSO用JWT完全够用复杂的企业级SSO比如需要对接SAML协议、OIDC协议、多租户隔离、动态权限下发时JWT往往只作为内部令牌格式外层还是要用标准协议做联邦认证。换句话说JWT是砖头SSO是大楼大楼需要砖头但不止砖头。如果你的需求仅仅是“集团内部多个站点一次登录通用”用JWT可以快速搭出来如果还要接入外部身份提供商、企业微信、钉钉、AD域建议直接研究OIDC协议把JWT作为其ID Token载体来使用熟悉这套生态后扩展性更强。6.3 什么情况下别硬上JWT这是我在技术评审时经常泼冷水的问题。JWT确实好用但并不是所有登录场景都适合它。如果你的业务强依赖服务端对会话的实时控制比如金融系统的强制签退、客服平台单点并发踢人、直播间房间踢封用户这种秒级生效需求JWT的无状态特性反而会拖后腿。我给你一个简单的判断标准登录态被篡改或删除后系统允不允许最多延迟几分钟到几十分钟才生效如果答案是不能忍受优先用传统Session Redis存储方案或者采用带token_version控制的JWT变体。另外系统流量极小、部署在低配服务器上的内部工具JWT反而可能显得杀鸡用牛刀Session方案实现更简单。技术选型别追新适合团队认知水平和业务场景才是第一位的。7. 常见问题排查与工具推荐7.1 线上JWT相关报错速查在实际项目中我整理过一张JWT问题排查表基本都是高频高频问题。常见现象可能原因处理方案登录后立刻提示未登录前端没正确携带Token检查Axios拦截器和请求头名称Token过期后自动续签不生效Refresh Token丢失或过期检查Cookie作用域和刷新接口路径本地能跑部署后验签失败密钥不一致检查配置中心密钥多环境隔离密钥用户改密码后旧Token还能用无token_version机制引入Token版本号或黑名单一段时间后所有请求401Access Token过期且刷新失败排查Refresh Token存储和刷新接口状态码时间不准导致Token提前过期服务器时钟漂移NTP同步签发时预留时钟偏移7.2 我最常用到的排查命令和工具清单开发调试阶段我通常用三个工具jwt.io用来解析Token内容确认Payload里的字段和过期时间是否符合预期Postman的脚本可以在收到响应后自动提取Token并注入后续请求的Header调试登录链路很方便线上排查时用Redis客户端查看黑名单和token_version的键值是否正确。如果需要写脚本批量验证Token有效性我经常用下面的Python小工具import jwt, time def verify_token(token: str, secret: str) - dict: try: payload jwt.decode(token, secret, algorithms[HS256]) if payload[exp] time.time(): return {valid: False, reason: expired} return {valid: True, payload: payload} except jwt.ExpiredSignatureError: return {valid: False, reason: expired} except jwt.InvalidTokenError: return {valid: False, reason: invalid}这套代码适合快速验证一批Token是否还有效定位“部分用户掉登录”之类的批量问题。真正遇到Key轮换需求时写一个发布计划先在配置中心增加新密钥并添加旧的验证密钥作为兼容验签灰度一段时间后再移除旧密钥。这个灰度思路是我在实践中总结出来的比直接切换密钥稳得多。写在最后的个人体会一开始我也踩过JWT的坑把它当成包治百病的万能钥匙什么状态都往Token里塞结果被安全扫描报告打脸。近几年做过的项目越多我越觉得JWT是柄双刃剑用好它是认证模块的加速器用不好它就是全站漏洞的突破口。在实际项目里我更倾向于把它当作一种“轻量、可验真的凭证”而不是“会话状态的替代品”该配合Redis黑名单的时候就配合该引入版本号的时候就引入该用双Token续签时就老老实实做别为了一点性能或便捷牺牲可控性。如果这篇文章能帮你避掉那些我在线上事故里吃过的亏那就算真有价值了。