缓存失效主因是键中混入动态token导致key永不重复；应剥离token，改用user_id等稳定标识构建key，并验证key是否真动态、排查token来源、区分鉴权与缓存维度。
缓存键里混了动态 Token，相当于给每个请求都生成一个新 key，缓存自然形同虚设——不是失效快，是压根没被复用过。
看键是否真的“动态”
先确认 Token 是不是真在 key 里。比如你写的是 user:token_abc123:profile，其中 abc123 每次都变，那这个 key 就永远不重复。用 redis-cli 执行 SCAN 0 MATCH "user:token_*:profile"，如果返回几十上百个不同 key，基本坐实问题。
- 查最近 5 分钟高频访问的业务逻辑，抓几条真实请求，比对它们生成的缓存 key 字符串
- 重点检查 Token 来源：是前端传的 session token？JWT payload 里的 jti？还是临时生成的一次性 nonce？
- 如果是 OAuth2 的 access_token，它本就不该进缓存 key——应该用用户 ID、设备 ID 或 scope 组合来抽象
区分“身份标识”和“会话凭证”
Token 是用来鉴权的，不是用来区分缓存维度的。真正决定缓存内容是否可共享的，是数据归属和语义一致性。
- 用户头像、基础资料 → 缓存 key 应基于 user_id，不是 token
- 个性化推荐结果 → 可加 user_id + ab_test_group，但避免塞 device_fingerprint 或 request_id
- 临时上传凭证（如 presigned URL token）→ 这类根本不该缓存，或只做极短 TTL（
用 Redis 命令快速验证键稳定性
连上生产 Redis 实例，执行三步验证：
- EXISTS user:1001:profile —— 看是否存在；隔 2 秒再执行一次，看是否仍存在
- TTL user:1001:profile —— 查剩余时间，若为 -1（永不过期）或远大于预期（如 86400），说明 key 没被频繁覆盖
- SCAN 0 MATCH "user:*:profile" COUNT 100 —— 如果返回大量带随机字符串的 key（如 user:xyz789:profile），就是 Token 泄漏进 key 的铁证
修复建议：两级抽象法
把“谁在访问”和“访问什么”拆开：
- 第一层（认证层）：用 Token 校验权限，通过后立即提取稳定标识（如 sub 字段、数据库 user_id）
- 第二层（缓存层）：所有 key 都基于该稳定标识构建，例如 profile:u1001、cart:u1001:v2
- 额外加一层保护：在代码里对 key 字符串做白名单校验，拒绝包含 uuid、jwt、base64 等特征子串的 key 写入
