jwt无法主动失效，必须用黑名单机制实现立即作废：鉴权时先完整解析校验签名和exp，再查黑名单；清理时用jwt.parseunverified快速提取exp并设动态ttl；登出仅写入tokenraw或jti，不干涉客户端存储。
JWT 本身无法主动失效，Gin 框架里想让 token「立刻作废」，唯一靠谱的路就是加黑名单——但直接往 map 或 Redis 里一塞就完事？错，90% 的线上事故都出在没对齐过期时间、锁粒度失控、或拦截逻辑漏校验。
为什么 jwt.ParseUnverified 必须用在黑名单清理，而不是鉴权主路径
鉴权时若用 jwt.ParseUnverified 提取 exp 字段做黑名单比对，等于放弃签名验证——攻击者可伪造任意 exp 值绕过检查。正确做法是：只用 jwt.ParseWithClaims 完整校验签名和有效期，通过后再查黑名单。
- 黑名单清理阶段才用
jwt.ParseUnverified：它不验签名，快，适合后台定时扫描 - 主请求链路必须走完整解析，否则
exp和jti都不可信 - 别在
ParseUnverified后直接删 map key——得先加读锁，再判断exp ，最后解锁后删
Redis 黑名单 TTL 怎么设才不爆内存
如果往 Redis 存 blacklist:{jti} 但不设 TTL，一周后可能积压数万条已自然过期却仍占内存的 key。TTL 不该硬写成固定值（比如 24h），而应动态计算：
- 写入时调
redis.SetEX(ctx, "blacklist:"+claims.JTI, "", time.Until(claims.ExpiresAt.Time)) -
claims.ExpiresAt.Time来自jwt.ParseWithClaims解析后的结构体，不是原始字符串 - 注意：
time.Until返回负数时（已过期），Redis 会拒绝设置，此时无需写入——该 token 本就该被exp拦住 - 避免用
SET+ 单独EXPIRE两步操作，存在竞态窗口
Gin 中间件里怎么安全提取并校验黑名单
别在中间件开头就调 c.GetHeader("Authorization") 后直接进黑名单查询——得先确认 token 格式合法、长度合理、且未过期，否则无效请求也会打到存储层。
- 先做基础过滤：
if len(tokenString) - 用
jwt.ParseWithClaims解析，捕获jwt.ValidationErrorExpired等错误，过期的直接返回，不查黑名单 - 仅当
token.Valid == true且claims.JTI != ""时，才查 Redis 或本地 map - 查 Redis 推荐用
redis.Exists(ctx, "blacklist:"+claims.JTI)，比Get更轻量
登出接口只做一件事：blacklist[tokenRaw] 写入
用户点「退出登录」，后端唯一该干的事，就是把当前请求里的原始 token 字符串（tokenRaw）写进黑名单。其他全是干扰项：
- 不要删客户端 localStorage 或 cookie——那是前端职责，服务端无权干涉
- 不要清 session 或数据库 token 字段——JWT 本来就没服务端 session
- 不要试图解析 token 后取
user_id再删全量设备 token——除非你明确支持「踢出所有设备」，否则这是过度设计 - 如果要用
jti而非tokenRaw作 key，确保签发时已填claims.JTI = uuid.NewString()，否则 fallback 到base64.RawURLEncoding.EncodeToString([]byte(tokenRaw))
真正容易被忽略的是时间对齐：Redis 的系统时间和服务端时间若差 2 秒，TTL 就可能提前失效；本地 map 清理 goroutine 若用 time.Sleep 轮询，高并发下锁竞争会让毛刺飙升——这些细节不压测根本看不出问题。
