Token黑名单机制需用trim+去Bearer后的parsedToken.Raw作key，配sync.RWMutex+map[string]struct{}；须对齐JWT过期时间，通过Redis TTL或本地定时清理；登出只加黑名单不删Token，并同步清客户端存储。
Token 黑名单机制不是“加个 map 就完事”，核心难点在于：如何在高并发下快速判断 Token 是否失效，同时不拖慢正常请求；以及——黑名单数据怎么更新、何时失效、要不要持久化。
为什么不能只用 map[string]bool 存 Token 字符串
看似简单，但直接存原始 tokenString 会踩三个坑：
- JWT 每次解析后可能带空白或换行（尤其从
Authorization: Bearer xxx提取时），导致相同 Token 多次存入 - 没做标准化处理，
Bearer token123和token123被当成两个不同值 - 没剥离签名前的原始字符串——
Parse()后的token.Raw才是唯一可比对的标识，而不是tokenString本身
正确做法是：提取时统一 trim + 去掉 Bearer 前缀；验证时用 parsedToken.Raw 作为黑名单 key。
sync.RWMutex + map[string]struct{} 是当前最稳的选择
除非你每秒要增删上万条 Token，否则别碰 sync.Map。它在读多写少场景下比加锁的普通 map 更慢、内存占用更高。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 初始化：
blacklist := make(map[string]struct{})，搭配sync.RWMutex控制并发 - 添加：
mu.Lock(); blacklist[tokenRaw] = struct{}{}; mu.Unlock() - 查询：
mu.RLock(); _, blocked := blacklist[tokenRaw]; mu.RUnlock() - 不要在查询路径里做
len(blacklist)或遍历——这些操作会阻塞写，QPS 上千时毛刺明显
黑名单怎么和 JWT 过期时间对齐
Token 自身有 exp，黑名单却没自动过期能力。硬留着已过期的 Token 在 map 里，只会让内存缓慢上涨。
可行方案只有两个：
- 配合 Redis：把黑名单写进 Redis，设 TTL 等于 Token 的剩余有效期（需在签发时计算
time.Until(expTime)） - 本地缓存 + 定期清理：启动 goroutine 每 5 分钟扫一次 map，用
jwt.ParseUnverified快速解出exp字段，删掉已过期的项（注意别锁太久）
纯内存方案不做清理，跑一周后 map 可能存几万条无效记录——而真正需要拦截的，永远只是最近 10 分钟内主动注销的那几十个。
登出时该不该立即删 Token，还是只加黑名单
必须只加黑名单，不能删 Token 本身。因为：
- JWT 是无状态的，服务端根本不存原始 Token 字符串，所谓“删”只是加一条记录
- 如果登出接口返回后客户端仍用旧 Token 发请求，你得拦住它——这正是黑名单存在的唯一意义
- 有些场景（如管理员强制踢人）需要异步触发登出，此时 Token 可能还在传输途中，加黑名单是最及时的干预手段
真正容易被忽略的是：登出响应里别返回 200 OK 就完事。要同步清除客户端的本地存储（比如前端清 localStorage），并确保后续所有中间件都走同一套黑名单校验逻辑——否则会出现“登出成功但还能调接口”的错觉。
