Cache::remember() 必须置于 get() 等终端方法前才能生效，因它是 Query Builder 链式方法，仅在终端执行时触发缓存；需显式指定语义化键名、手动处理失效，且非所有查询都适用。
Cache::remember() 是 Laravel 模型查询缓存最直接有效的手段，但它不是“开个开关就生效”的自动功能——必须显式调用、合理构造键、手动处理失效，否则缓存会变成数据不一致的根源。
为什么 remember() 必须放在 get() 或 first() 前面
remember() 是 Query Builder 的链式方法，它只在终端方法（如 get()、first()、count()）执行时才真正触发缓存逻辑。中间的 where()、with()、orderBy() 只是构建器状态，不产生缓存行为。
- 如果写成
Post::where('status', 'draft')->get()->remember(3600)，缓存根本不会生效（remember()被调用在集合对象上，无意义） - 正确顺序是：
Post::where('status', 'draft')->remember(3600)->get() -
remember()底层调用的就是Cache::remember()，所以不要在外层再套一层Cache::remember('key', 3600, fn() => ...)，纯属重复且易出错
缓存键怎么设计才不踩坑
默认键由完整 SQL + 绑定参数哈希生成，调试时完全看不出来源，线上排查极难。必须显式传入业务语义明确的键名。- 错误示范：
Post::where('category_id', $id)->remember(3600)->get()→ 键是随机哈希，无法定位、无法批量清理 - 正确做法：
Post::where('category_id', $id)->remember(3600, 'posts:by_category:'.$id)->get() - 多参数场景建议用
md5(json_encode($params))，比如分页+排序：'posts:paged:'.md5(json_encode(['page' => $page, 'sort' => $sort])) - 静态数据加版本号：
'v2:config:countries'，后续结构变更只需改版本号，旧缓存自然过期
缓存失效必须自己动手，Laravel 不会监听模型变更
这是线上最常导致“页面还是旧数据”的原因：模型save() 或 delete() 后，缓存纹丝不动。
- 在模型的
saving、deleting事件里主动清除：Cache::forget('posts:by_category:'.$this->category_id) - 若使用自定义键（强烈推荐），就别依赖默认键——它不可控、不可读、不可维护
- 对于
rememberForever()，更要谨慎：Cache::forget()是唯一清除方式；Redis 中误用会导致脏数据长期存在，只能靠redis-cli flushdb补救，生产环境风险极高
哪些查询根本不该加 remember()
缓存不是银弹，加错了反而拖慢响应、浪费内存。
- 用户私有数据：
Order::where('user_id', auth()->id())->remember(...)->get()→ 每个用户一个键，命中率为零，纯占 Redis 内存 - 含数据库函数的查询：
whereRaw('created_at > NOW() - INTERVAL 1 HOUR')→NOW()每次执行值不同，缓存键永远不命中 - 高频更新数据：如实时订单状态、聊天消息列表，缓存时间稍长就会造成体验断层
- 结果体积过大：单次缓存超 1MB 的集合，序列化/反序列化开销可能超过查库本身
缓存键的业务语义、失效时机的可控性、以及是否真能复用——这三点没想清楚前，remember() 就只是给 bug 加了一层包装纸。
