view:cache 缓存的是 Blade 模板编译后的 PHP 文件，非 HTML 输出；它将 resources/views/ 下的 .blade.php 编译为含 echo/foreach 的原生 PHP 文件，存于 storage/framework/views/，以哈希命名，运行时直接 include，仅适用于视图稳定的生产环境。
view:cache 缓存的是 Blade 模板编译后的 PHP 文件，不是 HTML 输出——改了模板不生效，八成是忘了重跑这个命令。
view:cache 到底编译了什么？
它把 resources/views/ 下每个 .blade.php 文件解析成带 echo、foreach、include 的原生 PHP 代码，存进 storage/framework/views/，文件名是哈希值（如 abc123.php）。运行时 Laravel 不再调用 Blade 编译器，而是直接 include 这些 PHP 文件。
- 不缓存渲染结果（HTML 字符串），和
View::make()->render()的输出缓存完全无关 - 不处理
@include('some.dynamic.path')中的动态路径，只认写死的字符串字面量 - 不扫描
views目录外的模板，比如vendor/或运行时拼接的视图名 - 生成的 PHP 文件可被 OPcache 加速，但需确保
opcache.enable_cli=1（否则view:cache生成的文件不会进 OPcache）
什么时候该跑 php artisan view:cache？
只在生产环境部署末尾跑，且确认视图结构已冻结。典型适用场景：
- 后台管理系统、企业官网这类布局固定、组件复用率高、几乎不热更新的项目
- CI/CD 流程中：构建镜像 → 复制代码 →
php artisan config:cache→php artisan view:cache→ 启动 FPM - 你明确知道所有视图都定义在
resources/views/，没用闭包路由或运行时view()动态构造视图名
不适合的场景：
- A/B 测试、用户主题切换、多语言视图路径动态计算
- 本地开发调试期间——改一行
.blade.php就得手动php artisan view:clear或删storage/framework/views/，非常反直觉 - 用了 IDE 的 Blade 语法检查（如 PHPStorm），因为检查对象是原始
.blade.php，不是编译后文件
为什么改了模板页面没变？常见排查点
这是最常踩的坑，表面像浏览器缓存或路由问题，实际根源在缓存机制本身：
-
APP_DEBUG=true时 Laravel 强制跳过视图缓存，但如果你手动跑过view:cache又没清掉，APP_DEBUG=true也不起作用——缓存文件已存在，Laravel 仍会加载它 -
view:clear只删storage/framework/views/目录内容，但若你之前用过config:cache，而配置里'compiled' => env('VIEW_COMPILED_PATH', null)被意外覆盖，可能指向其他目录 - 修改了
config/view.php里的'compiled'配置却没重新运行view:cache，旧编译文件还在被加载 - 部署时漏掉了
view:cache步骤，或者执行权限不足导致命令静默失败（检查storage/framework/views/是否有新文件生成）
真正关键的细节是：view 缓存和配置缓存、路由缓存、OPcache、Redis 输出缓存互不感知——它们各自独立生效，也各自需要独立维护。一个环节没对齐，性能优化就变成埋雷现场。
