DbDependency 通过每次读缓存前重执行SQL并比对标量结果来判断失效，须用聚合函数、显式指定db组件、避免硬编码表名；TagDependency需手动维护tag一致性，推荐带业务前缀的命名；二者可组合使用，但需注意依赖链路与缓存后端兼容性。
缓存依赖里 DbDependency 怎么写才生效
直接说结论：DbDependency 不是“监听数据库变化”，而是每次读缓存前重新执行一次 SQL，对比结果是否变化。如果 SQL 返回值变了，缓存就失效。
常见错误是写了个永远返回固定值的查询，比如 SELECT 1，或者漏了 db 配置导致查默认连接、连错库。
- SQL 必须返回**标量值**（一行一列），推荐用聚合函数，如
SELECT MAX(updated_at) FROM post - 必须显式指定
db组件，尤其在多数据库场景下：new DbDependency(['sql' => $sql, 'db' => Yii::$app->get('db2')]) - 注意 SQL 中的表名别用硬编码前缀，建议走
Yii::$app->db->tablePrefix或用{{%post}}占位符 - 不要在 SQL 里写
WHERE动态条件（比如带:id），因为依赖对象是复用的，参数不会自动刷新
TagDependency 的 tag 名怎么管理不冲突
tag 是字符串标识，Yii 用它做缓存项分组标记。tag 本身不自动关联数据，全靠你手动维护一致性——这也是最容易出问题的地方。
典型翻车现场：更新了文章，只删了 post-123 缓存，却忘了给所有含这篇文章的列表缓存打上 tag:post-123，导致列表没刷新。
- tag 命名建议带业务前缀和粒度，比如
post:123、user:profile:456，避免纯数字或泛化名如data - 一个缓存项可以同时依赖多个 tag：
new TagDependency(['tags' => ['post:123', 'user:456']]) - 批量失效时，用
Yii::$app->cache->deleteByTag('post:123')，不是delete() - 别把 tag 当成“事件总线”——它不触发回调，也不通知其他地方，只是个标记开关
DbDependency 和 TagDependency 能不能一起用
能，而且经常要一起用，但顺序和职责得理清：通常 DbDependency 控制“底层数据是否变”，TagDependency 控制“这个缓存属于哪几组业务逻辑”。两者是 AND 关系，任一失效整个缓存就过期。
举个实际例子：首页推荐文章列表缓存，既要检查最新文章时间戳（DB），又要关联当前用户偏好 tag（比如 rec:user:789），两个都得满足才命中。
- 组合写法：
new DependencyChain([new DbDependency([...]), new TagDependency(['tags' => ['rec:user:789']])])—— 注意 Yii 2.0.14+ 才支持DependencyChain - 低版本只能嵌套：把
TagDependency当主依赖，里面再包一层DbDependency作为其dep属性（不推荐，可读性差） - 性能上，每个依赖都会在 get 时触发一次判断，两个依赖 = 至少两次 DB 查询或 tag 检查，高并发下注意压测
缓存更新失败的三个隐蔽原因
不是代码写错，而是环境或配置细节卡住：查起来费时间，但改起来就一行。
-
cache组件没配keyPrefix，导致不同环境（本地/测试/生产）缓存 key 冲突，删 tag 删到别人头上 -
DbDependency的 SQL 查询用了未索引字段（如created_at没建索引），缓存读取变慢甚至超时，被静默降级为无依赖缓存 - 使用文件缓存（
FileCache）时，TagDependency不生效——它只在支持 tag 的缓存后端（如 Redis、APC）里起作用，文档里藏得深，很多人踩坑
复杂点从来不在语法，而在依赖链路上谁负责刷新、谁负责标记、谁又悄悄绕过了校验。盯住那几个字符串 tag 和那条 SQL 的执行结果，比看框架源码还管用。
