必须用原子命令如set(key,value,timeout,unit)或setIfAbsent()写入Token，避免set()+expire()导致的僵尸凭证；推荐Hash结构存储Token元信息，登出需维护logout:track:{userId}时间戳并校验iap，键名应语义清晰且设TTL。
没有“最佳方案”，只有“适配你场景的可靠方案”。直接用 stringRedisTemplate.opsForValue().set() 存 Token 是最常见错误起点——它看似简单，但会在高并发、Token 刷新、用户登出、集群扩容等真实环节翻车。
为什么 set() + expire() 组合在生产环境不安全
Redis 的 set() 和 expire() 是两个独立命令，非原子执行。当服务刚写入 Token，还没来得及设置过期时间就宕机或网络中断，这个 Token 就会永久滞留 Redis，变成“幽灵凭证”。
更隐蔽的问题是：如果并发请求同时调用登录接口，set() 可能覆盖前一个有效 Token，导致旧 Token 失效（影响正在刷新的客户端），或新 Token 被覆盖（引发 401）。
- 必须用
setIfAbsent()或set(key, value, duration, TimeUnit)原子写入，避免覆盖 - 过期时间必须在写入时一并指定，不能分两步
- 若需支持 Token 刷新（如滑动过期），不能只依赖固定 TTL，得配合
expire()动态延长，但必须确保刷新操作本身幂等
Token 存储结构选 String 还是 Hash？
单纯存 Token 字符串用 String 类型足够，但一旦需要附带用户 ID、登录时间、设备指纹、权限列表等元信息，String 就会迅速失控。
推荐用 Hash 结构存完整上下文，例如键为 login:token:{token}，值为 {"userId":"123","role":"USER","lastActive":"1720851420"}：
- 单次读取即可拿到全部元数据，避免多次
get()拼装 - 更新部分字段（如
lastActive）只需hSet()，不影响其他字段 - 内存占用比序列化 JSON 字符串更低（Redis Hash 有专门优化）
- 但注意：Spring Data Redis 的
hashOperations不支持直接设 TTL，需用expire()单独操作整个 key
如何安全地实现 Token 刷新与登出
登出不是简单 delete(tokenKey) 就完事。如果用户在多端登录，仅删 Token 会导致其他设备仍可访问，且无法阻止已签发的 JWT 继续校验通过（除非搭配黑名单）。
真正可控的做法是：维护一个“Token 状态映射”，例如用 Set 存已登出 Token 列表，或用 String 存“最后登出时间戳”，校验时比对 Token 中的 iap（签发时间）是否早于该时间戳。
- 登出时：写入
logout:track:{userId}=System.currentTimeMillis()，并设 7 天过期 - 鉴权时：先查 Token 是否存在，再查其
iap是否<=用户的最后登出时间戳 - 刷新 Token 时：必须生成全新随机字符串（不能复用旧 token），并同步更新
logout:track:{userId}时间戳，否则旧 Token 仍可能被重放
Redis 键设计必须考虑运维和排查成本
键名不是越短越好，而是要让人一眼看懂用途、归属、生命周期。比如 auth:token:abc123 比 t:abc123 更利于排查；auth:logout:track:123 明确表达了这是用户 123 的登出追踪点。
还要预留命名空间隔离能力：
- 开发/测试/生产环境用不同
database或加前缀，如dev:auth:token: - 不同业务线（如 app/web/admin）用不同一级前缀，避免 key 冲突和误删
- 所有键必须设 TTL，严禁永不过期；线上建议统一用
Duration.ofMinutes(30)起步，再按实际活跃度调优
最常被忽略的一点：Redis 内存淘汰策略（maxmemory-policy）必须设为 allkeys-lru 或 volatile-lru，否则当内存满时，可能把还在用的 Token 清掉，而把已过期却没被及时扫描的 key 留着——这不是 bug，是配置失配。
