Yii缓存本身无优劣，效率取决于是否手动设计多级结构；Cache是单层抽象，实际行为由配置的后端（如Redis、APCu）决定；需手动实现两级缓存、合理设计key、精准控制失效时机。

Yii 的缓存策略本身不“优”也不“劣”，关键看怎么用——默认配置下它只是个普通键值缓存代理，真正的效率提升来自你是否主动设计并串联了多级缓存结构。

yii2 中 yii\caching\Cache 本质是单层抽象

它

• 没配对后端，Cache::get() 永远返回 null，且不报错
• duration 参数在 FileCache 下受文件系统 mtime 影响，可能提前失效
• 所有缓存操作都走同一通道，不存在自动分级——所谓“多级”必须手动编码实现

手动实现两级缓存：先查 APCu，再查 Redis

典型场景：高频读、低更新频率的数据（如站点配置、菜单树）。目标是减少网络 IO，把热数据留在 PHP 进程内。

public function getSiteConfig()
{
    $key = 'site_config_v2';
    
    // 一级：APCu（进程内，快但不共享）
    $config = apcu_fetch($key);
    if ($config !== false) {
        return $config;
    }
    
    // 二级：Redis（跨进程，稍慢但一致）
    $config = Yii::$app->cache->get($key);
    if ($config === false) {
        $config = $this->loadFromDb(); // 实际查询
        Yii::$app->cache->set($key, $config, 3600);
    }
    
    // 写回 APCu，供本进程后续快速命中
    apcu_store($key, $config, 3600);
    
    return $config;
}

注意：apcu_store() 和 Yii::$app->cache->set() 的过期时间最好一致，否则会出现“APCu 已过期但 Redis 还有效”的状态漂移。

yii\filters\PageCache 不适合动态页面，但能救静态片段

它基于 HTTP 响应头做全页缓存，仅适用于无用户态、无 CSRF、URL 参数可穷举的场景（比如产品列表页的分页缓存）。常见误用：

• 在用户登录后启用 PageCache → 缓存了他人页面给当前用户看
• 用 only 列表限制动作，却忘了排除带 GET[sort] 的请求 → 同一 URL 缓存覆盖不同排序结果
• 配合 Dependency 时依赖了数据库连接，导致缓存失效检查反而比查询还慢

更稳妥的做法是用 FragmentCache 包裹模板中稳定区块，例如侧边栏广告位：

beginCache('sidebar_ad', ['duration' => 7200])): ?>
    render('_ad_banner') ?>
endCache(); ?>

缓存键设计不当会让所有优化归零

Yii 不帮你生成语义化 key，全靠你自己拼。容易踩的坑：

• 用 serialize($params) 当 key → 不同顺序的数组产生不同 key，重复缓存
• 在 key 里硬编码环境名（如 'prod_user_123'）→ 本地开发无法复现缓存逻辑
• 忽略用户身份上下文：未将 Yii::$app->user->id 或 Yii::$app->language 纳入 key → 多语言/多角色页面互相污染

推荐写法：

$key = [
    'user_profile',
    'v2',
    'uid' => Yii::$app->user->id,
    'lang' => Yii::$app->language,
];
$key = md5(json_encode($key)); // 确保顺序无关、可读可控

真正难的不是加缓存，而是让缓存失效时机和业务变更节奏对齐——比如商品价格变了，要同时清理“商品详情”“购物车摘要”“搜索结果页片段”三处缓存，这个链路一旦漏掉一环，用户看到的就是脏数据。