cache.stats().hitRate() // 按 key 前缀上报 hit/miss，低于 60% 告警
缓存上线半年，数据库扩容三次，最后加监控才发现命中率只有 18%，八成请求根本没命中，缓存等于白加。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，key 里拼了时间戳和随机数，每次请求生成的 key 都不一样，写入后再也读不到。上线时没有命中率指标，也没有任何告警。
「缓存命中率监控」改完先别急着全量，挑一台机器放半天，真有问题这段时间就能看出来。改动写完就同步给同事，下一个人踩同一个坑，成本还是你的。
验证用真实数据走一遍，测试数据太干净，边界情况根本碰不到。能分两步做的操作就别合成一步，中间看一眼返回值，出问题好判断。
处理上按这个顺序：加 hit/miss 计数并按 key 前缀上报；命中率低于 60% 触发告警；定期抽样看 key 的生成规则 确认没有时间戳这类变量。
改完只确认一件事：监控上线后看到真实命中率 18%，去掉 key 里的时间戳后升到 91%，数据库扩容计划暂时搁置。