之前做微服务接口认证时一直被 Token 的体积和过期策略折磨。JWT 越写越长、刷新逻辑绕来绕去、退出登录之后 Token 还能用……这些问题网上资料很多但都比较零散。本文整理了一份完整的 Token 优化实践手册覆盖 JWT 原理、字段瘦身、双 Token 机制、Redis 缓存、时钟偏移处理等内容新手可以当入门教程看有经验的开发者可以直接对照排错和复用。1. Token 优化的本质先搞清楚“贵”在哪里提到“Token 优化”不同场景下理解完全不同。不少文章写的是大模型 API 调用的 token 成本控制比如压缩 Prompt、限制上下文长度但还有一类更常见的工程场景是 Web 应用和微服务里的“访问令牌”优化也就是 JWT、OAuth2 Token 这类东西。本文围绕后者展开重点讲清楚在 Java/Spring Boot 技术栈下如何让 Token 更短、更安全、更好维护。1.1 Token 在工程中的三重身份Token 在系统里至少承担三个职责身份凭证客户端登录后拿到 Token后续请求在 Header 中携带它服务端据此识别“你是谁”。权限依据Token 中通常包含角色、权限等信息服务端可以基于这些信息做接口鉴权。会话载体无状态服务中Token 替代了传统 Session使得服务可以水平扩展不必依赖会话粘滞。正因为这三种身份一旦 Token 设计不合理影响会同时出现在安全、性能和扩展性三个层面。1.2 JWT 的结构与体积来源JWTJSON Web Token是目前使用最广泛的 Token 方案。一个标准 JWT 由三部分组成Header头部声明令牌类型和签名算法。Payload负载存放用户 ID、角色、过期时间等自定义声明。Signature签名对 Header 和 Payload 进行签名防止内容被篡改。每一部分都经过 Base64Url 编码最终以Header.Payload.Signature形式拼接。很多人觉得 JWT“大”是因为 Payload 里塞了太多可有可无的字段。比如把用户昵称、头像地址、手机号、邮箱全放进去一个 Token 轻松突破 1KB。每个请求都带着这个 1KB 的字符串在高并发场景下带宽和解析开销都会被放大。1.3 优化要解决的四类痛点结合项目落地经验Token 优化主要解决下面四类问题痛点表现影响Token 体积过大请求头携带的 Authorization 过长增加带宽消耗部分网关对 Header 长度有限制过期策略单一只有固定过期时间无法动态控制用户被封禁后 Token 仍有效安全性差刷新机制复杂客户端刷新逻辑混乱服务端难以管控用户体验差容易出现“登录频繁失效”密钥管理随意前后端共用密钥或密钥写死在代码里Token 可被伪造存在严重安全风险后面几节就围绕这些痛点逐步展开。2. 环境准备与版本说明本文示例以 Java Spring Boot 为演示环境核心依赖是 JJWTJava JWT 库。具体版本可根据你的项目实际情况调整重点演示配置思路和代码结构。2.1 运行环境JDK1.8 及以上推荐 11 或 17Spring Boot2.x 或 3.x 均可示例代码兼容两者Redis3.x 及以上可选用于双 Token 方案构建工具Maven 3.6IDEIDEA 或 Eclipse命令行演示使用 Maven2.2 项目依赖在pom.xml中添加如下依赖dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-impl/artifactId version0.11.5/version scoperuntime/scope /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-jackson/artifactId version0.11.5/version scoperuntime/scope /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency这里把jjwt-impl和jjwt-jackson的 scope 设置为 runtime 是 JJWT 官方的推荐做法避免业务代码直接依赖实现类。版本号建议与实践环境保持一致如果使用 JDK17 以上也可以选择 0.12.x 系列。2.3 项目结构token-optimize-demo ├── pom.xml └── src/main/java/com/example/token ├── TokenApplication.java ├── config │ └── JwtProperties.java ├── util │ └── JwtTokenUtil.java ├── service │ └── TokenService.java ├── interceptor │ └── AuthInterceptor.java └── controller ├── LoginController.java └── UserController.java3. JWT 设计层面的优化很多项目一上来就是“封装一个 JWT 工具类”然后搞定签发和解析就完事了。其实 Token 的优化在设计阶段就开始了等到上线后再改成本和风险都会高很多。3.1 精简 Payload字段做减法JWT 的 Payload 是一个 JSON 对象开发者可以在里面自由添加自定义字段。正因为自由很多人习惯把用户信息一股脑往里塞。先来看一个“反面教材”{ sub: 1234567890, name: 张三, nickname: 张三丰, avatar: https://example.com/avatar/123.png, email: zhangsanexample.com, phone: 13800138000, gender: male, role: admin, deptId: 1001, createdAt: 1700000000000 }这段 JSON 编码后再 Base64UrlPayload 部分就有 300 多个字符。而服务端真正每次请求都需要的信息可能只有userId和role。其他信息完全可以从数据库或缓存里取。优化后的 Payload{ sub: 1234567890, role: admin, exp: 1700003600, iat: 1700000000 }再配合jtiToken 唯一标识字段用于后续的 Redis 管理和吊销{ sub: 1234567890, role: admin, jti: a3f9c1e2-4b7d-4f5a-9e2c-7d0a1b2c3d4e, exp: 1700003600, iat: 1700000000 }这样 JWT 的 Payload 部分能够控制在 120 个字符左右。核心原则只放“每次请求都会用到的、且不经常变化的”信息。个人信息、权限列表、菜单配置这类数据建议通过缓存接口按需获取。3.2 签名算法怎么选JJWT 支持的常见签名算法有 HS256、HS384、HS512、RS256、RS384、RS512、ES256 等。它们的区别主要在于使用对称密钥还是非对称密钥。HS256对称算法签发和验证使用同一个密钥。优点是实现简单、计算快缺点是密钥一旦泄露攻击者可以直接伪造 Token。适合前后端分离的单体应用。RS256非对称算法私钥签发、公钥验证。适合微服务架构——认证中心持有私钥各业务服务只保留公钥即使某个服务被攻破也无法伪造 Token。ES256基于椭圆曲线的非对称算法密钥更短、计算更快但要求 JDK 或依赖库提供相应支持兼容性需要额外测试。工程实践建议单体应用起步阶段用 HS256 足够但要保管好密钥。微服务架构优先 RS256避免多个服务共享同一个对称密钥。如果追求性能和密钥长度优势可以评估 ES256但要确认所有运行环境都支持。下面是一个生成 HS256 密钥的参考方式Key key Keys.hmacShaKeyFor(Decoders.BASE64.decode(你的Base64编码的32字节密钥));密钥长度至少 32 字节256 位不要用太短的字符串硬凑。3.3 过期时间与时钟偏移JWT 的exp过期时间字段是服务端判断 Token 是否有效的主要依据。但分布式环境下不同服务器的系统时间可能存在几十秒甚至几分钟的偏差如果认证中心和业务服务的时钟不一致可能出现“Token 明明没过期却验证失败”的问题。JJWT 提供了setClock方法可以引入时钟偏移量Jwts.parserBuilder() .setSigningKey(key) .setClock(() - new Clock() { Override public Date now() { return new Date(System.currentTimeMillis() - 30 * 1000); } }) .build() .parseClaimsJws(token);上面的代码允许 30 秒的时钟偏移。生产环境建议把这个偏移量做成配置项方便不同机房调整。另外一个容易被忽略的点是exp和iat都是时间戳签发 Token 时建议统一使用服务器时间不要依赖客户端传过来的时间。4. 完整实战Spring Boot 中的 Token 优化方案这一节我们从零开始搭建一个带 Token 签发、解析、刷新、吊销的完整示例。先采用单 Token Redis 的方案再扩展双 Token 机制。4.1 配置类读取密钥与过期时间创建JwtProperties.java用于读取application.yml中的自定义配置package com.example.token.config; import org.springframework.boot.context.properties.ConfigurationProperties; import org.springframework.stereotype.Component; Component ConfigurationProperties(prefix jwt) public class JwtProperties { /** * HS256 签名密钥Base64 编码至少 32 字节 */ private String secret; /** * 访问令牌过期时间单位秒 */ private long expireSeconds; /** * 刷新令牌过期时间单位秒 */ private long refreshExpireSeconds; /** * 允许的时钟偏移单位秒 */ private long clockSkew; // getter / setter 省略需要手动生成 }对应的application.ymljwt: secret: bW9yZS1zZWN1cmUtc2VjcmV0LWtleS1mb3ItaHMyNTYtZGVtby1wcm9qZWN0 expire-seconds: 7200 refresh-expire-seconds: 604800 clock-skew: 30secret这个值只是示例实际项目中必须通过环境变量或配置中心注入严禁提交到 Git 仓库。4.2 核心工具类JWT 签发与解析创建JwtTokenUtil.java封装 Token 的创建、解析、刷新能力package com.example.token.util; import com.example.token.config.JwtProperties; import io.jsonwebtoken.Claims; import io.jsonwebtoken.Clock; import io.jsonwebtoken.Jwts; import io.jsonwebtoken.SignatureAlgorithm; import io.jsonwebtoken.security.Keys; import org.springframework.stereotype.Component; import javax.crypto.SecretKey; import java.util.Date; import java.util.HashMap; import java.util.Map; import java.util.UUID; Component public class JwtTokenUtil { private final JwtProperties jwtProperties; private final SecretKey key; public JwtTokenUtil(JwtProperties jwtProperties) { this.jwtProperties jwtProperties; this.key Keys.hmacShaKeyFor( java.util.Base64.getDecoder().decode(jwtProperties.getSecret())); } /** * 生成访问令牌 */ public String createAccessToken(String userId, String role) { MapString, Object claims new HashMap(); claims.put(role, role); return createToken(claims, userId, jwtProperties.getExpireSeconds()); } /** * 生成刷新令牌 */ public String createRefreshToken(String userId) { MapString, Object claims new HashMap(); claims.put(type, refresh); return createToken(claims, userId, jwtProperties.getRefreshExpireSeconds()); } private String createToken(MapString, Object claims, String userId, long expireSeconds) { Date now new Date(); Date expireDate new Date(now.getTime() expireSeconds * 1000); return Jwts.builder() .setClaims(claims) .setSubject(userId) .setId(UUID.randomUUID().toString()) .setIssuedAt(now) .setExpiration(expireDate) .signWith(key, SignatureAlgorithm.HS256) .compact(); } /** * 解析 Token返回 Claims无效或过期时抛出异常 */ public Claims parseToken(String token) { return Jwts.parserBuilder() .setSigningKey(key) .setClock(() - new Clock() { Override public Date now() { return new Date(System.currentTimeMillis() - jwtProperties.getClockSkew() * 1000); } }) .build() .parseClaimsJws(token) .getBody(); } public String getUserId(String token) { return parseToken(token).getSubject(); } }这里有几个设计细节值得说明createAccessToken和createRefreshToken使用不同的过期时间。刷新令牌的 Payload 中增加type: refresh标记用于识别令牌类型。UUID.randomUUID()生成的jti字段为后续 Redis 存储和吊销提供唯一标识。4.3 单 Token Redis 黑名单模式先介绍最简单可靠的优化方案Token 无状态签发但把“吊销”状态记录到 Redis。当用户退出登录或管理员强制下线时把 Token 的jti加入 Redis 黑名单设置过期时间等于 Token 剩余有效期。后续请求解析 Token 时先查黑名单命中则拒绝。创建TokenService.javapackage com.example.token.service; import com.example.token.config.JwtProperties; import com.example.token.util.JwtTokenUtil; import io.jsonwebtoken.Claims; import org.springframework.data.redis.core.StringRedisTemplate; import org.springframework.stereotype.Service; import java.util.concurrent.TimeUnit; Service public class TokenService { private static final String BLACKLIST_KEY_PREFIX token:blacklist:; private final StringRedisTemplate redisTemplate; private final JwtTokenUtil jwtTokenUtil; private final JwtProperties jwtProperties; public TokenService(StringRedisTemplate redisTemplate, JwtTokenUtil jwtTokenUtil, JwtProperties jwtProperties) { this.redisTemplate redisTemplate; this.jwtTokenUtil jwtTokenUtil; this.jwtProperties jwtProperties; } /** * 退出登录 / 吊销 Token */ public void revokeToken(String token) { Claims claims jwtTokenUtil.parseToken(token); String jti claims.getId(); long remainSeconds (claims.getExpiration().getTime() - System.currentTimeMillis()) / 1000; if (remainSeconds 0) { redisTemplate.opsForValue().set( BLACKLIST_KEY_PREFIX jti, 1, remainSeconds, TimeUnit.SECONDS ); } } /** * 检查 Token 是否已被吊销 */ public boolean isRevoked(String token) { Claims claims jwtTokenUtil.parseToken(token); return Boolean.TRUE.equals( redisTemplate.hasKey(BLACKLIST_KEY_PREFIX claims.getId())); } }这个方案的好处是日常请求仍然是纯无状态的只有退出登录时才访问 RedisRedis 压力很小而一旦需要吊销 Token也能实时生效。4.4 双 Token 机制访问令牌 刷新令牌单 Token 方案有一个体验问题如果访问令牌过期时间设置太短比如 30 分钟用户需要频繁重新登录设置太长比如 24 小时Token 泄露后的风险窗口又太大。双 Token 机制是经典解法Access Token访问令牌有效期较短30 分钟到 2 小时每次请求携带。Refresh Token刷新令牌有效期较长7 天到 30 天仅在 Access Token 过期后使用用于换取新的 Access Token。核心流程用户登录服务端同时返回 Access Token 和 Refresh Token。客户端请求接口时携带 Access Token。Access Token 过期后客户端携带 Refresh Token 请求/refresh接口。服务端验证 Refresh Token 有效后签发新的 Access Token同时可选择是否轮换 Refresh Token。Refresh Token 也过期后用户需要重新登录。在LoginController.java中实现登录与刷新接口package com.example.token.controller; import com.example.token.service.TokenService; import com.example.token.util.JwtTokenUtil; import io.jsonwebtoken.Claims; import org.springframework.web.bind.annotation.*; import java.util.HashMap; import java.util.Map; RestController public class LoginController { private final JwtTokenUtil jwtTokenUtil; private final TokenService tokenService; public LoginController(JwtTokenUtil jwtTokenUtil, TokenService tokenService) { this.jwtTokenUtil jwtTokenUtil; this.tokenService tokenService; } /** * 登录接口用户名密码校验略 */ PostMapping(/login) public MapString, String login(RequestParam String username, RequestParam String password) { // 实际项目中这里应该调用用户服务校验账号密码 // 这里直接模拟登录成功 String userId 10086; String role admin; String accessToken jwtTokenUtil.createAccessToken(userId, role); String refreshToken jwtTokenUtil.createRefreshToken(userId); MapString, String result new HashMap(); result.put(accessToken, accessToken); result.put(refreshToken, refreshToken); return result; } /** * 刷新令牌接口 */ PostMapping(/refresh) public MapString, String refresh(RequestHeader(Authorization) String refreshToken) { // 去掉 Bearer 前缀 if (refreshToken.startsWith(Bearer )) { refreshToken refreshToken.substring(7); } Claims claims jwtTokenUtil.parseToken(refreshToken); if (!refresh.equals(claims.get(type, String.class))) { throw new IllegalArgumentException(不是有效的刷新令牌); } String userId claims.getSubject(); String role String.valueOf(claims.get(role, String.class)); String newAccessToken jwtTokenUtil.createAccessToken(userId, role); MapString, String result new HashMap(); result.put(accessToken, newAccessToken); return result; } /** * 退出登录吊销刷新令牌和访问令牌 */ PostMapping(/logout) public String logout(RequestHeader(Authorization) String accessToken, RequestParam String refreshToken) { tokenService.revokeToken(accessToken.replace(Bearer , )); tokenService.revokeToken(refreshToken); return logout success; } }注意上面代码中刷新令牌里也保存了role字段。有人会问刷新令牌只是用来换新 Access Token 的为什么要重复存储角色这是为了在刷新时不必再查一次数据库或缓存。如果你更看重数据一致性比如用户角色中途被修改可以去掉刷新令牌中的role刷新时重新查询权限。4.5 拦截器中的 Token 校验与刷新联动创建AuthInterceptor.java统一拦截请求完成 Token 校验、黑名单检查、用户信息透传package com.example.token.interceptor; import com.example.token.service.TokenService; import com.example.token.util.JwtTokenUtil; import io.jsonwebtoken.Claims; import org.springframework.stereotype.Component; import org.springframework.web.servlet.HandlerInterceptor; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; Component public class AuthInterceptor implements HandlerInterceptor { private final JwtTokenUtil jwtTokenUtil; private final TokenService tokenService; public AuthInterceptor(JwtTokenUtil jwtTokenUtil, TokenService tokenService) { this.jwtTokenUtil jwtTokenUtil; this.tokenService tokenService; } Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录、刷新、退出接口 String uri request.getRequestURI(); if (uri.startsWith(/login) || uri.startsWith(/refresh)) { return true; } String authHeader request.getHeader(Authorization); if (authHeader null || !authHeader.startsWith(Bearer )) { response.setStatus(401); response.getWriter().write(Missing token); return false; } String token authHeader.substring(7); try { Claims claims jwtTokenUtil.parseToken(token); // 黑名单检查 if (tokenService.isRevoked(token)) { response.setStatus(401); response.getWriter().write(Token revoked); return false; } request.setAttribute(userId, claims.getSubject()); request.setAttribute(role, claims.get(role, String.class)); return true; } catch (Exception e) { response.setStatus(401); response.getWriter().write(Invalid token); return false; } } }再补充一个测试接口模拟获取当前登录用户信息package com.example.token.controller; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestAttribute; import org.springframework.web.bind.annotation.RestController; import java.util.HashMap; import java.util.Map; RestController public class UserController { GetMapping(/me) public MapString, Object me(RequestAttribute(userId) String userId, RequestAttribute(role) String role) { MapString, Object result new HashMap(); result.put(userId, userId); result.put(role, role); return result; } }记得在配置类中注册拦截器package com.example.token.config; import com.example.token.interceptor.AuthInterceptor; import org.springframework.context.annotation.Configuration; import org.springframework.web.servlet.config.annotation.InterceptorRegistry; import org.springframework.web.servlet.config.annotation.WebMvcConfigurer; Configuration public class WebConfig implements WebMvcConfigurer { private final AuthInterceptor authInterceptor; public WebConfig(AuthInterceptor authInterceptor) { this.authInterceptor authInterceptor; } Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(authInterceptor) .addPathPatterns(/**) .excludePathPatterns(/login, /refresh); } }4.6 运行与验证启动 Spring Boot 应用后用 curl 做一组简单的验证。登录获取 Tokencurl -X POST http://localhost:8080/login?usernameadminpassword123456预期返回{ accessToken: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMDA4NiIsInJvbGUiOiJhZG1pbiIsImp0aSI6ImEzZjljMWUyLTRiN2QtNGY1YS05ZTJjLTdkMGExYjJjM2Q0ZSIsImlhdCI6MTcwMDAwMDAwMCwiZXhwIjoxNzAwMDA3MjAwfQ.signature, refreshToken: eyJhbGciOiJIUzI1NiJ9.eyJ0eXBlIjoicmVmcmVzaCIsInN1YiI6IjEwMDg2IiwianRpIjoiYjRjMmE4YjAtOWQxMC00YzNhLWI5MWEtNjU2ZjA0M2Y1YzBkIiwiaWF0IjoxNzAwMDAwMDAwLCJleHAiOjE3MDA2MDQ4MDB9.signature }带 Access Token 访问/mecurl -X GET http://localhost:8080/me \ -H Authorization: Bearer accessToken预期返回{ userId: 10086, role: admin }退出登录后再用同一个 Token 访问应该收到 401 和Token revoked提示。5. 常见问题与排查思路Token 相关的报错在前后端联调时非常常见很多问题看着是“Token 失效”根因各不相同。问题现象常见原因解决思路Token 解析抛出JwtExceptionKey 长度不足或 Secret 不一致确认 Base64 解码后字节数是否达到 32 字节签发和解析是否使用同一个密钥Token 明明没过期却被判无效服务器时钟不同步使用 NTP 同步时间或在 JJWT 中设置 Clock 偏移Access Token 过期后刷新失败Refresh Token 被当作 Access Token 使用检查type声明确认刷新接口校验了令牌类型用户退出登录后 Token 还能用没有做吊销或黑名单处理使用 Redis 存储 jti 黑名单设置过期时间等于 Token 剩余时长Header 太长导致网关 413Payload 字段过多精简自定义声明只保留 userId、role 等必要字段HS256 密钥泄露导致 Token 可伪造密钥硬编码在代码中改为环境变量或配置中心存储定期轮换密钥刷新 Token 被重放攻击同一 Refresh Token 被多次使用刷新令牌加入版本号或一次性使用机制例如刷新后废弃旧令牌以下是几个高频报错的详细排查过程。报错 1io.jsonwebtoken.security.WeakKeyException这个异常表示签名密钥太弱。HS256 要求密钥至少 256 位32 字节排查时先检查配置的 Secret 经过 Base64 解码后是否满足长度要求echo -n 你的Secret | base64 -d | wc -c如果不足 32 字节需要重新生成。推荐使用下面命令生成一个足够强度的随机密钥openssl rand -base64 32报错 2io.jsonwebtoken.ExpiredJwtException表示 Token 已经过期。排查顺序先看服务器当前时间是否和签发时间正常。检查 JWT 的exp时间戳确认签发时设置的过期时间是否符合预期。如果服务器时间有偏差在解析时设置setClock允许偏移。如果是正常的过期前端应该走刷新流程而不是重新登录。报错 3Redis 中黑名单 Key 数量持续增长如果黑名单 key 设置了过期时间却仍然增长很快可能是两个原因Token 的 jti 重复了导致多个 Token 复用同一个 key。Redis 的过期时间没有设置成功检查代码中是否传入了TimeUnit.SECONDS。生产环境建议给 Redis 配置内存淘汰策略并定期监控token:blacklist:*前缀的 key 数量。报错 4刷新接口返回“不是有效的刷新令牌”通常是因为刷新接口拿到的仍然是 Access Token。前后端对接时必须明确区分两个 Token 的用途。如果在拦截器中统一校验了 Token还需要确保/refresh路径被放行否则刷新请求根本到不了控制器。6. 最佳实践与工程建议经历过 Token 方案从简单到复杂、再到踩坑修复的完整过程总结出下面几条可以直接落地的工程建议。6.1 Token 安全基线密钥分级管理开发环境、测试环境、生产环境使用不同的密钥生产密钥通过配置中心或环境变量注入不入代码库。定期轮换密钥如果使用 HS256密钥泄露的风险随着暴露时间增加。有条件的话每 3 到 6 个月轮换一次。使用 HTTPSToken 通过请求头传输如果链路是明文 HTTP抓包即可拿到 Token再强的签名算法也保护不了核心数据。设置合理的过期时间Access Token 建议 15 分钟到 2 小时Refresh Token 建议 7 天到 30 天。过期时间越短越安全但用户体验越差需要寻找平衡点。6.2 性能优化建议精简 Payload 能显著降低请求体积特别是移动端弱网环境下每个请求省 200 字节对体验的改善是实打实的。签名算法选择要考虑并发场景HS256 的验证性能优于 RS256 和 ES256但安全性上非对称算法更优。具体取舍可以参考单体应用选 HS256微服务网关统一认证选 RS256。避免每次请求都查询数据库用户角色、权限这类数据可以放到 Redis 缓存按用户 ID 维度设置 5 到 10 分钟过期。6.3 可维护性建议统一 Token 工具类不要在每个 Controller 里直接调用 JJWT 的 API统一封装后后续更换签名算法或密钥存储方式时只改一个类。配置项集中在配置类中过期时间、密钥、时钟偏移全部通过配置注入方便不同环境差异化调整。记录 Token 签发的审计日志大用户量场景下建议记录 Token 的 jti、用户 ID、签发时间、过期时间、IP 等信息便于问题回溯。版本兼容如果团队中同时存在多个服务升级 JJWT 版本时要注意兼容性先用测试环境验证签名和解析逻辑。6.4 生产环境注意事项上线前要确认网关层对请求头的长度限制部分 Nginx 配置默认large_client_header_buffers较小可能导致 JWT 请求头被截断。Redis 不可用时要设计降级策略黑名单查询失败时建议“宁可暂时放行也不要全部拒绝”但要结合业务安全性评估。刷新令牌接口要做限流和异常检测防止被批量调用。涉及用户账号封禁、权限变更等操作一定要同步吊销相应 Token不要只依赖 Token 过期。7. 总结与学习路线这篇 Token 优化手册从 JWT 的基本结构讲起覆盖了 Payload 精简、签名算法选择、双 Token 机制、Redis 黑名单、时钟偏移处理等核心内容。完成这套实践你应该能够理解 JWT 的 Header/Payload/Signature 三部分各自的作用与体积来源。区分 HS256 与 RS256 的适用场景能够在不同架构下做出合理选择。设计出短小、安全、支持吊销和刷新的 Token 方案。通过 Redis 黑名单解决“退出登录后 Token 仍有效”的难题。面对常见 Token 报错能够按原因快速定位并修复。接下来可以继续学习的方向包括OAuth2.0 与 OIDC 协议、网关层统一鉴权设计、Spring Authorization Server 的使用、自研认证中心的架构演进。如果工作中遇到“Token 越写越长”“刷新逻辑混乱”“用户权限变更不生效”这类问题建议先从本文第 3 节的字段精简和第 4 节的双 Token 改造入手通常能解决大部分痛点。如果本文对你有帮助可以收藏备用。后续遇到 Token 相关的业务问题欢迎留言讨论。
之前做微服务接口认证时一直被 Token 的体积和过期策略折磨。JWT 越写越长、刷新逻辑绕来绕去、退出登录之后 Token 还能用……这些问题网上资料很多但都比较零散。本文整理了一份完整的 Token 优化实践手册覆盖 JWT 原理、字段瘦身、双 Token 机制、Redis 缓存、时钟偏移处理等内容新手可以当入门教程看有经验的开发者可以直接对照排错和复用。1. Token 优化的本质先搞清楚“贵”在哪里提到“Token 优化”不同场景下理解完全不同。不少文章写的是大模型 API 调用的 token 成本控制比如压缩 Prompt、限制上下文长度但还有一类更常见的工程场景是 Web 应用和微服务里的“访问令牌”优化也就是 JWT、OAuth2 Token 这类东西。本文围绕后者展开重点讲清楚在 Java/Spring Boot 技术栈下如何让 Token 更短、更安全、更好维护。1.1 Token 在工程中的三重身份Token 在系统里至少承担三个职责身份凭证客户端登录后拿到 Token后续请求在 Header 中携带它服务端据此识别“你是谁”。权限依据Token 中通常包含角色、权限等信息服务端可以基于这些信息做接口鉴权。会话载体无状态服务中Token 替代了传统 Session使得服务可以水平扩展不必依赖会话粘滞。正因为这三种身份一旦 Token 设计不合理影响会同时出现在安全、性能和扩展性三个层面。1.2 JWT 的结构与体积来源JWTJSON Web Token是目前使用最广泛的 Token 方案。一个标准 JWT 由三部分组成Header头部声明令牌类型和签名算法。Payload负载存放用户 ID、角色、过期时间等自定义声明。Signature签名对 Header 和 Payload 进行签名防止内容被篡改。每一部分都经过 Base64Url 编码最终以Header.Payload.Signature形式拼接。很多人觉得 JWT“大”是因为 Payload 里塞了太多可有可无的字段。比如把用户昵称、头像地址、手机号、邮箱全放进去一个 Token 轻松突破 1KB。每个请求都带着这个 1KB 的字符串在高并发场景下带宽和解析开销都会被放大。1.3 优化要解决的四类痛点结合项目落地经验Token 优化主要解决下面四类问题痛点表现影响Token 体积过大请求头携带的 Authorization 过长增加带宽消耗部分网关对 Header 长度有限制过期策略单一只有固定过期时间无法动态控制用户被封禁后 Token 仍有效安全性差刷新机制复杂客户端刷新逻辑混乱服务端难以管控用户体验差容易出现“登录频繁失效”密钥管理随意前后端共用密钥或密钥写死在代码里Token 可被伪造存在严重安全风险后面几节就围绕这些痛点逐步展开。2. 环境准备与版本说明本文示例以 Java Spring Boot 为演示环境核心依赖是 JJWTJava JWT 库。具体版本可根据你的项目实际情况调整重点演示配置思路和代码结构。2.1 运行环境JDK1.8 及以上推荐 11 或 17Spring Boot2.x 或 3.x 均可示例代码兼容两者Redis3.x 及以上可选用于双 Token 方案构建工具Maven 3.6IDEIDEA 或 Eclipse命令行演示使用 Maven2.2 项目依赖在pom.xml中添加如下依赖dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-api/artifactId version0.11.5/version /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-impl/artifactId version0.11.5/version scoperuntime/scope /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt-jackson/artifactId version0.11.5/version scoperuntime/scope /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency这里把jjwt-impl和jjwt-jackson的 scope 设置为 runtime 是 JJWT 官方的推荐做法避免业务代码直接依赖实现类。版本号建议与实践环境保持一致如果使用 JDK17 以上也可以选择 0.12.x 系列。2.3 项目结构token-optimize-demo ├── pom.xml └── src/main/java/com/example/token ├── TokenApplication.java ├── config │ └── JwtProperties.java ├── util │ └── JwtTokenUtil.java ├── service │ └── TokenService.java ├── interceptor │ └── AuthInterceptor.java └── controller ├── LoginController.java └── UserController.java3. JWT 设计层面的优化很多项目一上来就是“封装一个 JWT 工具类”然后搞定签发和解析就完事了。其实 Token 的优化在设计阶段就开始了等到上线后再改成本和风险都会高很多。3.1 精简 Payload字段做减法JWT 的 Payload 是一个 JSON 对象开发者可以在里面自由添加自定义字段。正因为自由很多人习惯把用户信息一股脑往里塞。先来看一个“反面教材”{ sub: 1234567890, name: 张三, nickname: 张三丰, avatar: https://example.com/avatar/123.png, email: zhangsanexample.com, phone: 13800138000, gender: male, role: admin, deptId: 1001, createdAt: 1700000000000 }这段 JSON 编码后再 Base64UrlPayload 部分就有 300 多个字符。而服务端真正每次请求都需要的信息可能只有userId和role。其他信息完全可以从数据库或缓存里取。优化后的 Payload{ sub: 1234567890, role: admin, exp: 1700003600, iat: 1700000000 }再配合jtiToken 唯一标识字段用于后续的 Redis 管理和吊销{ sub: 1234567890, role: admin, jti: a3f9c1e2-4b7d-4f5a-9e2c-7d0a1b2c3d4e, exp: 1700003600, iat: 1700000000 }这样 JWT 的 Payload 部分能够控制在 120 个字符左右。核心原则只放“每次请求都会用到的、且不经常变化的”信息。个人信息、权限列表、菜单配置这类数据建议通过缓存接口按需获取。3.2 签名算法怎么选JJWT 支持的常见签名算法有 HS256、HS384、HS512、RS256、RS384、RS512、ES256 等。它们的区别主要在于使用对称密钥还是非对称密钥。HS256对称算法签发和验证使用同一个密钥。优点是实现简单、计算快缺点是密钥一旦泄露攻击者可以直接伪造 Token。适合前后端分离的单体应用。RS256非对称算法私钥签发、公钥验证。适合微服务架构——认证中心持有私钥各业务服务只保留公钥即使某个服务被攻破也无法伪造 Token。ES256基于椭圆曲线的非对称算法密钥更短、计算更快但要求 JDK 或依赖库提供相应支持兼容性需要额外测试。工程实践建议单体应用起步阶段用 HS256 足够但要保管好密钥。微服务架构优先 RS256避免多个服务共享同一个对称密钥。如果追求性能和密钥长度优势可以评估 ES256但要确认所有运行环境都支持。下面是一个生成 HS256 密钥的参考方式Key key Keys.hmacShaKeyFor(Decoders.BASE64.decode(你的Base64编码的32字节密钥));密钥长度至少 32 字节256 位不要用太短的字符串硬凑。3.3 过期时间与时钟偏移JWT 的exp过期时间字段是服务端判断 Token 是否有效的主要依据。但分布式环境下不同服务器的系统时间可能存在几十秒甚至几分钟的偏差如果认证中心和业务服务的时钟不一致可能出现“Token 明明没过期却验证失败”的问题。JJWT 提供了setClock方法可以引入时钟偏移量Jwts.parserBuilder() .setSigningKey(key) .setClock(() - new Clock() { Override public Date now() { return new Date(System.currentTimeMillis() - 30 * 1000); } }) .build() .parseClaimsJws(token);上面的代码允许 30 秒的时钟偏移。生产环境建议把这个偏移量做成配置项方便不同机房调整。另外一个容易被忽略的点是exp和iat都是时间戳签发 Token 时建议统一使用服务器时间不要依赖客户端传过来的时间。4. 完整实战Spring Boot 中的 Token 优化方案这一节我们从零开始搭建一个带 Token 签发、解析、刷新、吊销的完整示例。先采用单 Token Redis 的方案再扩展双 Token 机制。4.1 配置类读取密钥与过期时间创建JwtProperties.java用于读取application.yml中的自定义配置package com.example.token.config; import org.springframework.boot.context.properties.ConfigurationProperties; import org.springframework.stereotype.Component; Component ConfigurationProperties(prefix jwt) public class JwtProperties { /** * HS256 签名密钥Base64 编码至少 32 字节 */ private String secret; /** * 访问令牌过期时间单位秒 */ private long expireSeconds; /** * 刷新令牌过期时间单位秒 */ private long refreshExpireSeconds; /** * 允许的时钟偏移单位秒 */ private long clockSkew; // getter / setter 省略需要手动生成 }对应的application.ymljwt: secret: bW9yZS1zZWN1cmUtc2VjcmV0LWtleS1mb3ItaHMyNTYtZGVtby1wcm9qZWN0 expire-seconds: 7200 refresh-expire-seconds: 604800 clock-skew: 30secret这个值只是示例实际项目中必须通过环境变量或配置中心注入严禁提交到 Git 仓库。4.2 核心工具类JWT 签发与解析创建JwtTokenUtil.java封装 Token 的创建、解析、刷新能力package com.example.token.util; import com.example.token.config.JwtProperties; import io.jsonwebtoken.Claims; import io.jsonwebtoken.Clock; import io.jsonwebtoken.Jwts; import io.jsonwebtoken.SignatureAlgorithm; import io.jsonwebtoken.security.Keys; import org.springframework.stereotype.Component; import javax.crypto.SecretKey; import java.util.Date; import java.util.HashMap; import java.util.Map; import java.util.UUID; Component public class JwtTokenUtil { private final JwtProperties jwtProperties; private final SecretKey key; public JwtTokenUtil(JwtProperties jwtProperties) { this.jwtProperties jwtProperties; this.key Keys.hmacShaKeyFor( java.util.Base64.getDecoder().decode(jwtProperties.getSecret())); } /** * 生成访问令牌 */ public String createAccessToken(String userId, String role) { MapString, Object claims new HashMap(); claims.put(role, role); return createToken(claims, userId, jwtProperties.getExpireSeconds()); } /** * 生成刷新令牌 */ public String createRefreshToken(String userId) { MapString, Object claims new HashMap(); claims.put(type, refresh); return createToken(claims, userId, jwtProperties.getRefreshExpireSeconds()); } private String createToken(MapString, Object claims, String userId, long expireSeconds) { Date now new Date(); Date expireDate new Date(now.getTime() expireSeconds * 1000); return Jwts.builder() .setClaims(claims) .setSubject(userId) .setId(UUID.randomUUID().toString()) .setIssuedAt(now) .setExpiration(expireDate) .signWith(key, SignatureAlgorithm.HS256) .compact(); } /** * 解析 Token返回 Claims无效或过期时抛出异常 */ public Claims parseToken(String token) { return Jwts.parserBuilder() .setSigningKey(key) .setClock(() - new Clock() { Override public Date now() { return new Date(System.currentTimeMillis() - jwtProperties.getClockSkew() * 1000); } }) .build() .parseClaimsJws(token) .getBody(); } public String getUserId(String token) { return parseToken(token).getSubject(); } }这里有几个设计细节值得说明createAccessToken和createRefreshToken使用不同的过期时间。刷新令牌的 Payload 中增加type: refresh标记用于识别令牌类型。UUID.randomUUID()生成的jti字段为后续 Redis 存储和吊销提供唯一标识。4.3 单 Token Redis 黑名单模式先介绍最简单可靠的优化方案Token 无状态签发但把“吊销”状态记录到 Redis。当用户退出登录或管理员强制下线时把 Token 的jti加入 Redis 黑名单设置过期时间等于 Token 剩余有效期。后续请求解析 Token 时先查黑名单命中则拒绝。创建TokenService.javapackage com.example.token.service; import com.example.token.config.JwtProperties; import com.example.token.util.JwtTokenUtil; import io.jsonwebtoken.Claims; import org.springframework.data.redis.core.StringRedisTemplate; import org.springframework.stereotype.Service; import java.util.concurrent.TimeUnit; Service public class TokenService { private static final String BLACKLIST_KEY_PREFIX token:blacklist:; private final StringRedisTemplate redisTemplate; private final JwtTokenUtil jwtTokenUtil; private final JwtProperties jwtProperties; public TokenService(StringRedisTemplate redisTemplate, JwtTokenUtil jwtTokenUtil, JwtProperties jwtProperties) { this.redisTemplate redisTemplate; this.jwtTokenUtil jwtTokenUtil; this.jwtProperties jwtProperties; } /** * 退出登录 / 吊销 Token */ public void revokeToken(String token) { Claims claims jwtTokenUtil.parseToken(token); String jti claims.getId(); long remainSeconds (claims.getExpiration().getTime() - System.currentTimeMillis()) / 1000; if (remainSeconds 0) { redisTemplate.opsForValue().set( BLACKLIST_KEY_PREFIX jti, 1, remainSeconds, TimeUnit.SECONDS ); } } /** * 检查 Token 是否已被吊销 */ public boolean isRevoked(String token) { Claims claims jwtTokenUtil.parseToken(token); return Boolean.TRUE.equals( redisTemplate.hasKey(BLACKLIST_KEY_PREFIX claims.getId())); } }这个方案的好处是日常请求仍然是纯无状态的只有退出登录时才访问 RedisRedis 压力很小而一旦需要吊销 Token也能实时生效。4.4 双 Token 机制访问令牌 刷新令牌单 Token 方案有一个体验问题如果访问令牌过期时间设置太短比如 30 分钟用户需要频繁重新登录设置太长比如 24 小时Token 泄露后的风险窗口又太大。双 Token 机制是经典解法Access Token访问令牌有效期较短30 分钟到 2 小时每次请求携带。Refresh Token刷新令牌有效期较长7 天到 30 天仅在 Access Token 过期后使用用于换取新的 Access Token。核心流程用户登录服务端同时返回 Access Token 和 Refresh Token。客户端请求接口时携带 Access Token。Access Token 过期后客户端携带 Refresh Token 请求/refresh接口。服务端验证 Refresh Token 有效后签发新的 Access Token同时可选择是否轮换 Refresh Token。Refresh Token 也过期后用户需要重新登录。在LoginController.java中实现登录与刷新接口package com.example.token.controller; import com.example.token.service.TokenService; import com.example.token.util.JwtTokenUtil; import io.jsonwebtoken.Claims; import org.springframework.web.bind.annotation.*; import java.util.HashMap; import java.util.Map; RestController public class LoginController { private final JwtTokenUtil jwtTokenUtil; private final TokenService tokenService; public LoginController(JwtTokenUtil jwtTokenUtil, TokenService tokenService) { this.jwtTokenUtil jwtTokenUtil; this.tokenService tokenService; } /** * 登录接口用户名密码校验略 */ PostMapping(/login) public MapString, String login(RequestParam String username, RequestParam String password) { // 实际项目中这里应该调用用户服务校验账号密码 // 这里直接模拟登录成功 String userId 10086; String role admin; String accessToken jwtTokenUtil.createAccessToken(userId, role); String refreshToken jwtTokenUtil.createRefreshToken(userId); MapString, String result new HashMap(); result.put(accessToken, accessToken); result.put(refreshToken, refreshToken); return result; } /** * 刷新令牌接口 */ PostMapping(/refresh) public MapString, String refresh(RequestHeader(Authorization) String refreshToken) { // 去掉 Bearer 前缀 if (refreshToken.startsWith(Bearer )) { refreshToken refreshToken.substring(7); } Claims claims jwtTokenUtil.parseToken(refreshToken); if (!refresh.equals(claims.get(type, String.class))) { throw new IllegalArgumentException(不是有效的刷新令牌); } String userId claims.getSubject(); String role String.valueOf(claims.get(role, String.class)); String newAccessToken jwtTokenUtil.createAccessToken(userId, role); MapString, String result new HashMap(); result.put(accessToken, newAccessToken); return result; } /** * 退出登录吊销刷新令牌和访问令牌 */ PostMapping(/logout) public String logout(RequestHeader(Authorization) String accessToken, RequestParam String refreshToken) { tokenService.revokeToken(accessToken.replace(Bearer , )); tokenService.revokeToken(refreshToken); return logout success; } }注意上面代码中刷新令牌里也保存了role字段。有人会问刷新令牌只是用来换新 Access Token 的为什么要重复存储角色这是为了在刷新时不必再查一次数据库或缓存。如果你更看重数据一致性比如用户角色中途被修改可以去掉刷新令牌中的role刷新时重新查询权限。4.5 拦截器中的 Token 校验与刷新联动创建AuthInterceptor.java统一拦截请求完成 Token 校验、黑名单检查、用户信息透传package com.example.token.interceptor; import com.example.token.service.TokenService; import com.example.token.util.JwtTokenUtil; import io.jsonwebtoken.Claims; import org.springframework.stereotype.Component; import org.springframework.web.servlet.HandlerInterceptor; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; Component public class AuthInterceptor implements HandlerInterceptor { private final JwtTokenUtil jwtTokenUtil; private final TokenService tokenService; public AuthInterceptor(JwtTokenUtil jwtTokenUtil, TokenService tokenService) { this.jwtTokenUtil jwtTokenUtil; this.tokenService tokenService; } Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录、刷新、退出接口 String uri request.getRequestURI(); if (uri.startsWith(/login) || uri.startsWith(/refresh)) { return true; } String authHeader request.getHeader(Authorization); if (authHeader null || !authHeader.startsWith(Bearer )) { response.setStatus(401); response.getWriter().write(Missing token); return false; } String token authHeader.substring(7); try { Claims claims jwtTokenUtil.parseToken(token); // 黑名单检查 if (tokenService.isRevoked(token)) { response.setStatus(401); response.getWriter().write(Token revoked); return false; } request.setAttribute(userId, claims.getSubject()); request.setAttribute(role, claims.get(role, String.class)); return true; } catch (Exception e) { response.setStatus(401); response.getWriter().write(Invalid token); return false; } } }再补充一个测试接口模拟获取当前登录用户信息package com.example.token.controller; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestAttribute; import org.springframework.web.bind.annotation.RestController; import java.util.HashMap; import java.util.Map; RestController public class UserController { GetMapping(/me) public MapString, Object me(RequestAttribute(userId) String userId, RequestAttribute(role) String role) { MapString, Object result new HashMap(); result.put(userId, userId); result.put(role, role); return result; } }记得在配置类中注册拦截器package com.example.token.config; import com.example.token.interceptor.AuthInterceptor; import org.springframework.context.annotation.Configuration; import org.springframework.web.servlet.config.annotation.InterceptorRegistry; import org.springframework.web.servlet.config.annotation.WebMvcConfigurer; Configuration public class WebConfig implements WebMvcConfigurer { private final AuthInterceptor authInterceptor; public WebConfig(AuthInterceptor authInterceptor) { this.authInterceptor authInterceptor; } Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(authInterceptor) .addPathPatterns(/**) .excludePathPatterns(/login, /refresh); } }4.6 运行与验证启动 Spring Boot 应用后用 curl 做一组简单的验证。登录获取 Tokencurl -X POST http://localhost:8080/login?usernameadminpassword123456预期返回{ accessToken: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMDA4NiIsInJvbGUiOiJhZG1pbiIsImp0aSI6ImEzZjljMWUyLTRiN2QtNGY1YS05ZTJjLTdkMGExYjJjM2Q0ZSIsImlhdCI6MTcwMDAwMDAwMCwiZXhwIjoxNzAwMDA3MjAwfQ.signature, refreshToken: eyJhbGciOiJIUzI1NiJ9.eyJ0eXBlIjoicmVmcmVzaCIsInN1YiI6IjEwMDg2IiwianRpIjoiYjRjMmE4YjAtOWQxMC00YzNhLWI5MWEtNjU2ZjA0M2Y1YzBkIiwiaWF0IjoxNzAwMDAwMDAwLCJleHAiOjE3MDA2MDQ4MDB9.signature }带 Access Token 访问/mecurl -X GET http://localhost:8080/me \ -H Authorization: Bearer accessToken预期返回{ userId: 10086, role: admin }退出登录后再用同一个 Token 访问应该收到 401 和Token revoked提示。5. 常见问题与排查思路Token 相关的报错在前后端联调时非常常见很多问题看着是“Token 失效”根因各不相同。问题现象常见原因解决思路Token 解析抛出JwtExceptionKey 长度不足或 Secret 不一致确认 Base64 解码后字节数是否达到 32 字节签发和解析是否使用同一个密钥Token 明明没过期却被判无效服务器时钟不同步使用 NTP 同步时间或在 JJWT 中设置 Clock 偏移Access Token 过期后刷新失败Refresh Token 被当作 Access Token 使用检查type声明确认刷新接口校验了令牌类型用户退出登录后 Token 还能用没有做吊销或黑名单处理使用 Redis 存储 jti 黑名单设置过期时间等于 Token 剩余时长Header 太长导致网关 413Payload 字段过多精简自定义声明只保留 userId、role 等必要字段HS256 密钥泄露导致 Token 可伪造密钥硬编码在代码中改为环境变量或配置中心存储定期轮换密钥刷新 Token 被重放攻击同一 Refresh Token 被多次使用刷新令牌加入版本号或一次性使用机制例如刷新后废弃旧令牌以下是几个高频报错的详细排查过程。报错 1io.jsonwebtoken.security.WeakKeyException这个异常表示签名密钥太弱。HS256 要求密钥至少 256 位32 字节排查时先检查配置的 Secret 经过 Base64 解码后是否满足长度要求echo -n 你的Secret | base64 -d | wc -c如果不足 32 字节需要重新生成。推荐使用下面命令生成一个足够强度的随机密钥openssl rand -base64 32报错 2io.jsonwebtoken.ExpiredJwtException表示 Token 已经过期。排查顺序先看服务器当前时间是否和签发时间正常。检查 JWT 的exp时间戳确认签发时设置的过期时间是否符合预期。如果服务器时间有偏差在解析时设置setClock允许偏移。如果是正常的过期前端应该走刷新流程而不是重新登录。报错 3Redis 中黑名单 Key 数量持续增长如果黑名单 key 设置了过期时间却仍然增长很快可能是两个原因Token 的 jti 重复了导致多个 Token 复用同一个 key。Redis 的过期时间没有设置成功检查代码中是否传入了TimeUnit.SECONDS。生产环境建议给 Redis 配置内存淘汰策略并定期监控token:blacklist:*前缀的 key 数量。报错 4刷新接口返回“不是有效的刷新令牌”通常是因为刷新接口拿到的仍然是 Access Token。前后端对接时必须明确区分两个 Token 的用途。如果在拦截器中统一校验了 Token还需要确保/refresh路径被放行否则刷新请求根本到不了控制器。6. 最佳实践与工程建议经历过 Token 方案从简单到复杂、再到踩坑修复的完整过程总结出下面几条可以直接落地的工程建议。6.1 Token 安全基线密钥分级管理开发环境、测试环境、生产环境使用不同的密钥生产密钥通过配置中心或环境变量注入不入代码库。定期轮换密钥如果使用 HS256密钥泄露的风险随着暴露时间增加。有条件的话每 3 到 6 个月轮换一次。使用 HTTPSToken 通过请求头传输如果链路是明文 HTTP抓包即可拿到 Token再强的签名算法也保护不了核心数据。设置合理的过期时间Access Token 建议 15 分钟到 2 小时Refresh Token 建议 7 天到 30 天。过期时间越短越安全但用户体验越差需要寻找平衡点。6.2 性能优化建议精简 Payload 能显著降低请求体积特别是移动端弱网环境下每个请求省 200 字节对体验的改善是实打实的。签名算法选择要考虑并发场景HS256 的验证性能优于 RS256 和 ES256但安全性上非对称算法更优。具体取舍可以参考单体应用选 HS256微服务网关统一认证选 RS256。避免每次请求都查询数据库用户角色、权限这类数据可以放到 Redis 缓存按用户 ID 维度设置 5 到 10 分钟过期。6.3 可维护性建议统一 Token 工具类不要在每个 Controller 里直接调用 JJWT 的 API统一封装后后续更换签名算法或密钥存储方式时只改一个类。配置项集中在配置类中过期时间、密钥、时钟偏移全部通过配置注入方便不同环境差异化调整。记录 Token 签发的审计日志大用户量场景下建议记录 Token 的 jti、用户 ID、签发时间、过期时间、IP 等信息便于问题回溯。版本兼容如果团队中同时存在多个服务升级 JJWT 版本时要注意兼容性先用测试环境验证签名和解析逻辑。6.4 生产环境注意事项上线前要确认网关层对请求头的长度限制部分 Nginx 配置默认large_client_header_buffers较小可能导致 JWT 请求头被截断。Redis 不可用时要设计降级策略黑名单查询失败时建议“宁可暂时放行也不要全部拒绝”但要结合业务安全性评估。刷新令牌接口要做限流和异常检测防止被批量调用。涉及用户账号封禁、权限变更等操作一定要同步吊销相应 Token不要只依赖 Token 过期。7. 总结与学习路线这篇 Token 优化手册从 JWT 的基本结构讲起覆盖了 Payload 精简、签名算法选择、双 Token 机制、Redis 黑名单、时钟偏移处理等核心内容。完成这套实践你应该能够理解 JWT 的 Header/Payload/Signature 三部分各自的作用与体积来源。区分 HS256 与 RS256 的适用场景能够在不同架构下做出合理选择。设计出短小、安全、支持吊销和刷新的 Token 方案。通过 Redis 黑名单解决“退出登录后 Token 仍有效”的难题。面对常见 Token 报错能够按原因快速定位并修复。接下来可以继续学习的方向包括OAuth2.0 与 OIDC 协议、网关层统一鉴权设计、Spring Authorization Server 的使用、自研认证中心的架构演进。如果工作中遇到“Token 越写越长”“刷新逻辑混乱”“用户权限变更不生效”这类问题建议先从本文第 3 节的字段精简和第 4 节的双 Token 改造入手通常能解决大部分痛点。如果本文对你有帮助可以收藏备用。后续遇到 Token 相关的业务问题欢迎留言讨论。
