jwt密钥必须是base64解码后≥32字节的合法密钥，验证时须显式指定签名算法并阻断失败请求流，且jjwt-api与jjwt-impl版本必须严格一致。
JWT生成时密钥必须是Base64编码的SecretKey，不能直接用字符串
很多人用Keys.hmacShaKeyFor("my-secret".getBytes())，结果报InvalidKeyException: Invalid key length。这是因为hmacShaKeyFor要求输入的byte数组长度必须符合HMAC算法要求（如HS256需≥256位=32字节），而"my-secret"只有10字节。
正确做法是用MacProvider.generateKey()生成合规密钥，或手动构造Base64编码的32字节密钥：
- 推荐：用
Keys.hmacShaKeyFor(Decoders.BASE64.decode("your-base64-secret=="))，确保secret是合法Base64字符串且解码后长度≥32字节 - 开发阶段可临时用
MacProvider.generateKey()生成随机密钥，但别硬编码进代码 - Spring Boot中建议配置
jwt.secret=base64-encoded-32-byte-key，再在代码里Decoders.BASE64.decode()解析
验证JWT时要显式指定签名算法，否则默认只认HS256
如果Token是用ES256（ECDSA）签发的，但验证时没指定算法，Jwts.parserBuilder().build().parseClaimsJws(token)会直接抛UnsupportedJwtException: Signed JWTs must be parsed using a JWSAlgorithm-specific parser。
必须用setSigningKey + requireAlgorithm双保险：
立即学习“Java免费学习笔记（深入）”；
- HS系列：用
.setSigningKey(key).requireAlgorithm(SignatureAlgorithm.HS256) - RS/ES系列：需先加载公钥，再用
.setSigningKey(publicKey).requireAlgorithm(SignatureAlgorithm.RS256) - 生产环境别依赖
parserBuilder().build()的自动算法推断——它不安全也不可靠
Spring过滤器中验证失败要提前return，不能继续chain.doFilter
常见错误是在doFilter里验证JWT失败后只打印日志、设置响应状态码，却忘了return，导致请求仍进入后续拦截器甚至Controller，造成越权访问。
标准拦截逻辑必须阻断执行流：
- 调用
response.setStatus(HttpServletResponse.SC_UNAUTHORIZED)后立即return - 不要用
chain.doFilter(request, response)包裹在try-catch里“兜底”——异常不该是控制流程的手段 - 如果用了
OncePerRequestFilter，记得重写shouldNotFilter跳过静态资源路径，避免对/css/或/favicon.ico也校验Token
jjwt-api和jjwt-impl版本必须严格一致，否则ClassCastException频发
比如jjwt-api:0.11.5 + jjwt-impl:0.11.2混合使用，解析Token时可能抛java.lang.ClassCastException: io.jsonwebtoken.impl.DefaultJwtParserBuilder cannot be cast to io.jsonwebtoken.JwtParserBuilder——这是典型的SPI实现类不匹配。
Maven依赖必须锁死同一版本：
- 用BOM管理：引入
jjwt-bom并声明importscope - 手动声明时，三个核心模块
jjwt-api、jjwt-impl、jjwt-jackson（或jjwt-gson）版本号必须完全相同 - 特别注意：Spring Boot 2.6+默认带的
jjwt版本较老，要显式排除父POM传递依赖
JWT本身不加密payload，敏感字段别往claims里塞；时间戳校验（exp/nbf）默认开启，但时钟偏移需用setAllowedClockSkewSeconds微调；这些细节不写进过滤器逻辑，上线后就只能靠日志猜问题。
