关键是要为每个用户生成唯一缓存键，必须嵌入user_id或token哈希等唯一标识，采用user_{id}:profile格式，禁用固定字符串，并在登出时批量清理user_{id}*键。

核心问题是缓存键缺乏区分度，导致多个用户共用同一缓存项。解决的关键是让每个用户的请求生成唯一、可隔离的缓存键。

缓存键必须携带用户标识

不能用固定字符串（如"user"或"currentUser"）作为键名。必须将当前用户的唯一标识（如 user_id、tenant_id 或 auth_token 的哈希）嵌入键中。

• 推荐格式：user_{id}:profile、tenant_{tid}:dashboard
• 避免拼接原始用户名或邮箱——含特殊字符或空格时易出错；优先用数字 ID 或标准化后的 token 哈希
• 多租户系统中，还需加入租户字段，否则 A 租户数据可能被 B 租户读取

动态生成键，不依赖全局变量

不要在缓存操作前手动设置一个全局 currentUser 变量再拼键。应在每次请求上下文中实时提取用户身份，并构造键。

• 例如在 Express 中从 req.user.id 获取；在 Spring Boot 中通过 SecurityContext 获取 Authentication
• 使用工具函数统一生成键，比如：generateCacheKey("user_profile", { userId: 123 })
• 禁止在中间件外硬编码键名，防止遗漏或误用

登出或切换用户时主动清理

仅靠键隔离还不够。用户登出后，其专属缓存若长期残留，可能被后续登录的同设备用户意外复用（尤其在共享 Redis 实例时）。

• 登出接口中调用 del user_{id}* 批量清除该用户相关键
• 若使用 JWT，可在 token 过期时触发清理任务（配合 Redis 的 key 过期事件或定时扫描）
• 敏感数据（如余额、订单列表）建议设置较短 TTL，双重降低风险

验证缓存是否真正隔离

上线前做简单交叉测试：用户 A 登录 → 请求个人数据 → 用户 B 登录 → 请求个人数据 → 检查两者返回内容是否独立且正确。

• 用 Redis CLI 直接查看键名：KEYS user_*，确认无重复或覆盖现象
• 日志中记录缓存键生成过程，便于故障时回溯
• 监控缓存命中率按用户维度拆分，异常下降可能提示键冲突