php artisan view:cache 将 resources/views/ 下所有 .blade.php 文件编译为原生 PHP（含 echo、foreach 等），以哈希名存入 storage/framework/views/，运行时直接 include 这些文件；它不缓存 HTML 输出，不处理动态 @include，修改模板后必须重执行该命令才生效。
Blade 视图编译本身不需“优化”，真正要控制的是编译产物的缓存行为——即是否预编译、是否启用缓存路径、何时重建。
view:cache 命令到底干了什么？
它把 resources/views/ 下所有 .blade.php 文件，逐个编译成原生 PHP 代码（含 echo、foreach 等），再写入 storage/framework/views/ 目录，文件名是哈希值（如 abc123.php）。Laravel 运行时不再解析模板，而是直接 include 这些 PHP 文件。
- 不缓存 HTML 渲染结果，只缓存编译后的 PHP 逻辑
- 不处理
@include的动态路径（如@include($partial)）或运行时拼接的视图名 - 修改任何
.blade.php后，必须重新执行php artisan view:cache才能生效 - 开发环境禁用该命令；生产环境部署后应立即执行一次
如何禁用或临时绕过 Blade 编译缓存？
有三种互不冲突的方式，按优先级从高到低：
- 修改
config/view.php中的'compiled' => ''（空字符串），强制 Laravel 每次都重新编译 - 运行
php artisan view:clear删除storage/framework/views/全部文件，下次访问自动重建 - 在服务容器中手动重置编译器路径：
$bladeCompiler->setCachePath('')（适合测试或中间件内条件性禁用）
注意：'compiled' => null 或 false 不生效，必须是空字符串或非法路径。
为什么改了 Blade 文件但页面没更新？
常见于以下几种情况：
- 生产环境误启了
view:cache，但改完模板后没再运行该命令 - 使用了
php artisan config:cache，但config/view.php里'compiled'被硬编码为某个路径，而你改的是本地未缓存的配置文件 - 服务器部署时用了 rsync 或类似工具，漏传了
storage/framework/views/目录，导致旧缓存残留 - 某些 Docker 镜像或 CI/CD 流程在构建阶段执行了
view:cache，但后续覆盖了resources/views/却未触发重建
最稳的排查顺序：确认 storage/framework/views/ 下文件修改时间是否早于你的模板修改时间；再检查 config/view.php 的 compiled 值是否被覆盖。
Blade 编译缓存的关键不在“快”，而在“确定性”——它把不确定的运行时解析，变成确定的、可验证的、可打包的 PHP 文件。一旦路径或哈希机制被干扰，就容易陷入“改了却看不到”的静默失效状态。
