数据库缓存和视图缓存是两个独立但可协同工作的优化层：前者减少sql查询次数，后者跳过blade编译开销；需分别配置、各自生效，且关键逻辑不可互相替代。
数据库缓存和视图缓存是两个独立但可协同工作的优化层：前者减少 SQL 查询次数，后者跳过 Blade 编译开销。它们不自动联动，需分别配置、各自生效，且关键逻辑不能互相替代。
数据库查询结果缓存（用 remember() 或 Cache::remember）
这是真正减轻数据库压力的核心手段，适用于重复执行的 Eloquent 查询或原生 SQL。
- 在模型查询链中直接加 remember(秒数)，必须放在
get()、first()或paginate()前：User::where('active', 1)->remember(3600)->with('profile')->get(); - 自定义缓存键名便于按业务维度清理，比如按部门、年份、状态组合：
Post::whereYear('published_at', $year)->remember(7200, "posts_{$year}_published")->get(); - 对非 Eloquent 查询（如多表 JOIN、聚合统计），用
Cache::remember()封装闭包：Cache::remember('stats:orders:monthly:'.$month, 3600, fn() => DB::select(...)); - 务必确保缓存驱动已切换为
redis或memcached（修改.env中CACHE_DRIVER=redis并运行php artisan config:clear），否则仍走 file 驱动，效果极弱。
Blade 视图缓存（用 php artisan view:cache）
它只加速模板编译过程，不影响数据来源——即使你缓存了视图，每次请求仍会执行里面的数据库查询，除非你也对这些查询做了 remember()。
- 运行命令生成编译后 PHP 文件：
php artisan view:cache
生成文件位于storage/framework/views/，文件名含内容哈希，模板一改就必须重跑该命令。 - 生产环境部署流程中必须包含这步，且要在
composer install --no-dev后、服务重启前执行；漏掉会导致页面渲染慢，甚至显示旧模板逻辑。 - 验证是否生效：访问一个带
@if或@foreach的页面，用dd(app('view.engine.resolver')->resolve('blade')->getCompiler()->getCompiledPath('welcome'))查看路径，确认指向storage/下的 PHP 文件。 - 开发时别依赖它——改完
.blade.php后得手动再跑一次view:cache才能看到更新；APP_DEBUG=true 时 Laravel 会强制跳过视图缓存。
两者配合使用的注意事项
它们不是“开了就叠加提速”，而是各管一段：视图缓存省编译时间，数据库缓存省查询时间。若没做数据库缓存，视图再快也得等 SQL 返回；若没做视图缓存，数据库再快也得花几十毫秒编译模板。
- 避免在视图里写动态调用，比如
{{ config('app.name') }}、{{ env('APP_ENV') }}或未预加载的关系，这些无法被视图缓存固化，每次仍要执行。 - 权限类 N+1 查询（如循环中调
$user->roles）不会因视图缓存而消失，必须在模型层用remember()或内存缓存预加载解决。 - 缓存键设计要有业务语义，例如
user_profile_{$id}比data_123更易定位和清除；多租户系统还要加前缀，如tenant_a:user_profile_123。 - Redis 配置建议启用
igbinary序列化（'serialize' => 'igbinary'），尤其当缓存大量模型对象时，可节省约 60% 内存占用。
常见失效场景与排查方向
线上出现“明明缓存了却没提速”，大概率是某一层悄悄 fallback 到未缓存路径。
- 视图缓存失效：检查
storage/framework/views/是否为空或只有.gitignore；确认APP_DEBUG=true是否开启；查看 web 服务器用户（如www-data）是否有读取该目录权限。 - 数据库缓存失效：用
php artisan tinker测试连接：Cache::store('redis')->put('test', 'ok', 10)返回true才说明驱动通；再查 Redis 是否真存入键值（redis-cli KEYS "*test*"）。 - 缓存键冲突或污染：多环境共用 Redis 时，务必设
CACHE_PREFIX，否则本地开发缓存可能覆盖生产键，导致数据错乱。 - TTL 设置不合理：高频变更数据（如订单状态）设长 TTL 容易陈旧；低频查询（如站点配置）设太短又频繁穿透，建议按数据类型分级设置。
