Token黑名单必须用Redis而非内存或数据库，因需高频读写、低延迟、自动过期及跨进程共享：内存map多实例下失效；MySQL写入慢且无原生TTL；Redis的SET+EX命令天然支持带过期时间的单次操作。
为什么 Token 黑名单必须用 Redis 而不是内存或数据库
因为黑名单需要高频读写、低延迟、自动过期，且必须跨进程共享。内存（map）在多实例部署下完全失效；MySQL 写入慢、无原生 TTL 支持，会拖垮鉴权链路；而 Redis 的 SET + EX 命令天然适配“存一个 token、设 72 小时过期”这种模式，单次操作平均耗时
常见错误是把黑名单当“永久记录”处理——比如用 HSET 存 token 和注销时间，再靠后台任务扫描清理。这不仅冗余，还引入竞态：用户刚登出，另一个请求已携带该 token 进入校验流程。正确做法是：登出时直接 SET token "" EX 259200（72 小时），校验时只做一次 EXISTS 查询。
登出时如何安全写入黑名单（含 JWT jti 字段必要性）
JWT 必须包含唯一标识字段 jti（JWT ID），不能依赖 sub 或 user_id。否则同一用户多次登录生成的多个有效 token，登出其中一个就会误杀全部。
-
jti应为 UUIDv4 或加密哈希（如sha256(tokenString)），确保每个 token 独立可标识 - 登出接口中，从 token 解析出
jti，然后执行：redisClient.Set(ctx, "blacklist:"+jti, "", 72*time.Hour)
- 务必检查
Parse返回的token.Valid，避免解析失败的垃圾字符串被误加入黑名单 - 不要在登出时删 token，而是设过期——Redis 的
EX是原子操作，不存在“写入成功但过期失败”的中间态
鉴权中间件里怎么高效查黑名单
校验逻辑必须放在 JWT 签名和过期验证之后，否则可能对无效 token 做无谓的 Redis 查询。典型顺序是：解析 → 验签 → 检 exp → 提取 jti → EXISTS blacklist:jti → 拒绝已黑 token。
关键细节：
Token 消耗追踪工具。当用户需要监控 API token 使用情况、生成每日/每周消耗报告、分析使用趋势时使用此 Skill。功能包括：自动记录每次对话的 token 消耗、生成数据表格报告、计算使用趋势和预测、支持定时推送日报。
- 使用
redisClient.Exists(ctx, "blacklist:"+jti)，返回int64，非零即存在 - 不要用
Get再判空字符串——多一次网络往返，且语义不清 - 如果 Redis 查询超时（建议设
ctx, cancel := context.WithTimeout(context.Background(), 50*time.Millisecond)），应拒绝请求（fail-close），而非放行——宁可误拦，不可漏放 - 生产环境建议用连接池，并开启
redisClient.Options().MinIdleConns = 10避免冷启动抖动
Redis 键设计与内存控制的实际坑点
键名别用 blacklist:token_xxx 这种裸 token，容易被扫描或泄露。统一加前缀+哈希化更稳妥：blacklist:jti_ + base64.RawURLEncoding.EncodeToString(sha256.Sum256([]byte(jti)).[:])。
但更现实的做法是：接受 blacklist: + jti（只要 jti 本身是随机 UUID），并配合 Redis 的内存淘汰策略：
- 设置
maxmemory-policy volatile-lru，确保带过期时间的 key 优先被淘汰 - 定期用
redis-cli --scan --pattern 'blacklist:*' | wc -l监控总量，超 100 万需告警——说明大量 token 未自然过期（可能是前端没调登出，或 jti 生成逻辑有 bug） - 绝不使用
KEYS命令遍历，它会阻塞 Redis 主线程
最易被忽略的一点：JWT 的 exp 和黑名单过期时间不是二选一，而是叠加生效。哪怕 token 还剩 1 分钟过期，只要它已在黑名单中，就必须拒绝——注销动作的语义优先级高于原始有效期。
