Eloquent 的 remember() 是最轻量的查询缓存方式，仅作用于当前查询链路，需在 get()/first() 前调用；缓存 key 默认由 SQL 和绑定参数生成，需主动 forget() 避免数据不一致，慎用 rememberForever()，跨模型或复杂逻辑推荐 Cache::remember()。
用 remember() 给 Eloquent 查询加缓存最直接
Laravel 自带的 remember() 是模型查询缓存最轻量、最贴近业务逻辑的方式。它不依赖外部配置，写在哪条链路上，就缓存哪次查询结果。
常见错误是以为调用一次 remember() 就全局生效——其实它只作用于当前查询构建器实例，且必须在 get()、first() 等执行方法之前调用。
-
remember(3600)表示缓存 1 小时，单位是秒；传0表示永久（实际受缓存驱动 TTL 限制） - 缓存 key 默认由完整 SQL + 绑定参数生成，所以
User::where('status', $status)->remember(60)->get()中$status变化会触发不同 key - 注意：如果查询里用了
DB::raw()或动态表名，key 可能无法准确反映变化，容易缓存击穿
缓存失效不能靠“等过期”，得主动 forget()
查完缓存，改完数据却不删缓存，是 Laravel 缓存最常见的数据不一致来源。Eloquent 不会自动监听模型变更反向清理查询缓存。
典型场景：用户编辑了文章，但首页最新列表还是旧标题——因为 Article::latest()->take(5)->remember(300)->get() 还在用老缓存。
- 更新/删除模型后，用
Cache::forget($key)清理，但手动拼 key 容易错；更稳妥的是用Article::flushQueryCache()（需开启查询缓存） - 或者，在模型的
saving/deleting事件里统一处理，例如：static::updating(fn ($model) => Cache::forget("articles:{$model->id}")) - 别依赖
rememberForever()：底层仍是驱动的默认 TTL，Redis 或 Memcached 实际仍会淘汰
Cache::remember() 和模型 remember() 选哪个？
两者都能缓存查询结果，但职责和适用范围不同：模型上的 remember() 是语法糖，本质调用 Cache::remember()；而手写 Cache::remember() 更灵活，适合复杂组装逻辑。
容易踩的坑是混用导致 key 冲突或重复序列化。比如同时对同个查询链路既调 ->remember(60) 又包一层 Cache::remember()，结果缓存两份、失效却只清一份。
- 简单查询（单模型、固定条件）：优先用模型
remember()，语义清晰，key 自动生成 - 跨模型拼装、含业务逻辑判断（如“取粉丝数 > 100 的用户”）、需要自定义 key 命名：用
Cache::remember('user:top:active', 300, fn() => ...) - 注意：
Cache::remember()回调里不要用->remember()，否则嵌套缓存，key 难追踪、失效难管理
缓存键冲突和序列化问题在升级或部署时突然暴露
本地开发没问题，上线后缓存乱掉？大概率是模型属性变动、Laravel 版本升级或缓存驱动切换引发的序列化兼容问题。
Laravel 9+ 默认用 serialize 序列化模型，而 Redis 驱动若配成 redis://... 且未指定 options.serializer，可能在某些环境降级为 igbinary，导致反序列化失败，查出来是空集合或报 unserialize(): Error at offset。
- 检查
config/cache.php中 redis 配置的options，显式设'serializer' => 'php'保证一致性 - 模型新增了
$casts或修改了$appends，会导致序列化后结构变化，旧缓存反序列化失败；上线前建议清空相关缓存 - 用
Cache::getStore()->getPrefix()查当前缓存前缀，避免多应用共用 Redis 时 key 意外覆盖
remember() 就一劳永逸的事——key 怎么生成、什么时候失效、序列化是否稳定，每个环节都得盯着看。尤其上线前后，最容易在看似无关的配置变更里翻车。 
