做Web开发这几年JWT这个缩写几乎绕不开。不管是你自己搭个人项目还是接手公司的SPA应用后端给前端丢过来的登录凭证十有八九就是那一串由两个英文句点隔开的长字符。我第一次接手这类项目时看着那串字符的第一反应是——这不就是一段被糊过的加密文本吗后来翻了一堆资料才明白它压根不是加密而是一段可校验、可签名、可携带用户状态的自包含数据块。这篇文章我会从原理一路拆到实战覆盖签名算法选型、登录认证链路、Token续签方案、SPA项目里验证码与JWT的配合实现以及这些年网上经常被吐槽的JWT漏洞总结和加固手段。无论你是刚接触SPA开发的新手还是准备排查线上认证问题的老手都能从中找到能直接拿去用的东西。我们先把最基础也最容易误解的那层窗户纸捅破JWT到底是个什么玩意儿。1. JWT到底是个什么东西1.1 为什么后端老爱用它无状态认证的商业逻辑要理解JWT先得搞清楚它解决了什么问题。传统的Session认证流程是用户登录后服务端把用户信息存在内存里或者Redis里同时生成一个sessionId塞给浏览器浏览器每次请求带着这个Id服务端再去存储里查。这套方案在单个服务器时代很完美但到了分布式和微服务时代就尴尬了——用户的请求被负载均衡转发到服务器A结果登录状态存在了服务器B上取不到session用户就莫名其妙被登出了。JWT的思路完全反过来它把用户身份信息直接编码进Token本身服务端只需要验证签名的合法性不需要在内存里存任何会话状态。这也就是所谓的“无状态认证”。好处非常明显服务实例可以随便横向扩容不需要共享存储适合跨域、跨系统、移动端App这种没法维持传统Cookie会话的场景接口对接方拿到的Token是自包含的可以独立校验。当然无状态不是免费的午餐。它牺牲了“主动失效”的能力——如果Token没设置合理的过期时间或者发生了泄露你没法像删Session那样把它从服务端踢出去。业界对这件事的解决方案通常是把Token的过期时间调短配合续签机制或者用黑名单兜底。后面我会专门讲续签和漏洞加固这里先记下这个权衡Session靠存储换可控性JWT靠签名换扩展性没有谁绝对好只有适不适合。对比项SessionJWT状态存储服务端内存/RedisToken内自包含扩展性多实例需共享存储天然支持水平扩容主动失效直接删Session需黑名单或缩短过期时间跨域/移动端需要配置无需额外配置防御重点CSRFXSS存储端1.2 三段式结构逐行拆解Header.Payload.SignatureJWT全称是JSON Web Token标准定义在RFC 7519里。它长得像这样eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U这三段之间用点分隔分别是Header头部、Payload载荷、Signature签名。每一段都做了Base64URL编码注意不是普通Base64编码而是把替换成-、/替换成_、去掉末尾的这样整个字符串放在URL里、放在请求头里都不会产生歧义。Header是固定的元信息通常长这样{ alg: HS256, typ: JWT }alg标明签名算法比如HS256、RS256、ES256typ一般固定是JWT在你把Token塞进其他类型报文时可以做个区分实际开发中很多库并不校验这个字段。Payload才是真正存储业务数据的地方官方称为Claims声明。它又分成三类注册声明Registered Claims、公共声明Public Claims、私有声明Private Claims。注册声明是标准规定的几个键最常用的有subSubjectToken的主体通常存用户IDexpExpiration Time过期时间戳必须校验iatIssued At签发时间issIssuer签发者多系统交互时用来识别来源audAudience接收方标识私有声明就是自己定义的键值对比如role、name、permission。很多人喜欢把用户昵称、头像URL甚至手机号都塞进Payload里图一个“自包含”。但你要明白一个关键点Payload只是做了Base64URL编码不是加密。任何人拿到Token粘贴到jwt.io或者一段三行的解码脚本里就能看到明文内容。所以Payload里绝不能放密码、身份证号、银行卡号这类敏感数据只能放“不怕被别人看到”的非敏感信息比如用户ID、角色编码。1.3 一个必须破除的误区编码不是加密签名不等于防篡改很多初学者会混淆两个概念看到那串字符就觉得“好安全”——实际上Base64URL编码就是把字节流变成可打印字符毫无机密性可言。真正提供安全性的是第三段Signature。签名的生成过程可以简化成三步把Base64URL编码后的Header和Payload用点拼接起来得到一个待签名串headerBase64Url.payloadBase64Url用Header里声明好的算法比如HMAC SHA-256拿上密钥对它做哈希运算把哈希结果再做一次Base64URL编码拼到待签名串后面形成完整的JWT校验方做的事情更简单取前两段重新算一遍签名和第三段比对。一致说明内容确实是持有密钥的人签发的同时没有被改动过不一致直接拒绝。这里的核心逻辑是完整性校验不是机密性保护。它是用来保证“数据没被篡改”和“数据确实来自可信方”的不保证“数据别人看不见”。这个认知会贯穿整篇文章尤其是在聊漏洞的时候——很多攻击手法就是利用了开发者“把JWT当成加密数据”的错觉。2. 签名算法选型HS256还是RS256不能拍脑袋2.1 对称签名与公私钥签名的本质区别选签名算法是JWT实战中的第一个分岔路口。最常见的两个是HS256HMAC SHA-256和RS256RSA SHA-256。HS256是对称签名签发和校验用的是同一个密钥。它的优点是运算快、实现简单一个secret就能搞定缺点也很明显——谁拿到这个secret谁就能自己伪造合法Token所以secret必须保存在服务端绝不能下发到客户端、更不可能写进前端代码里。HS256适合那种“签发端和校验端都是我自己”的单体应用或内部服务。RS256是非对称签名签发端持有私钥校验端只用公钥。私钥负责签名公钥负责验签公钥被泄露了也无所谓因为拿到公钥只能验证签名、不能伪造签名。这就非常适合微服务架构——网关、各个服务节点只需要配置一份公钥就能校验来自统一认证中心的Token私钥只掌握在认证中心手里攻击面被大幅缩小。另一个实际区别是签名长度。RSA签名长度和密钥长度绑定通常512字节起步会导致Token体积变大ES256基于椭圆曲线的签名长度更短而且安全性更好但实现商会比RSA多一些注意点比如旧版本的Node.js、Java库对ES256的支持有坑。2.2 不同业务场景下的选型思路直接给一份参考结论单体应用、前后端分离、后端就是唯一认证方优先HS256简单够用密钥藏在环境变量里配合强随机字符串线上别用123456这种弱密钥就行。微服务架构、多个服务需要校验同一个Token用RS256认证中心分发私钥各服务配置公钥。好处是私钥不落地到业务服务安全性好也方便公钥轮换。涉及第三方身份提供商比如企业内部SSO一般选RS256或ES256因为第三方只会给你公钥不会把共享密钥给你。移动端、IoT设备等Token要被多个端解析校验非对称方案更安全毕竟密钥不可能安全地藏在客户端里。顺带提一下Java领域的实现选型比较成熟的是jjwtJava JWT和nimbus-jose-jwt前者API友好、文档多Go项目用golang-jwt/jwtPython用PyJWTNode.js生态里则是jsonwebtoken一家独大。语言不同底层原理完全一致看一份规范的讲解就能通吃。2.3 密钥管理与轮换的实操细节无论选了哪种算法密钥管理都是最容易翻车的环节。HS256的secret必须是高熵随机串建议长度不低于32字节用openssl rand -base64 32这类命令生成不要自己敲一段普通字符串。RS256的私钥不要提交到代码仓库建议加载自环境变量、挂载的密钥文件或密钥管理服务例如KMS公钥倒是可以打包进代码因为它本来就是公开的。密钥轮换是两个方案都要面对的。HS256轮换时要注意“新老密钥并存期”——签发新Token用新secret验证时先试新secret、失败再试旧secret等所有存量Token过期后再彻底下线旧密钥。RS256轮换更规范一些可以在Token的Header里加一个kidKey ID每个JWT声明自己是用哪个密钥签的服务端维护密钥列表根据kid找到对应私钥/公钥来验签。kid看起来不起眼但它是做密钥轮换的定海神针强烈建议一开始就加上。3. 登录认证实战从签发到校验的完整链路3.1 环境准备与核心依赖实战部分我用Node.js Express来演示因为代码密度低、可读性好原理讲清楚之后迁移到Java或Go没有障碍。你需要准备一个Node.js环境装几个依赖npm install express jsonwebtokenJava开发者就换成jjwt-api、jjwt-impl、jjwt-jackson三件套Go开发者用github.com/golang-jwt/jwt/v5。代码逻辑是相通的。我习惯在项目根目录放一个jwt.js模块专门封装签名、解析、校验三个方法避免业务代码里到处散落着jsonwebtoken.sign之类的调用。下面这段代码是我项目中比较常用的一种封装const jwt require(jsonwebtoken); const SECRET process.env.JWT_SECRET || please-change-me; const EXPIRES_IN 2h; function signToken(user) { return jwt.sign( { sub: user.id, role: user.role, name: user.name }, SECRET, { algorithm: HS256, expiresIn: EXPIRES_IN } ); } function verifyToken(token) { return jwt.verify(token, SECRET, { algorithms: [HS256] }); } module.exports { signToken, verifyToken };这里有一个细节很多人会忽略jwt.verify的时候必须显式传入algorithms白名单。jsonwebtoken库在旧版本或者部分配置下如果服务端不指定算法攻击者把Header里的alg改成none或HS256就有机会绕过校验。显式声明只用HS256相当于堵死了这类路径。后面漏洞章节会展开讲。3.2 后端签发Token登录接口的标准姿势登录接口一般长这样先校验用户名密码校验通过后调用signToken把Token和几个基础信息返回给前端const express require(express); const { signToken } require(./jwt); const app express(); app.use(express.json()); app.post(/api/login, (req, res) { const { username, password } req.body; // 这里换成真实的用户校验逻辑比如从数据库查询并比对密码 if (username ! admin || password ! 123456) { return res.status(401).json({ message: 用户名或密码错误 }); } const token signToken({ id: 10001, role: admin, name: 管理员 }); res.json({ token, tokenType: Bearer, expiresIn: 7200 }); });响应里的tokenType: Bearer是约定俗成的标准前端组拿到后需要拼成Bearer token放在请求头里。为什么返回还带一个expiresIn因为前端需要知道Token的有效期方便提前做“即将过期”提示或触发续签动作而不是等请求401了再傻乎乎地跳登录页。3.3 校验Token的中间件每一处受保护接口的守门员签发Token只是上半场真正的关键是校验。实现一个Express中间件挂在所有需要登录的路由前面const { verifyToken } require(./jwt); function authMiddleware(req, res, next) { const authHeader req.headers.authorization || ; const [scheme, token] authHeader.split( ); if (scheme ! Bearer || !token) { return res.status(401).json({ message: 未提供认证凭证 }); } try { const payload verifyToken(token); req.user payload; // 把解析出的用户信息挂到请求对象上 next(); } catch (err) { // 需要把过期和签名错误区分处理后面排查部分细讲 return res.status(401).json({ message: Token无效或已过期 }); } } app.use(/api/user, authMiddleware); app.get(/api/user/profile, (req, res) { res.json({ user: req.user }); });校验中间件的两个细节值得注意。第一req.user payload放的是解码后的Claims后续接口可以直接读取用户ID和角色不用每个接口都重新解析一遍Token省事也统一。第二中间件里不要直接返回笼统的“认证失败”最好区分“Token格式错误”“签名不合法”“Token过期”等情况并写进日志。排查线上问题的时候这种区分能让你少掉一半头发。3.4 前端拿到Token之后存哪里、怎么带都是学问前端拿到Token后的存储方案网上的口水战打了好几年其实不外乎三种localStorage、CookiehttpOnly、内存变量。localStorage方案实现最简单——登录成功存进localStorage请求前塞进Authorization头。优点是请求头可控、不容易被CSRF攻击缺点是一旦页面被注入恶意脚本XSS攻击者可以直接读到Token并原样带走。Cookie httpOnly方案正好相反前端Cookie由浏览器自动携带脚本里读不到天然防XSS窃取但跨域时Cookie的携带需要精细化配置SameSite、Secure等属性如果不小心就直接面对CSRF攻击的风险需要额外防护。我个人在纯前端SPA项目里更倾向于localStorage 极严格的XSS防护CSP、输入过滤、依赖库漏洞扫描因为SPA的跨域请求场景多Authorization头的方式更通用。如果你做的项目对安全要求极高且站点没有复杂的跨域部署Cookie httpOnly Secure SameSiteLax是更稳的选择。这没有一个标准答案但要明白你选了哪种就同时承担了哪种的风险面。4. Token续签三种常用方案与取舍4.1 为什么不能一签管终身有人会问把过期时间设成一年不就不用折腾续签了吗话是这么说但风险很直接Token一旦泄露相当于把用户一年的登录态交给了攻击者而你完全没有办法主动回收。所以业内共识是过期时间必须短比如2小时但体验上又不能要求用户每2小时重新登录一次于是“续签”就成了必需品。续签的本质是在Token过期之前借助一个可信凭据换取新的Token。下面三种方案是我在实际项目里见过最多的按复杂度从低到高讲。4.2 方案一滑动过期刷新适合内部系统思路很简单在响应每个受保护接口时检查当前Token的剩余有效期如果少于某个阈值比如30分钟就用同样的Claims再签一个新Token通过响应头或响应体带回去前端替换存储。function refreshIfNeeded(req, res, payload) { const exp payload.exp; const remaining exp - Math.floor(Date.now() / 1000); if (remaining 1800) { const newToken signToken({ sub: payload.sub, role: payload.role }); res.setHeader(X-New-Token, newToken); } }这个方案的优点是实现极简、无额外存储缺点是每个请求都可能产生新Token服务端没法准确记录“当前有效的Token是哪个”一旦Token泄露你连把它踢掉的途径都没有只能等它自己过期。适合内部管理系统、低并发后台这类环境但不太适合用户量大的C端产品。4.3 方案二双Token机制Access Token Refresh Token这是目前互联网产品里最主流的做法。思路是Access Token有效期短30分钟到2小时只管访问受保护资源。Refresh Token有效期长7天到30天只负责在Access Token过期后去换取新的Access Token绝不参与业务接口访问。前端收到401后带Refresh Token调/api/refresh接口后端校验Refresh Token合法后签发新的Access Token。代码如下app.post(/api/refresh, (req, res) { const refreshToken req.body.refreshToken; try { const payload verifyToken(refreshToken); if (payload.type ! refresh) { return res.status(401).json({ message: Refresh Token类型错误 }); } const newAccessToken signToken({ sub: payload.sub, role: payload.role, type: access }); res.json({ token: newAccessToken, expiresIn: 7200 }); } catch (err) { return res.status(401).json({ message: Refresh Token失效 }); } });上面这段代码里我特意在Token里加了一个type字段用来区分Access和Refresh。原因很简单如果不区分一个拿到的Access Token被泄露后攻击者可以拿它去“续签”成长期的Refresh Token整个机制就形同虚设了。Refresh Token本身也有讲究。第一它要在服务端持久化存储Redis或数据库并绑定用户ID和设备标识第二建议单次使用——每次刷新时校验合法后立即作废旧Refresh Token、签发一个新Refresh Token这样即便Refresh Token泄露攻击者一旦使用原设备的下一次刷新就会失败系统能察觉异常。第三前端要把Refresh Token和Access Token分开存减少一次XSS把两个Token全带走的概率。4.4 续签中的并发与安全细节双Token方案在移动端和SPA里会遇到一个经典问题多个请求同时打到后端都发现Access Token过期同时拿着同一个Refresh Token去刷新。结果要么是多次签发、旧Token被提前作废导致其他请求失败要么产生竞态条件。常用的解法是给Refresh Token加一次性标记刷新时在Redis里对比存储的旧Refresh Token是否一致一致才签发新Token并原子地替换成新值。下面是一个简化版的Redis处理逻辑const redisKey refresh:${userId}; const oldToken await redis.get(redisKey); if (oldToken ! refreshToken) { return res.status(401).json({ message: Refresh Token已被使用 }); } const newRefreshToken generateNewRefreshToken(); await redis.set(redisKey, newRefreshToken, EX, 30 * 24 * 3600);这套逻辑里oldToken ! refreshToken这一步是个简单的乐观锁配合Redis单线程特性可以处理大部分并发场景。高并发业务也可以考虑给Redis加一个短时分布式锁把刷新动作串行化。这里我踩过一次坑最初只做了Redis里存Refresh Token但漏了对比逻辑客户端并发请求一上来旧Token没被作废结果好几个请求都刷新成功后端的会话管理直接乱套。所以再强调一遍——续签操作必须是幂等且防重放的不能只“存”不“比”。5. SPA登录场景验证码与JWT的无缝衔接5.1 验证码在认证流程中的位置接着聊一个SPA项目里绕不开的流程登录时的验证码。有人觉得既然有JWT提供无状态认证验证码是不是多此一举其实两者解决的问题完全不同。JWT解决的是“登录成功后如何保持会话”验证码解决的是“登录入口如何防止被机器人刷”。暴力破解、撞库攻击、批量注册全都盯着登录接口。验证码的作用本质上是在密码校验之前先做一次人机校验把自动化脚本挡在门外。常见的有图形验证码、滑块验证码、行为验证码无感。实现复杂度依次递增。5.2 验证码状态存哪里Redis方案验证码本身是一个“有过期时间的临时状态”而且必须能跨请求保持——用户先请求验证码图片过一会儿再提交登录。这个状态放在哪里最合适显然是Redis天然带过期时间属性。设计上我习惯这样生成验证码时往Redis里写入一条记录key是一个随机生成的captchaIdvalue是一个包含验证码文本和过期时间的结构TTL设为5分钟。响应给前端的是captchaId加上一张图片图片里是字体加了噪点和干扰线的字符。const svgCaptcha require(svg-captcha); const { v4: uuidv4 } require(uuid); const redis require(redis).createClient(); app.get(/api/captcha, async (req, res) { const captcha svgCaptcha.create({ size: 4, noise: 3, fontSize: 48 }); const captchaId uuidv4(); await redis.setEx(captcha:${captchaId}, 300, captcha.text.toLowerCase()); res.json({ captchaId, image: captcha.data }); });为什么不用Session存验证码因为SPA项目的后端大概率是无状态的用Session还要再引入会话存储反而违背了使用JWT的初衷。直接把验证码状态放进Redis天然无状态、天然过期登录接口校验地独立不占任何会话资源。5.3 从“输入验证码”到“拿到Token”的完整流程完整的登录链路应该是这样前端打开登录页调用/api/captcha获取验证码图片和captchaId。用户输入用户名、密码、验证码点击登录。后端登录接口先接收captchaId和验证码文本去Redis里取出正确的验证码比对。比对通过后立刻删除这条Redis记录验证码只能用一次再进入用户名密码校验。用户名密码通过走正常JWT签发流程返回Access Token和Refresh Token。代码如下app.post(/api/login, async (req, res) { const { username, password, captchaId, captchaText } req.body; // 第一步校验验证码 const stored await redis.get(captcha:${captchaId}); if (!stored || stored ! captchaText.toLowerCase()) { return res.status(400).json({ message: 验证码错误或已过期 }); } await redis.del(captcha:${captchaId}); // 第二步校验用户名密码真实项目里这里要处理密码哈希比对 const user await findUser(username); if (!user || !verifyPassword(password, user.passwordHash)) { return res.status(401).json({ message: 用户名或密码错误 }); } // 第三步签发JWT const accessToken signToken({ sub: user.id, role: user.role, type: access }); const refreshToken signToken({ sub: user.id, role: user.role, type: refresh }); res.json({ token: accessToken, refreshToken }); });这里要特别提两个细节。第一个是验证码校验和密码校验的顺序。如果把密码校验放在前面脚本攻击者就可以通过“密码到底错没错”来反向确认一个账号是否存在这等于给撞库提供了侧信道信号。验证码永远在最前面挡住机器人后面的密码错误提示也要尽量统一不要区分“用户不存在”和“密码错误”。第二个是失败次数的限流。即使有了验证码也建议对同一个IP、同一个账号做登录失败次数限流比如连续失败5次锁定15分钟。验证码防的是“普通脚本”限流防的是“绕过验证码或者人工慢速尝试”的情况两者是不同层面的防线叠加使用效果才稳固。6. JWT常见漏洞与安全加固实践6.1 那些年被玩坏的漏洞类型汇总网上关于JWT漏洞的总结基本绕不开下面几个类型每一种我都见过真实案例或者社区里的经典讨论一个个说清楚。算法混淆攻击Algorithm Confusion。这是最著名的JWT漏洞之一。攻击者把Token的Header从RS256改成HS256然后拿泄露的公钥当HMAC的密钥重新签名。如果服务端校验时不强制指定算法某一些旧库会默认信任Header声明的算法结果公钥被当成了对称密钥来验签伪造的Token就这么通过了。防御方式就是我在前面反复强调的校验时显式锁定算法白名单不接受Header里的算法任意变更。algnone攻击。这是更古老的漏洞。当年有些JWT库为了支持“无签名场景”预留了none算法。攻击者把Header的alg改成none、删掉签名段如果服务端没有禁用none或者空签名处理不当就能直接伪造任意身份的Token。现在主流库默认禁掉了但不排除你用的老版本、老项目里还留着这个坑。线上排查时可以拿一个测试Token改改alg字段试一下如果校验没拦住说明该升级库并加白名单了。弱密钥暴破。HS256潜在的风险点。如果secret用的是弱口令、常见字符串攻击者能下载大量JWT样本后用字典跑本地签名比对第三个签名段是否匹配从而还原出密钥。防御手段很简单secret必须是高熵随机串并且用环境变量隔离不落代码库。JWT本身不存在暴力破解难度密钥弱就相当于裸奔。过期失效校验缺失。有些只写了verify、没检查exp的代码会接受任何过期Token。这类问题常见于手写解析逻辑的项目。所以无论你用什么库都要确认它在verify流程里默认检查exp如果没有就自己补。敏感信息泄露。开发者把手机号、邮箱甚至密码哈希放进Payload结果Token在日志、前端存储、第三方接口传递的环节被截获解码即泄露。记住Payload永远当明文处理。Token固定与无状态副作用。同一用户的Token永远不会变导致无法在服务端踢人下线、无法感知异地登录。配合续签机制或Redis的jti黑名单才能缓解。6.2 高并发下的黑名单与主动失效既然JWT无状态无法主动失效那业务上的“登出”“改密码后踢下线”怎么办最实用的方案是维护一个黑名单。黑名单里存的是jtiJWT ID或Token哈希配合exp用Redis的TTL自动清理。const { v4: uuidv4 } require(uuid); // 签发时给每个Token分配唯一jti function signToken(user) { return jwt.sign( { sub: user.id, role: user.role, jti: uuidv4() }, SECRET, { expiresIn: EXPIRES_IN, algorithm: HS256 } ); } // 登出时把jti加入黑名单 async function revokeToken(jti, ttlSeconds) { await redis.setEx(jwt:blacklist:${jti}, ttlSeconds, 1); } // 校验时先查黑名单 async function isRevoked(jti) { return await redis.exists(jwt:blacklist:${jti}); }这个方案的代价是“每次校验都要查一次Redis”严格来说JWT已经不是完全无状态了但换来了可控性在C端产品里价值极高。缓存层用Redis本身就很便宜拿到安全收益完全划算。改密码、封号场景的做法相似把该用户的所有jti加入黑名单同时提升用户密码版本号。更进阶的做法是给用户维护一个tokenVersion每次敏感操作后加一JWT的Payload里带着当前版本版本不匹配直接拒。6.3 安全加固清单我把自己在项目上线前总要过一遍的检查项整理成一份清单直接照着逐条核对显式锁定算法白名单不接受none。校验exp、iat必要时校验iss和aud。Payload只放非敏感信息用户密码等绝不放进去。Secret必须高熵随机串通过环境变量或密钥管理服务加载。Token过期时间合理Access Token不超过2小时Refresh Token不超过30天。所有传输走HTTPSToken不做URL参数传递防日志泄露。前端存储根据XSS和CSRF风险面选择方案两种方案都不完美要清楚自己在防什么。登出时走黑名单机制主动失效能力必须有。第三方库保持更新老版本的JWT库存在已知漏洞要及时升级。日志里不要打印完整Token结构化日志里只记录jti或最后4位。7. 问题排查与调试实录7.1 高频报错速查表写好看得见摸得着的排查部分。下面这些是群里、评论区里被问烂了的报错都整理成速查表报错现象常见原因解决办法JsonWebTokenError: invalid signatureSecret不一致、密钥被轮换、算法不匹配核对两端密钥确认Header的alg和校验白名单一致TokenExpiredError: jwt expired过期时间到了客户端与服务器时间偏差大校验过期时间调整服务器时间同步NTP超时后走续签流程Unexpected token in JSONToken字符串被截断、被URL编码检查Token是否完整粘贴注意Bearer前缀处理401但日志显示verify通过黑名单查到了该Token检查登出逻辑是否误把正常Token封禁同一Token在多环境一个通过一个不通过多环境密钥配置不同检查各环境环境变量是否一致Payload中文乱码Base64URL解码后未按UTF-8解析解码时显式指定UTF-8字符集7.2 排错心法先看签名再看过期最后分享一个我自己的排查心法。接到一个认证报错不要先去看业务代码先把这个Token拿去jwt.io或者本地写个三行脚本解出来看一眼三样东西Header里的alg、Payload里的exp和iat、以及第三段签名是否跟本地用同样密钥算出来的一致。顺序也很有讲究签名不一致说明密钥或算法出问题跟过期无关签名没问题但报错过期才去查时间同步和过期策略两个都没问题说明校验逻辑本身可能写岔了比如中间件没挂到路由上、或者前端丢的是旧Token而本地缓存没更新。调试的技巧说到底是把“JWT是一个黑盒”变成“JWT是一段可以用脚本拆开看的字符串”。在很多项目里校验不通过的第一反应是怀疑前端传参有问题其实十次里有七八次是后端密钥不一致。我就因为拿到不同环境的测试Token而排查了整整一个下午最后发现是测试环境把JWT_SECRET覆盖成了默认值。还有一个没人提的小技巧本地调试时可以给exp设一个特别长的值比如86400000一天避免每几分钟断一次调试流程。但上线前的测试用例里一定要额外写一个“过期Token必须被拒绝”的用例保证过期逻辑在真实配置下是生效的。JWT这个东西原理说穿了并不复杂就是一个经过签名编码的JSON对象。但在实际工程里面任何一个环节的草率处理——签名算法不锁定、Payload塞敏感数据、过期时间设成半年、续签不做防重放——都可能变成线上事故的引子。把原理吃透把校验细节当成习惯你的登录认证链路才算真正站得住。