缓存键混入时间戳导致缓存永不命中，应改用稳定标识（如user_profile_{uid}）配合TTL控制新鲜度，避免key随请求时机动态变化。
缓存键里混入时间戳，等于给每个请求都发一张新门票——缓存永远找不到“熟人”，自然不命中。
一眼识别带时间戳的缓存键
先查日志或监控中实际生成的 key，重点看是否含以下特征：
-
显式时间成分：如
user:1001:202609161423、report_daily_2026-09-16T08:57:22Z -
隐式动态字段：比如 URL 中带
?t=1757990242、请求头含X-Request-Time、或 trace ID 里嵌了毫秒级时间 -
函数调用痕迹：代码里出现
datetime.now()、int(time.time())、uuid4().hex[:8]等直接拼进 key 的写法
快速定位问题代码位置
在项目中全局搜索关键词组合，缩小范围：
-
搜 key 拼接模式：
"cache_key"、"redis_key"、.format(、f"...、+连接字符串的地方 -
搜时间相关函数：
time.time()、datetime.、strftime、timestamp() - 查高频接口的缓存逻辑：比如报表页、用户中心、订单列表等——这些页面最容易因“实时刷新”误加时间戳
修复方案：用稳定标识替代动态值
核心原则：缓存键应只反映数据语义，不反映请求时机。例如：
- 错误写法：
f"user_profile_{uid}_{int(time.time() // 60)}（按分钟切片，仍每分钟变一次） - 正确做法：
f"user_profile_{uid}"+ 合理 TTL（如 5 分钟），由过期机制控制新鲜度，而非靠 key 变化 - 若真需区分“版本”，改用内容哈希：
f"user_profile_{uid}_{hash_config(config_dict)}"，确保相同参数始终产出同一 key
上线前验证是否修好了
别只信代码改了，要实测：
- 本地或预发环境发起两次相同请求，对比 Redis 中实际 set 的 key 是否完全一致
- 用
redis-cli monitor抓几秒流量，观察 key 出现频次——如果同一业务 key 每秒都在刷新，说明还没根除 - 上线后盯 10 分钟监控：缓存命中率是否从
