yii框架用redis做缓存核心三步：装对phpredis扩展（≥2.6.12）、配对cache组件（含keyprefix防冲突）、用对方法（get/set需注意序列化与集群配置）；任一环节出错将导致缓存失效或污染。
直接说结论：Yii 框架用 Redis 做缓存，核心就三步——装对扩展、配对组件、用对方法；错一步就可能缓存写不进、读不出、或和 Session 互相污染。
phpredis 扩展必须启用，且版本要 ≥2.6.12
Yii2 的 yii\redis\Cache 依赖 phpredis（不是 predis 或 redis 扩展），不装或装错会静默失败——set() 返回 true，但 redis-cli 查不到 key。
- 执行
php -m | grep redis，输出里必须有redis（不是memcache或空） - 确认 Redis 服务端版本：
redis-cli INFO | grep redis_version，低于 2.6.12 会报ERR unknown command 'EVAL' - Windows 下若用 WAMP/XAMPP，需手动启用
php_redis.dll并检查phpinfo()中 redis 模块是否加载成功
配置 cache 组件时，keyPrefix 是防冲突刚需
不设 keyPrefix，所有缓存 key 都裸奔，极易和别的应用、或 Yii 自身的 Session/Asset 缓存撞车。尤其当你共用一个 Redis 实例时，get('user_123') 可能读到别人写的二进制垃圾。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在
'cache' => ['class' => 'yii\redis\Cache', 'redis' => [...], 'keyPrefix' => 'myapp_cache_']中显式声明前缀 - 前缀建议含应用名 + 环境（如
'prod_api_cache_'），避免开发/生产混用导致脏读 - 别指望靠命名规范代替
keyPrefix：Yii 内部对 key 做了 hash 处理，set('user:123')最终存的可能是myapp_cache_:5a7f:user:123
Cache::get() 返回 false 不一定代表没命中
返回 false 可能是 key 不存在，也可能是序列化失败、值被压缩损坏、或你用 phpredis 直连却误判了 igbinary 格式。
- 先用
redis-cli查原始值：get "myapp_cache_:user_list"，如果返回"\x00\x00\x00"或乱码，说明序列化方式不匹配 - 默认用
phpserialize，若改用igbinary（提速约 20%），必须确保所有写入/读取端都启用igbinary扩展，且配置中明确写'serializer' => 'igbinary' - 调用
get()后别直接=== false判断，加一层is_bool($val) && $val === false排除实际存了布尔 false 的情况
Redis 集群配置不能照搬单节点写法
集群模式下硬写 'hostname' 和 'port' 会导致连接始终打向第一个节点，分片失效，还可能因槽位迁移报 MOVED 错误。
- 删掉
redis下的hostname/port，改用'clusters' => ['192.168.1.10:6379', '192.168.1.11:6379'] -
redis子项的class仍为'yii\redis\Connection'，不要改成Cluster类——Yii2 内部根据clusters字段自动切换逻辑 - 集群各节点必须已执行
CLUSTER MEET、分配好 slot，Yii2 不负责初始化，只做客户端路由
最易被忽略的是：keyPrefix 和 serializer 这两个配置一旦写进组件定义，就无法在运行时动态覆盖；哪怕你在控制器里临时改 Yii::$app->cache->keyPrefix = 'tmp_'，也不会生效——因为 key 生成发生在组件初始化阶段。
