缓存预热命令应放在 commands/ 目录下（如 app/console/commands/CacheWarmupController.php），类名以 Controller 结尾并继承 yii\console\Controller，且必须实现 public function actionIndex()。
缓存预热命令该放在哪个位置
Yii 的缓存预热不是靠配置自动触发的，必须手动写一个 console 命令。这个命令得放在 commands/ 目录下（比如 app/console/commands/CacheWarmupController.php），且类名要符合 Yii 控制器命名规范：以 Controller 结尾，继承 yii\console\Controller。
- 别放进
controllers/—— 那是 Web 请求用的，console应用不加载它 - 别漏掉
public function actionIndex()，否则php yii cache-warmup会报 “Unknown command” - 如果项目用了模块化结构，确保
console/config/main.php的controllerMap或controllerNamespace能正确定位到你的命令类
怎么安全地触发数据缓存生成
预热的核心不是“把所有缓存塞进去”，而是模拟真实请求路径中关键缓存键的生成逻辑。硬编码 Yii::$app->cache->set('key', $data) 很容易和实际业务用的键名、过期时间、依赖项对不上。
- 优先复用已有缓存逻辑：比如调用
ArticleService::getPopularList()这类本身带CacheDependency和duration的方法，而不是自己重写 set - 避免在预热里执行耗时操作（如全表扫描）——应提前分页或加 where 条件限制范围
- 注意缓存组件配置：确认
console应用里'cache' => ['class' => 'yii\caching\FileCache']和 web 应用用的是同一个实例（尤其是 Redis 场景下，host/port/db 必须一致）
为什么预热后页面还是没走缓存
最常见原因是缓存键不一致。Web 请求里用的是带用户 ID、语言、URL 参数的复合键，而 console 命令里只塞了静态字符串。
- 检查
cache key构造方式：比如['article:list', $category, Yii::$app->language]，console 中必须传同样的$category和显式设置Yii::$app->language = 'zh-CN' - 留意
TagDependency：如果缓存依赖Article::className()，但 console 命令没触发过Article::find()->count()这类能刷新 tag 的操作，缓存就始终无效 - Redis 缓存需确认
keyPrefix：web 和 console 的cache组件若配置了不同keyPrefix，就是两套隔离缓存空间
如何避免预热命令卡死或重复执行
预热不是“越快越好”，而是“可控、可中断、可重入”。直接跑全量数据很容易超时或锁表。
- 加
set_time_limit(0)和ini_set('memory_limit', '512M')到 action 开头（console 环境默认限制严） - 用分批处理：比如
Article::find()->limit(100)->offset($i * 100)->all()，配合echo "done {$i} batch\n"实时反馈 - 加文件锁或 Redis 锁：防止 crontab 多次调度重叠执行，例如用
Yii::$app->cache->add('cache_warmup_lock', 1, 3600)，失败则 exit
缓存预热真正的难点不在“怎么塞进去”，而在于“塞进去的和后面取出来的，是不是同一把钥匙”。键名、依赖、过期策略、环境隔离，四个点错一个，就白忙活。
