Laravel 的 Cache::tags() 在 Redis + 文件缓存组合中失效，是因为 file 驱动不支持标签语义——它仅将键名拼接为路径写入文件，无法按标签遍历或精准 flush；只有 Redis、Memcached 等原生支持集合操作的驱动才真正实现 tags()，生产环境必须统一使用 Redis 驱动并配置全局 prefix。
多级缓存不是 Laravel 原生内置的概念，而是开发者根据场景组合不同缓存层形成的策略。它不靠一个配置开关打开，而是靠你明确区分“什么数据放哪一层”+“怎么协同失效”。
Redis + 文件缓存组合时，为什么 Cache::tags() 会失效
Laravel 的 Cache::tags() 依赖驱动自身支持标签语义。file 驱动根本不实现标签逻辑——它只是把键名拼成 tags/users/xxx 写进文件，flush() 时无法遍历匹配，只能清空整个目录（不安全）或直接报错。只有 Redis、Memcached 等支持集合操作的驱动才真正支持 tags()。
- 验证当前驱动是否支持：运行
php artisan tinker -n，输入Cache::tags(['test'])->put('key', 'val', 60)，如果报Method tags does not exist或写入后flush()无效果，说明驱动不兼容 - 生产环境必须统一用 Redis 驱动：在
config/cache.php中确保'default' => 'redis'，且'redis'配置段启用了prefix - 别在混合驱动项目里幻想“一级内存 + 二级文件”的多级自动联动——Laravel 不会帮你跨驱动同步标签或失效事件
如何手动实现两级缓存（内存 + 数据库兜底）
当 Redis 临时不可用，又不想让请求直接穿透到数据库，可以手写 fallback 逻辑。这不是 Laravel 自动行为，得你自己控制读写顺序。
- 读取时先查
Cache::store('redis')，命中则返回；未命中再查Cache::store('database')；都未命中才查 DB 并双写 - 写入时必须同步更新两级：
Cache::store('redis')->put(...)和Cache::store('database')->put(...)，不能只写一级 - 清除时同样要双删：
Cache::store('redis')->forget($key)+Cache::store('database')->forget($key)，否则数据不一致 - 注意 database 驱动性能极低，仅适合低频、关键配置类数据，绝不能用于用户会话或高频查询结果
权限、设置、菜单等扩展包的缓存怎么避免互相污染
spatie/laravel-permission、laravel-settings、laravel-menu 这些包各自管理自己的缓存键，但默认都用 Laravel 全局缓存驱动。一旦没配 prefix，它们的键会撞车——比如 spatie.permission.cache 和 laravel_settings 都落在 Redis 同一个 DB 里，cache:clear --all 会误删对方数据。
- 每个包必须独立配 prefix：在
config/permission.php改'key' => 'myapp_permission_cache:'；在config/settings.php加'cache_prefix' => 'myapp_settings:' - 检查所有包是否都走
Cache::store()而非直连底层 Redis 客户端——绕过 Laravel 抽象层会导致 prefix 失效、tags 失效、TTL 被忽略 - laravel-settings 的
CacheDiscoveredSettingsCommand和 permission 的permission:cache-reset命令互不感知，该谁清谁的，别指望一个命令清干净全部
缓存键命名和失效边界最容易被忽略的三点
很多缓存问题不是因为没设 TTL，而是键设计本身埋了雷。
- 动态 ID 拼接键（如
'user_'.$id.'_profile'）导致批量失效 impossible：用户改头像后，你没法精准清掉他所有相关缓存，只能扫全库（线上禁用）或留着脏数据 -
Cache::remember()里塞副作用逻辑（发邮件、扣库存、写日志）——缓存命中时这些逻辑就跳过了，行为不一致 - 用
now()->addMinutes(10)而非600是好习惯，但更关键的是：这个 10 分钟是否真符合业务语义？用户资料变更频率、权限更新时效要求、菜单结构稳定周期，都得单独评估，不能全堆一个 TTL
