Yii缓存本身无优劣，效率取决于是否手动设计多级结构；Cache是单层抽象，实际行为由配置的后端（如Redis、APCu）决定；需手动实现两级缓存、合理设计key、精准控制失效时机。
Yii 的缓存策略本身不“优”也不“劣”，关键看怎么用——默认配置下它只是个普通键值缓存代理，真正的效率提升来自你是否主动设计并串联了多级缓存结构。
yii2 中 yii\caching\Cache 本质是单层抽象
它本身不决定存储介质，只提供统一接口；底层实际行为完全取决于你配的 cache 组件（如 FileCache、RedisCache、ApcuCache）。这意味着：
- 没配对后端，
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 包裹模板中稳定区块，例如侧边栏广告位：
<?php if ($this->beginCache('sidebar_ad', ['duration' => 7200])): ?>
<div class="ad"><?= $this->render('_ad_banner') ?></div>
<?php $this->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)); // 确保顺序无关、可读可控
真正难的不是加缓存，而是让缓存失效时机和业务变更节奏对齐——比如商品价格变了，要同时清理“商品详情”“购物车摘要”“搜索结果页片段”三处缓存，这个链路一旦漏掉一环，用户看到的就是脏数据。
