laravel无独立“查询缓存”，所谓查询缓存实为开发者通过cache::remember()等手动写入的键值对，cache:clear仅清除此类缓存项，不干预数据库或eloquent行为；精准清理需用cache::forget()删指定键或cache::tags()->flush()清标签组。
查缓存没清干净，不是命令没跑，而是你根本没清对地方——Laravel 的「查询缓存」本身并不存在独立缓存层，它依赖的是 Cache 门面或底层驱动（如 Redis、文件）存储的键值对，而这些键通常由 Eloquent 或 Query Builder 手动构造。所谓“查询缓存”，其实是开发者自己写的 Cache::remember() 或 Cache::get() 逻辑，不是框架自动拦截 SQL 生成的。
cache:clear 为什么对“查询结果”无效？
因为 php artisan cache:clear 只清 Cache::put()、Cache::remember() 写入的缓存项，不碰数据库连接、不重置 Eloquent 查询日志，也不影响模型观察者或关系预加载行为。如果你用的是原生 SQL 查询 + 手动缓存，那清的就是你 Cache::put('user_orders_123', ...) 这类键；但如果你没显式调用缓存方法，那根本就没有“查询缓存”可清。
- 常见错误现象：改了数据库数据，页面还是旧内容 → 实际是代码里用了
Cache::remember('users_list', 3600, fn() => User::all())，但没清这个键 - 使用场景：列表页、统计数、关联聚合结果等需要复用的查询结果
- 参数差异：
Cache::remember()第二个参数是秒数，Cache::rememberForever()不设 TTL，必须手动 flush 或 forget - 性能影响：盲目清全库缓存（如
Cache::flush()）会连 session、token 等非查询类缓存一并干掉，导致用户登出、API 失效
怎么精准清除某次查询的缓存？
别靠 cache:clear，得从缓存键入手。Eloquent 自带的缓存键命名无统一规则，必须你自己控制。
- 用
Cache::forget('key_name')删除单个键，例如Cache::forget('dashboard_stats') - 批量清除可用标签（tags）：先写入时打标
Cache::tags(['orders'])->remember('recent', 300, fn() => Order::latest()->take(10)->get())，再用Cache::tags(['orders'])->flush() - 若用 Redis 驱动且未启用标签，可通过
redis-cli -n 0 KEYS "orders:*"查键，再DEL批量删（生产环境慎用，KEYS 是阻塞命令） - 注意：文件驱动不支持
tags，Cache::tags(...)->flush()在driver=files下静默失败，不会报错
config/cache.php 里哪些配置影响查询缓存行为？
真正决定“查完要不要缓存”和“缓存存在哪”的，是缓存驱动和默认 TTL，不是数据库配置。
-
'default' => env('CACHE_DRIVER', 'file')：改这里等于换整个缓存落盘方式，Redis 和 file 行为差异极大（比如 tags 支持、原子性、过期精度） -
'stores.redis.ttl' => 3600：只影响未显式指定过期时间的Cache::put()，不影响remember()传入的 TTL -
'prefix' => 'laravel_cache_'：所有缓存键都会加前缀，排查时别漏掉，redis-cli KEYS "laravel_cache_*"才能扫到 - 如果用的是
database驱动，记得检查cache表有没有被误删或锁死，cache:clear会清表但不重建索引
最常被忽略的一点：你在本地用 php artisan tinker 测试 Cache::remember()，但生产环境可能启用了 config:cache，导致 env('CACHE_DRIVER') 被固化为字符串而非运行时读取——这时候改 .env 里的 CACHE_DRIVER=redis 根本不生效，得先 config:clear 再 config:cache。
