FileEngine不支持Cache::tag()，调用静默返回true但实际未清理；RedisEngine需显式配置tagPrefix并验证索引写入，清理时应使用SCAN替代KEYS避免阻塞。
FileEngine 根本不支持 Cache::tag() 清理
直接把 Cache::config('default', ['engine' => 'File']) 换成 ['engine' => 'Redis']，但继续用 Cache::tag('user')->clear()，大概率什么都不会删掉——因为 FileEngine 压根没实现 tags() 方法，调用时静默返回 true，你以为清成功了，其实缓存文件还在磁盘上。
这不是配置漏了或者路径错了，是设计如此：FileEngine 只提供键值读写，没有索引、没有标签映射、也没有反向查找能力。想靠它做分组清理，等于用记事本管理数据库外键关系。
RedisEngine 必须显式启用标签支持并配对 tag_prefix
CakePHP 的 RedisEngine 默认也不开启标签功能，光改 engine 不够，还得补两处关键配置：
-
'settings' => ['tagPrefix' => 'cake_tag:']—— 必须显式设置，且值不能为空或仅空格 -
'duration' => '+1 hour'等过期时间要保留，否则部分版本会跳过标签索引写入 - 确认
redis扩展已加载（php -m | grep redis），且连接能通（Cache::read('test')先写再读验证）
如果漏了 tagPrefix，你写缓存时打的标签（比如 Cache::tag('user')->write('profile', $data)）会生成形如 cake_tag:user:profile 的索引 key，但清理时却去查 user:profile，自然匹配不到。
立即学习“PHP免费学习笔记（深入）”；
清理前先验证标签索引是否真实写入 Redis
别信代码返回值，进 Redis CLI 直接查：
redis-cli 127.0.0.1:6379> KEYS cake_tag:user:* # 应该返回类似 cake_tag:user:profile、cake_tag:user:settings 这样的 key
如果空，说明标签根本没写进去，常见原因有：
- 写缓存时没走
Cache::tag()->write()，而是用了Cache::write('key', $val, 'default') -
cache_tag配置项拼错，比如写成tag_prefix或tagprefix - 环境加载的是旧缓存配置（比如
bootstrap.php里硬编码了 FileEngine，覆盖了 config 文件）
用 SCAN 替代 KEYS 批量删除，避免线上阻塞
即使标签索引存在，CakePHP 原生的 clear() 在高并发下可能触发全量扫描，尤其当 Redis 里 key 数量超 10 万时，KEYS 命令会让 Redis 主线程卡住几秒甚至更久。
安全做法是手动走 SCAN + DEL：
$redis = new \Redis();
$redis->connect('127.0.0.1', 6379);
$cursor = 0;
do {
$keys = $redis->scan($cursor, 'cake_tag:user:*', 500);
if ($keys[1]) {
$redis->del($keys[1]);
}
$cursor = $keys[0];
} while ($cursor != 0);注意：这个脚本必须和 CakePHP 使用相同的 tagPrefix，且 SCAN 的 count 参数建议设为 100–500，太小效率低，太大仍可能抖动。
标签不是魔法开关，它依赖驱动层的索引写入和一致性配置；一旦跨环境（比如本地 File、预发 Redis），Cache::tag() 行为就会割裂——最稳的方式，是把标签逻辑下沉到 key 命名规则里，比如统一用 user:123:profile，再配合 SCAN 定向清理。
