jwt鉴权优化需四步：缓存密钥字节、预热时间戳并禁用默认校验、中间件复用解析结果、黑名单改用布隆过滤器；避免全局注册与重复解析，可将耗时从0.18ms降至0.03ms。
JWT解析耗时高，尤其在HS256验证阶段
标准 jwt.Parse() 每次调用都会重新计算 HMAC 签名，即使密钥和算法固定。实测单次验证平均耗时 0.05ms（HS256），看似微小，但在 10k QPS 下，每秒就多出 500ms 的纯 CPU 开销。
- 避免在
func(token *jwt.Token) (interface{}, error)回调里重复构造密钥字节切片，应提前var secret = []byte("your_secret_key")缓存 - 不要在每次验证时都调用
time.Now().Unix()做 exp 校验——改用token.Claims.(jwt.MapClaims)["exp"]取值后与预热的当前时间戳比对 - 若使用
github.com/golang-jwt/jwt/v4，务必禁用默认的VerifyExp和VerifyIat，自己做轻量校验：它们内部会反复调用time.Now()并触发逃逸
Token重复解析：中间件未复用已解析结果
Gin 中间件链是线性的，但很多鉴权中间件在后续业务 handler 里又调了一次 ValidateToken()，导致同一请求 Token 被解析两次。更隐蔽的是，有些日志中间件或审计中间件也悄悄读了 Authorization Header 并尝试解析。
- 在鉴权中间件中解析成功后，立刻调用
c.Set("user_id", claims["user_id"].(string))，后续 handler 直接用c.GetString("user_id") - 禁止在非鉴权中间件里调用任何 JWT 解析逻辑；如需用户信息，统一从
c.Get()获取 - 给
*gin.Context加个扩展方法（如c.UserID()），内部封装c.Get("user_id")类型断言，避免散落各处的重复取值
Redis/DB查白名单或黑名单引入毫秒级延迟
为支持 Token 吊销，常在鉴权中间件里查 Redis 判断是否在黑名单。但一次 Redis GET 就可能耗时 0.5–2ms，直接把 P99 延迟从亚毫秒拉到毫秒级，完全抵消 JWT 无状态优势。
- 黑名单场景改用布隆过滤器（Bloom Filter）做前置快速拒绝：Redis +
bf.exists，误判率可控且耗时稳定在 0.1ms 内 - 白名单（如租户配额）可预加载到内存 map，按租户 ID 分片缓存，TTL 设为 5–10 分钟，用 goroutine 定期刷新
- 绝对避免在鉴权中间件中执行同步 DB 查询；如有必要，必须加超时（
context.WithTimeout(c.Request.Context(), 5*time.Millisecond)）并设 fallback 默认放行
中间件注册位置不当放大无效开销
把鉴权中间件挂到 r.Use() 全局链上，会导致 /health、/metrics、静态资源等所有路径都走一遍 JWT 解析，毫无意义却白白消耗 CPU。
- 只在真正需要鉴权的路由组注册：用
api := r.Group("/api/v1", authMiddleware)，而非r.Use(authMiddleware) - 对 OPTIONS 预检请求直接跳过鉴权：
if c.Request.Method == "OPTIONS" { c.Next(); return }，避免解析无效 header - 若网关还代理前端资源（如 /assets/），应在路由匹配前用
r.NoRoute()或正则路由排除，不让请求进入中间件链
