高并发场景下 JWT 鉴权性能瓶颈可通过引入本地缓存存储解析后的用户信息或 Token 状态来优化，适用于读多写少且对实时注销要求不苛刻的场景，主要风险在于缓存一致性导致的安全滞后。
先说结论：本地缓存能显著减少重复解密消耗和远程查询 IO，但必须严格控制缓存 TTL 以匹配 Token 有效期。
- 先定位：确认瓶颈是 CPU 解密耗时还是远程用户状态查询耗时
- 先做：引入进程内缓存（如 Caffeine/Guava）并设置短 TTL
- 再验证：监控缓存命中率与注销生效延迟是否在业务允许范围内
快速处理思路
如果不适合直接执行命令，可按照以下架构调整思路处理：在网关或认证服务层增加本地缓存层，缓存键为 Token 指纹或 JWT ID，值为解析后的用户 Claims 信息，缓存过期时间必须小于或等于 JWT 的 exp 时间。
为什么会这样
性能瓶颈通常来自重复的签名验证计算和频繁的状态查询。
JWT 本身是无状态的，每次请求都需要验证签名（尤其是 RS256 非对称加密算法消耗较多 CPU），如果业务还需要查询数据库或 Redis 确认用户是否被封禁，会产生网络 IO 开销。公开资料中没有看到可靠的量化数据表明具体提升比例，因为性能增益取决于令牌大小、加密算法、硬件配置和并发模型，但减少重复计算和远程 IO 是公认的优化方向。
分步处理
按照以下步骤实施本地缓存优化，每一步都需要确认配置正确后再进入下一步。
第一步：选择缓存组件
在 Java 体系中推荐使用 Caffeine 或 Guava Cache，Go 体系可使用 BigCache 或 FreeCache。避免使用分布式缓存（如 Redis）作为本层优化，因为网络 IO 依然是瓶颈。
第二步：配置缓存策略
设置缓存过期时间（TTL）。例如 JWT 有效期为 30 分钟，本地缓存 TTL 建议设置为 5-10 分钟，强制客户端重新认证或刷新缓存，防止缓存数据长期滞留。
// 示例：Caffeine 配置思路（伪代码）
Cache<String, Claims> cache = Caffeine.newBuilder()
.maximumSize(10_000)
.expireAfterWrite(10, TimeUnit.MINUTES)
.build();第三步：处理缓存失效
对于注销或权限变更场景，本地缓存无法即时感知。需要在 Token 中引入版本号（version），用户修改密码或权限时递增版本号，缓存键包含版本号，旧缓存自然失效。
怎么验证是否生效
通过监控指标和日志确认优化效果，不要仅凭感觉判断。
检查缓存命中率
查看缓存组件的监控指标（如 hitRate），高并发下命中率应稳定在较高水平。如果命中率低，检查缓存键生成逻辑是否一致。
对比响应延迟
在相同压测条件下，对比开启缓存前后的 P99 延迟。注意观察 CPU 使用率是否下降，如果 CPU 未下降，说明瓶颈可能在 IO 而非解密。
验证注销时效
执行用户注销操作，记录从注销到请求被拒绝的时间差。该时间差应小于本地缓存 TTL，否则视为安全风险。
常见坑
实施本地缓存时容易忽略以下风险点，需提前评估。
内存溢出风险
本地缓存占用堆内存。如果缓存键未设置最大数量限制，高并发下大量不同 Token 可能导致 OOM。必须配置 maximumSize。
多实例一致性问题
本地缓存仅对当前进程有效。在多实例部署下，用户请求落到不同实例可能导致鉴权状态不一致。需配合短期 TTL 或广播失效消息。
误缓存无效 Token
不要缓存签名验证失败的 Token。仅缓存验证通过且未过期的 Token 信息，避免缓存穿透或存储垃圾数据。
常见问题
本地缓存会影响 Token 注销的实时性吗？
会影响，注销生效会有延迟。
延迟时间取决于本地缓存的剩余 TTL。如果对实时注销要求极高，建议缩短 TTL 或改用集中式黑名单查询。
应该缓存整个 JWT 字符串还是解析后的内容？
建议缓存解析后的 Claims 内容。
缓存解析后的对象可以节省每次请求的解密和解析 CPU 开销，缓存原始字符串仅节省 IO 但无法节省解密计算。
多服务实例部署时本地缓存怎么同步？
本地缓存默认不同步，需接受短暂不一致。
通过设置较短的 TTL 来控制不一致窗口，或者通过消息队列广播失效事件，但后者会增加系统复杂度。
HS256 和 RS256 算法对缓存优化有影响吗？
有影响，RS256 更需要缓存优化。
RS256 是非对称加密，验证消耗 CPU 远高于 HS256。如果使用的是 RS256，本地缓存带来的 CPU 节省效果更明显。