Yii2缓存fallback到DummyCache最常见原因是Redis组件未正确配置：未显式定义redis组件、类名错误、密码或database遗漏，导致连接失败而静默降级。

Yii2缓存没走Redis，而是 fallback 到 dummy cache

最常见的情况是：你明明配了 yii\redis\Cache，但 Yii::$app->cache->get() 始终返回 false，日志里也看不到 Redis 连接记录——这说明缓存组件根本没连上 Redis，自动退化成空实现（yii\caching\DummyCache）。

• redis 组件没单独定义，只在 cache 里嵌套写了 'redis' => [...]；Yii 2.0.14+ 已废弃这种写法，必须显式声明独立的 redis 组件
• 'class' => 'yii\redis\Cache' 写错，比如写成 'yii\caching\RedisCache'（该类根本不存在）
• Redis 服务开了密码，但 redis 组件里漏了 'password' => 'xxx'；连接失败不抛异常，只会静默降级
• database 配错了（比如设成 0，但实际用的是 2），导致键写进去了却读不出来

缓存 key 设计不合理，导致命中率天然偏低

命中率低不一定是 Redis 没起作用，很可能是 key 写得太“活”：每次请求生成的 key 都不同，或者 key 粒度太粗，更新频繁导致大面积失效。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 用动态参数拼 key 但没标准化，比如 'user_'.$id.'_profile' 和 'user_'.$id.'_profile_v2' 被当成两个 key，旧 key 过期后新 key 又没预热
• 缓存整个列表（如 'all_users'），只要一个用户改资料就得清掉全部，下次访问全 miss
• 没设 keyPrefix，开发/测试/生产环境共用同一套 Redis 实例，互相覆盖或干扰
• key 长度过长或含特殊字符（如空格、换行），Redis 存储或序列化出问题，get() 返回 false 却误判为未命中

缓存穿透让大量请求绕过缓存直打 DB

当请求的 key 在 Redis 和 DB 都不存在时，如果业务代码不做拦截，就会反复穿透到数据库——这部分请求永远不命中，直接拉低整体命中率。

• 没做空值缓存：DB 查无结果就什么都不存，下一次同样请求又来一遍
• 空值缓存没设过期时间，或设得太长（如 24 小时），导致脏数据长期滞留
• 恶意爬虫或错误 URL 大量刷不存在的 ID（如 /user/999999999），Redis 里塞满无效 key
• 没引入布隆过滤器预检，对高频无效 key 缺乏快速否定能力

过期策略和监控缺失，问题发现滞后

命中率掉到 70% 了才发现，往往已经线上跑了一周——因为没人盯指标，也没设告警阈值。

• 没定期查 redis-cli info stats，忽视 keyspace_hits/keyspace_misses 的真实比值
• 过期时间硬编码（如 3600），没加随机偏移，导致热点 key 同一时刻集体失效（缓存雪崩）
• 没用 Yii::$app->cache->getOrSet()，而是手动 get() + set()，中间可能被并发覆盖或漏写
• 没区分 false 和 null：if (!$val) 会把合法的 null 数据当成未命中，重复查库

缓存命中率不是配完就能高，它依赖 key 设计、空值处理、过期控制和持续监控四个环节的咬合。最容易被忽略的是：**没验证缓存是否真走 Redis，就直接优化业务逻辑**——先确认 Yii::$app->cache->redis->ping() 能通，再谈命中率。