php artisan view:clear 只清除 storage/framework/views/ 目录下所有已编译的 blade 模板（.php 文件），不涉及缓存、配置、路由、日志或上传文件，下次请求时自动重建。
php artisan view:clear 到底清什么
它只删 storage/framework/views/ 目录下所有已编译的 .php 文件，这些是 Blade 模板被 Laravel 编译后生成的原生 PHP 代码。改了 resources/views/welcome.blade.php 却没看到变化？大概率就是这个目录里还躺着旧的编译结果。
- 不碰
storage/framework/cache/或任何配置、路由缓存 - 不清日志（
storage/logs/）、不删上传文件（storage/app/） - 下次请求时自动重建，无需手动触发编译
为什么有时候 view:clear 执行完页面还是旧的
常见原因不是命令没跑，而是缓存类型混了——你清了视图，但没清配置或路由，导致控制器返回了错误视图，或者中间件逻辑没更新。
-
config:cache启用后，.env修改不生效 → 必须配php artisan config:clear - 改了
routes/web.php却 404 → 路由缓存还在，得跑php artisan route:clear - 用了
@include或组件，但子视图路径写错 → 清缓存也救不了语法或路径问题
storage/framework/views 目录手动删行不行
行，而且有时更彻底。尤其当你发现 view:clear 执行后目录里还有残留文件（比如权限问题导致部分文件删不掉），直接清空目录更可靠。
- Linux/macOS：
rm -rf storage/framework/views/* - Windows CMD：
del /s /q storage\framework\views\* - 删完记得检查 Web 进程（如 php-fpm）是否有权限在该目录下新建文件
- 别顺手把
storage/framework/views/.gitignore也删了，否则 Git 可能误提交编译文件
视图缓存对开发和部署的影响差异
开发阶段关掉视图缓存最省心；生产环境开它能省掉模板解析开销，但会掩盖 Blade 语法错误——因为报错发生在编译后的 PHP 文件里，堆栈信息指向 storage/framework/views/xxx.php，而不是你写的 .blade.php。
- 本地开发建议：确保
APP_DEBUG=true且不运行view:cache（Laravel 本身也不提供这个命令） - CI/CD 部署后务必加
php artisan view:clear，尤其用 Docker 多实例时，缓存可能跨容器残留 - Blade 中的
@php、@endphp或复杂条件嵌套，容易在编译后出隐性错误，上线前最好本地模拟一次清缓存+刷新
view:clear 的问题，而是你漏掉了 config:clear 或 route:clear。
