企业官网建设流程全解析

先说个我自己的体会：干了这么多年后端，真正让你半夜被叫起来修的东西，往往不是复杂的业务逻辑，而是那些看起来最不起眼的“鉴权机制”。尤其是现在前后端分离成了常态，JWT（JSON Web Token）这个概念几乎每个开发者都挂在嘴边，但真正能在生产环境里把它用得滴水不漏的人，说实话不多。

我见过太多项目所谓的“JWT落地”，就是把用户ID塞进token里，然后verify一下完事，连签名算法用的是HS256还是RS256都没搞清楚。结果就是，一旦token泄露或者密钥管理不善，整个API就像没上锁的仓库，任何人都能进出。这篇文章我打算把自己在几个实际项目里踩过的坑、最终沉淀下来的那套方案，完整拆开讲讲。如果你正准备给新项目加认证，或者觉得现有的JWT用法哪里不对劲，这篇文章应该能帮你省掉不少弯路。

1. 认证与授权，到底在解决什么问题

先花点时间把“认证”（Authentication）和“授权”（Authorization）这两个词掰扯清楚。很多问题根源上就是这两个概念混了。

1.1 认证和授权，一字之差却天壤之别

认证解决的是“你是谁”的问题，授权解决的是“你能干什么”的问题。

举个最好懂的例子：你进小区大门，保安看了你的门禁卡，确认你是业主，这是认证。进了单元楼，你用钥匙只能打开自己家的门，开不了邻居家的门，这是授权。门禁卡只证明身份，而具体的开门权限，是由门锁和钥匙本身决定的。

在API场景下，认证就是你拿着用户名密码或者一个有效凭证，告诉服务器“我是张三”。服务器验证通过后，给你发一个token。之后你每次请求都带着这个token，服务器看一眼就确认“哦，是张三”。但张三能不能调用“删除所有用户”这个接口，那就不是认证该管的事了，那是授权环节的活。

我见过很多团队把两者混在一起处理，最典型的就是把权限判断直接写在业务代码里，比如：

if (user.getRole().equals("admin")) { // 执行删除操作 }

这种写法不是不行，但会导致权限逻辑散落在各个业务方法里，后期维护非常痛苦。一旦权限规则复杂起来，比如“用户能删自己创建的订单，但只能看不能改别人的订单”，这种写在业务代码里的判断会让代码迅速腐化。好的做法，是在API网关层或者拦截器层，统一做认证，然后按接口维度配置授权规则，业务代码里只关心业务本身。

1.2 为什么是JWT，Session的方案不香了吗

既然要保护API，传统方案就是Session，把用户状态存在服务器内存里，通过一个会话ID关联。JWT和Session之争，其实核心是状态存储位置的区别，以及由此带来的一系列架构影响。

Session方案下，服务器内存里存了一份完整的用户状态。这在单体应用时代没什么问题，但一旦你有多台应用服务器，就会出现一个尴尬的局面：用户在A服务器登录了，下一次请求被负载均衡转发到B服务器，B服务器上没有他的Session数据，就会判定未登录。

解决方案有几种：一是配置会话粘滞（Sticky Session），让同一个用户始终打到同一台服务器；二是把Session数据放到一个共享的Redis里。这两种方案都可行，但都引入了额外的复杂度。后者稍微好一点，但部署运维上依旧多一个强依赖。

JWT的本质，是把用户信息加密签名后放到客户端去保存，服务器不保存任何会话状态。它的payload里直接带着用户ID、过期时间、角色等关键信息。服务器收到请求后，只需要验签，然后从token里解析出用户身份即可。天然无状态、天然适合水平扩展，这是它最大的价值。

这里必须给小白一个建议：如果你只有一个单机小应用，Session其实是更简单直接的选择。引入JWT并不意味着高级，只有当你的应用确实面临多端、多实例、跨服务共享认证状态的场景时，JWT的优势才能真正体现出来。

1.3 无状态认证和前后端分离的天然契合

现在的前端项目，尤其是SPA，很少再依赖服务端模板渲染。前端是一个纯静态的服务，后端只提供API。Session方案下，浏览器会自动携带Cookie，这没问题，但在移动端App里就没有“浏览器自动带Cookie”这回事了。你需要手动把会话ID存起来，每次请求放进Header里，那就跟JWT的使用方式没有本质区别了。

JWT的设计在前后端分离场景下显得非常自然：前端调用登录接口，拿到token，存在localStorage或者pinia/redux之类的状态管理器里，然后在HTTP拦截器中统一塞进Authorization头。后端拿到之后解析验签。整个流程干净利落，没有任何Cookie跨域之类的糟心事。

跨域这块我还想说一句。Cookie方案下如果要跨域携带，你需要折腾CORS配置、withCredentials开关、SameSite属性，一个没配好就是各种诡异问题。用JWT做Header认证，跨域问题小很多，只要设置Access-Control-Allow-Headers包含Authorization即可，相对简单。

2. JWT核心机制与关键技术选型

把JWT当黑盒使用，和一知半解地使用，在碰到问题时的排查效率完全不一样。我把JWT拆开揉碎，从结构讲到算法选型。

2.1 JWT结构：三段式，各司其职

一个完整的JWT看起来像这样：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

它由三部分组成，用两个英文句点.分隔：

• Header：声明了token的类型和签名算法。通常是{"alg": "HS256", "typ": "JWT"}，经Base64Url编码后是第一部分。
• Payload：存放实际的声明（Claims），比如用户ID（sub）、用户名、角色、签发时间（iat）、过期时间（exp）等，Base64Url编码后是第二部分。
• Signature：对前两部分签名生成的字符串，用于防篡改。

需要注意一个常被误解的点：JWT的Header和Payload只是Base64编码，不是加密，谁都能解开看。所以千万不要在payload里放密码、身份证号等敏感信息。

2.2 HS256与RS256，到底该怎么选

这是很多团队一开始就会忽略的问题。签名算法常见的有HS256和RS256，两者有本质区别：

HS256的坑在于，如果服务端源码泄露，或者Git仓库历史里不小心提交了放着Secret的配置文件，攻击者就能拿着Secret自己签发任意身份的JWT。RS256要安全得多——即使公钥公开泄露，也无法反推出私钥，更不能伪造签名。

如果你在做微服务，多个服务都需要验证同一个token，那么RS256是更优选：认证服务用私钥签发，其他业务服务只保存公钥就能验签，私钥没有出过认证服务本身，暴露面小了很多。单体应用用HS256图个省事没问题，但Secret的管理必须严格。

2.3 JWT做登录验证，核心流程一句话概括

从流程上来讲，JWT登录验证分为两大阶段：签发阶段和验证阶段。

签发阶段，用户提交凭据，服务端核对，生成token，返回客户端。验证阶段，客户端每次请求带上token，服务端验签、查过期时间、提取身份。如果验证失败，返回401。

技术实现上，我一般把签发封装在AuthService里，验证封装在过滤器/拦截器里。这样既方便单元测试，也让代码结构清晰。下面具体展开。

3. 从零实现一套完整的JWT认证体系

下面进入实操环节。我用Java（Spring Boot）和Node.js（JavaScript）各写一套核心实现，你可以根据自己的技术栈参考。核心逻辑是通用的，换语言也只是换一个库而已。

3.1 用户登录接口，正确生成并返回token

以Spring Boot为例，我使用的库是java-jwt（由Auth0维护）或jjwt，整体依赖如下：

<dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-api</artifactId> <version>0.11.5</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-impl</artifactId> <version>0.11.5</version> <scope>runtime</scope> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-jackson</artifactId> <version>0.11.5</version> <scope>runtime</scope> </dependency>

登录接口的代码逻辑：

@PostMapping("/login") public ResponseEntity<?> login(@RequestBody LoginRequest request) { // 1. 校验用户名密码（从数据库取出用户，比对加密后的密码） User user = userService.authenticate(request.getUsername(), request.getPassword()); if (user == null) { return ResponseEntity.status(401).body("用户名或密码错误"); } // 2. 生成JWT令牌 String token = jwtUtils.generateToken(user.getId(), user.getUsername(), user.getRoles()); // 3. 返回token和用户基本信息 return ResponseEntity.ok(new LoginResponse(token, user.getUsername(), user.getRoles())); }

密码的校验我在这里特别提醒一句：密码比较一定要用专门的密码哈希算法，比如BCrypt，不能把明文密码存数据库，也不能用简单的MD5存储。

生成token的方法：

public String generateToken(Long userId, String username, List<String> roles) { Date now = new Date(); Date expiryDate = new Date(now.getTime() + 3600_000); // 1小时过期 return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("username", username) .claim("roles", roles) .setIssuedAt(now) .setExpiration(expiryDate) .signWith(secretKey, SignatureAlgorithm.HS256) .compact(); }

这里有一个要点：expiresIn这个过期时长，你不能拍脑袋定。我见过很多项目胡乱设个7天，导致token泄露后攻击者能玩很久。比较常见的做法是：普通登录token有效期设短一点，比如30分钟到2小时；如果业务确实需要长会话，配合刷新token机制来实现续期，而不是简单粗暴地把token时间拉长。

3.2 封装JWT解析与验签工具类

验签解析的工具类，一般包含三个核心方法：validateToken、parseToken、getClaims。这里给出参考：

public Claims parseToken(String token) { return Jwts.parserBuilder() .setSigningKey(secretKey) .build() .parseClaimsJws(token) .getBody(); } public boolean validateToken(String token) { try { Claims claims = parseToken(token); return claims.getExpiration().after(new Date()); } catch (ExpiredJwtException e) { // 过期，业务上需要提示客户端刷新token return false; } catch (JwtException | IllegalArgumentException e) { // 签名不对或token被篡改 return false; } }

这里要说一个我踩过的坑：验签时不能只看签名对不对，还要检查exp是否过期。有些库在解析签名时不会主动帮你校验过期时间，你需要额外判断。我用Claims里的getExpiration()就是这个目的。

另外，解析出来的Claims就是一个Map结构，你可以通过claims.get("roles")拿到角色列表，用来做后续的接口授权判断。

换一套技术栈看Node.js的实现

如果你用Node.js，库是jsonwebtoken和express-jwt：

// 安装：npm install jsonwebtoken const jwt = require('jsonwebtoken'); const SECRET_KEY = process.env.JWT_SECRET; // 签发 function generateToken(user) { return jwt.sign( { userId: user.id, username: user.username, roles: user.roles }, SECRET_KEY, { expiresIn: '1h' } ); } // 验证 function authMiddleware(req, res, next) { const authHeader = req.headers.authorization; if (!authHeader || !authHeader.startsWith('Bearer ')) { return res.status(401).json({ message: '缺少认证信息' }); } const token = authHeader.split(' ')[1]; try { const decoded = jwt.verify(token, SECRET_KEY); req.user = decoded; next(); } catch (err) { return res.status(401).json({ message: 'token无效或已过期' }); } }

Bearer前缀一定要记得处理，很多初学者直接用了整个Header里的字符串去验签，结果就是验签必然失败。

3.3 全局认证拦截器与授权策略落地

认证拦截器做的事情是：解析请求头里的token，验签通过后把用户信息放入请求上下文，供后续业务方法直接获取。

Spring Boot里的实现方式有很多，比如HandlerInterceptor、Filter、OncePerRequestFilter。我比较推荐HandlerInterceptor，因为它能很方便地和Spring MVC的Handler方法进行绑定。

public class JwtAuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { if ("OPTIONS".equalsIgnoreCase(request.getMethod())) { return true; // 放行预检请求 } String token = resolveToken(request); if (token == null || !jwtUtils.validateToken(token)) { response.setStatus(HttpServletResponse.SC_UNAUTHORIZED); response.setContentType("application/json;charset=UTF-8"); response.getWriter().write("{\"code\":401,\"message\":\"认证失败\"}"); return false; } Claims claims = jwtUtils.parseToken(token); request.setAttribute("userId", Long.parseLong(claims.getSubject())); request.setAttribute("username", claims.get("username")); request.setAttribute("roles", claims.get("roles")); return true; } }

有了这个拦截器，业务接口就可以从request里取用户信息：

@GetMapping("/user/profile") public UserProfile getProfile(HttpServletRequest request) { Long userId = (Long) request.getAttribute("userId"); return userService.getProfile(userId); }

授权这一层，如果项目不大，用@PreAuthorize("hasRole('ADMIN')")之类的注解就够了。如果是复杂的动态权限，或者接口数量多，建议把权限规则集中到一个配置类里，用“路径到角色”的映射表管理，比散落在代码里更可控。

3.4 刷新令牌刷新机制：不能只靠长有效期硬撑

如果你设了两小时的有效期，用户每两小时就要重新登录一次，体验肯定不行。所以JWT续签是每个生产级系统都必须面对的问题。

比较常用的方案是双token机制：access_token有效期短（比如30分钟），refresh_token有效期长（比如7天）。access_token用来正常访问API，refresh_token专门用来换取新的access_token。

刷新流程大致如下：

1. 客户端请求业务接口，后端返回401且错误码是TOKEN_EXPIRED。
2. 前端拦截到该错误后，携带refresh_token调用/auth/refresh接口。
3. 后端校验refresh_token的有效性，签发一个新的access_token（顺便也签发新的refresh_token，做轮换）。
4. 前端拿到新token后，重放刚才失败的请求。

后端刷新接口的大致实现：

@PostMapping("/auth/refresh") public ResponseEntity<?> refresh(@RequestBody RefreshRequest request) { String refreshToken = request.getRefreshToken(); // 这里必须做两件事： // 1. 验签、校验过期时间 // 2. 去Redis或数据库检查是否仍然有效（是否已被登出/撤销） if (!refreshTokenService.isValid(refreshToken)) { return ResponseEntity.status(401).body("refresh token无效"); } String newAccessToken = jwtUtils.generateToken(userId, username, roles); return ResponseEntity.ok(new TokenResponse(newAccessToken)); }

这里有一个重要的细节：refresh_token要不要存服务端？虽然JWT是无状态的，但refresh_token如果完全无状态，就会面临一个很尴尬的问题——你无法主动让一个已经发放出去的refresh_token失效。如果用户点了“退出登录”，你只能删除客户端存储的token，但攻击者手里已经拷贝的token还是能继续用。所以实际项目中，我倾向于把refresh_token的jti（JWT ID）存到Redis里，退出登录时直接删掉。这样虽然牺牲了一点“无状态”的特性，但换来的是主动控制权，这笔买卖划算。

4. 常见问题与避坑实战

这个部分我把这几年被问次数最多的几个问题整理了一下，每一个都是真实线上踩过的坑。

4.1 401 Unauthorized：最常见的几种根因

结合开场提到的搜索热词，比如“unexpected status 401 unauthorized: incorrect api key provided”，这类问题在API调用中非常典型。401的本质是“你给我的这个身份凭证，我不认”，但不认的原因千差万别：

排查401，我建议先抓原始请求和响应，在浏览器控制台、Postman、或者curl里加上-i参数看完整响应头。401响应里一般会带WWW-Authenticate头，它暗示了服务端期望的认证方式，这个信息非常有价值。

4.2 密钥管理：代码里的密钥就是裸奔

这个话题多说几句。我之前在审计别人项目的时候，经常看到有人把密钥写在application.yml里然后提交到Git仓库，这相当于把保险柜钥匙挂在门口。密钥一旦泄露，攻击者可以自己签发一个角色为admin的token，直接绕过所有权限。

正确的做法是：本地开发用环境变量或.env文件，线上用配置中心或KMS管理，绝不允许明文出现在代码仓库中。另外，.env文件要加进.gitignore，同时每次密钥轮换后，老密钥还要留一个“宽限期”，让还没用新密钥签发的token自然过期，而不是立刻全部失效。

还有一个很多人忽略的问题：密钥要有足够强度。HS256的密钥至少32字节。太短的密钥很容易被暴力破解。我自己生成密钥常用命令：

openssl rand -base64 48

生成一段足够长的随机字符串，然后设为环境变量。

特别注意kid（Key ID）参数

在JWT的Header里有一个可选的kid字段，它是用来让验证方找到对应密钥的标识。很多JWT库在处理kid时会去文件系统或数据库里根据这个ID查密钥，这就有可能导致认证绕过漏洞——如果攻击者把kid指定为一个可控路径或者SQL注入点，就可能导致任意文件读取或命令执行。这类漏洞在真实世界里已经出现过多次，所以务必谨慎处理kid。如果你用不到多密钥轮换，就不要用kid。如果要多密钥支持，使用kid时必须限制它只能匹配一个白名单里的值，绝不能直接拼进文件路径去读。

4.3 token过期，到底该不该报401

这个看似很小的问题，前端后端的体验影响却不小。

大部分人默认：token过期，返回401。这没问题。但如果是访问一个并不需要登录的公开接口，由于你统一加了拦截器，也会被401挡住。所以拦截器里必须配置白名单路径，比如/auth/login、/auth/refresh、/public/**这些路径不校验token。

还有一个细节：前端拿到401之后，应该区分“没带token”和“token过期”。我的建议是后端返回一个结构化错误体：

{ "code": 40101, "message": "token已过期", "data": null }

前端如果识别到40101这个码，就自动去刷新token，并重放原请求；如果识别到40100（未认证），就跳转登录页。这样用户的无感刷新体验是最好的。

4.4 如何在网关层做到统一鉴权

如果你用了微服务架构，每个服务都自己写一套JWT解析逻辑，不仅是代码重复的问题，更重要的是密钥管理和安全策略分散。更好的方案是让网关统一完成认证和粗粒度授权。

比如Spring Cloud Gateway + JWT：

@Bean public RouteLocator customRouteLocator(RouteLocatorBuilder builder) { return builder.routes() .route("auth-service", r -> r.path("/api/auth/**") .uri("lb://auth-service")) .route("user-service", r -> r.path("/api/user/**") .filters(f -> f.filter(jwtAuthFilter)) .uri("lb://user-service")) .build(); }

网关完成的工作包括：解析token、验签、把用户信息通过请求头传递给下游服务（比如X-User-Id、X-User-Roles），下游服务直接从请求头读取，自己的逻辑干净很多。这套模式在互联网大厂基本是标配方案。

不过也要注意：网关层如果配置太重，会导致网关本身成为性能瓶颈。验签操作本身就是异步、高并发的，建议网关采用异步非阻塞模型，比如Spring Cloud Gateway基于WebFlux，本身就是异步的，只要你自己不要在过滤器里写阻塞代码就行。

5. 关于JWT漏洞与安全加固，你必须知道的事

聊完了落地，我觉得有必要再单独开一节讲讲安全。毕竟JWT的核心是安全凭证，设计上是安全的，但用不好的话漏洞敞口不小。

5.1 算法混淆攻击

我记得早年有个经典的攻击手段，叫“算法混淆”。攻击者把token的alg字段改成none（不签名），服务端如果没做限制，就可能直接信任这个token。这些漏洞后来在库层面已经默认修复了，但如果你用的库版本过老，或者你自己手写了验签逻辑，就一定要检查是否强制指定了签名算法。比如：

Jwts.parserBuilder() .setSigningKey(secretKey) .build()

如果库在解析时发现alg为none，但你没做限制，就存在被绕过风险。现在的jjwt库在解析时会根据Header声明的算法去找对应的验签方式，并且默认拒绝none。但如果你是自行研究协议实现的，就得把“禁用alg=none”写进代码评审清单里。

另一个与算法混淆相关的场景是：不要接受不同类型的密钥用同一个字段解析。比如你的验签逻辑只接受HMAC密钥，但如果攻击者把token改成RS256并强迫服务端用setSigningKey(RSAPublicKey)去验签，就可能出现逻辑错误。所以setSigningKey之前，明确约束算法类型。

5.2 token泄露之后，怎么把损失控制在最小

JWT的无状态既是优点也是缺点：一旦签发，服务器无法主动让它提前失效，只能等exp自然过期。所以业界总结了几条控制损失的原则：

• 存储端不泄露，传送端不裸奔：前端不要放localStorage，因为XSS脚本能直接读到。更安全的是放在HttpOnly Cookie里，这样JavaScript读不到，能防大部分XSS窃取。但这里要注意，如果用Cookie，跟纯Header方案的跨域特点又不一样了，你需要手动处理CSRF问题。权衡之下我建议：Web项目优先考虑HttpOnly Cookie，移动端API保留Header方案，两者不冲突。
• 过期时间短酬谢：token生命周期越短，就算泄露了，攻击者能用的窗口期也越短。我见过生产环境里access_token设4小时的，说实话有点久。一般30分钟到1小时比较合适。
• 异地登录检测：虽然不是JWT本身的能力，但可以在签发时夹带一个lastLoginIp之类的claim，每次请求对比当前IP，如果不一致就要求重新验证。这个方法在安全要求高的系统里很实用。

5.3 主动失效场景处理：退出登录必须能拔线

我在前面的刷新token部分已经提到了用Redis存储refresh_token的jti。同理，如果你业务上需要做到“管理员可以封禁某个用户，让他立即下线”，就不能完全依赖JWT自身的无状态特性。方案有两个：

一是黑名单机制：服务端维护一个Redis集合，存该用户的token唯一标识（jti），一旦该用户需要被强制下线，就把jti写进黑名单。每次验签时除了验签名和过期时间，还要查一下Redis黑名单。这个方案最通用。

二是软状态方案：在token里不存敏感信息，而是只存一个sessionId，服务端Redis里记录sessionId -> userId的映射。如果这个session对应的用户在Redis里被删掉了，token自然作废。这种方案属于“半无状态”，灵活性和可控性都更高。

我在实际项目里一般推荐第二个方案：JWT承载身份声明，Redis记录会话的存活状态。这样既保留了JWT便于解析的优点，又解决了主动失效的痛点。

6. 从单服务走向多端的当前实践

最后说说当我面对一个完整项目的时候，JWT这盘棋会怎么下。

6.1 一个实用的多端登录方案

现在的应用通常有Web端、移动端、小程序，甚至第三方开放平台。多端登录意味着同一个用户可能同时在Web、App、小程序上保持会话。如果纯粹按用户维度去管会话，会出现“在一端退出，全部端被迫退出”的问题。

我采用的是会话维度管理：

• 签发token时，加入一个deviceId或者clientType的claim。
• Redis的key用session:{userId}:{deviceId}来存会话信息，而不是session:{userId}。
• 退出登录时，只删除当前这个deviceId对应的会话。

这个方案的灵活性好很多，尤其是针对用户“手机端一直保持登录，但Web端退出后手机端不受影响”的需求，可以直接支持。

顺便说一下，如果你在设计第三方开放api，比如“开放平台接入”，那通常用的是更严格的双token方案加API Key，而不是直接给第三方用户签发你的用户token。每个第三方应用有自己的appId和appSecret，业务上先把第三方应用认证通过，再在内部生成一个受限的访问token，这个token的权限范围和数据范围都是受控的。这跟上面提到的“incorrect api key provided”报错是同一个领域的话题——API Key和JWT在不同场景下的职责区分要明确。

6.2 日志和审计，别把敏感信息打进日志

我在排查线上问题的时候经常要翻日志，但我也见过不少日志系统里把token整个打出来的。token本质上就是一把钥匙，钥匙样子都印在日志里了，只要日志泄露，就等于钥匙被复制。所以打日志的时候，token和密码都必须脱敏，建议统一封装一个日志工具类，对Authorization头、密码字段、身份证号做替换处理。

同时建议引入请求ID链路追踪，在网关层生成一个requestId，贯穿整个调用链，这样在排查具体一个用户的认证失败问题时，能快速定位到是哪一次请求、哪一步验签失败。这套机制配合日志脱敏，排查效率和安全性都能兼顾。

我在实际操作中的习惯是，认证日志只保留**“用户ID、时间、IP、结果（成功/失败）、原因分类”**这五个维度，明文token和payload里的原始Claims一律不打进日志系统。这样即使日志被拖库，也拿不到能直接利用的凭证信息。

6.3 终版架构长什么样

一个典型的中大型系统，认证这块的最终架构大致是这样：

• 认证中心（Auth Service）负责登录、签发token、管理刷新令牌。
• API网关或统一入口负责拦截请求、验签、将用户信息注入请求上下文。
• 业务服务通过请求上下文拿到用户ID和角色，做必要的本地校验，不再直接依赖JWT解析。
• Redis承担刷新令牌状态、黑名单、会话信息等动态数据的存储。
• 密钥通过配置中心或KMS下发，定时轮换，轮换期间新旧密钥并存。

这套架构支撑百万级用户量基本没什么问题，再往上加性能层、加缓存策略，也只是在这个骨架之上做扩展而已。

对我来说，做认证授权最重要的一件事，是不管方案多花哨，一定要想清楚每一个token从出生到销毁的完整生命周期，以及它被泄露后你能做到的止损动作。想清了这两件事，JWT对你来说就不是一个库存的玩具，而是一个真正可靠的安全工具。