cache:clear 仅清除应用缓存（如 Cache::put() 写入的键），不清理配置、路由、视图等；清的是 cache.store 驱动对应位置（如 Redis 键或 storage/framework/cache/data/ 文件），且不触发 Cache::forget() 事件。
cache:clear 命令到底清哪些缓存
它只清 php artisan cache:clear 对应的「应用缓存」（即 Cache::put()、Cache::remember() 写入的键），不碰配置、路由、视图、配置这些。很多人执行完还看到旧配置或新路由不生效，就是误以为它能“一锅端”。
- 清的是
cache.store配置指定的驱动（如redis、file、database）里的键，不是清整个 Redis 实例 - 如果用的是
file驱动，它删的是storage/framework/cache/data/下的文件，但不会清理.gitignore里排除的临时缓存目录结构 -
cache:clear不会触发Cache::forget()的事件监听器，所以依赖缓存清除做清理逻辑的代码不会自动运行
config:clear 和 config:cache 的分工必须分清
config:clear 只删 bootstrap/cache/config.php 这个缓存文件；而 config:cache 是把所有 config/*.php 合并编译成一个静态数组写进去。两者不是互逆操作——你删了 config.php，Laravel 在下次请求时会自动重新加载配置，但不会重新生成它，除非再跑一次 config:cache。
- 开发环境一般不用
config:cache，因为改配置后要手动重跑才生效；线上才需要它来提速 - 如果
config/app.php里用了闭包或动态值（比如env('APP_DEBUG')），config:cache会把它固化为当前环境的值，换环境不重启 PHP-FPM 就不会更新 -
config:clear执行后，php artisan tinker里config('app.name')仍返回正确值，说明它只是删缓存文件，不影响运行时解析
route:clear 和 route:cache 的真实影响
route:clear 删除 bootstrap/cache/routes-v7.php（版本号随 Laravel 升级变），而 route:cache 是把所有 Route:: 定义序列化进这个文件。关键点在于：缓存路由后，Route::get()、Route::resource() 等动态注册方式将完全失效——它们只在首次生成缓存时被读取，之后全靠文件里静态数组匹配。
- 带闭包的路由（
Route::get('/', function () { ... })）可以被缓存，但调试时断点进不去，因为执行的是反序列化后的函数，不是源码 - 使用
Route::macro()或第三方包动态注册的路由，如果没在routes/web.php或routes/api.php主文件中显式调用，就不会进缓存 -
route:clear后第一次请求会明显变慢，因为要重新扫描+编译全部路由，别在高峰期跑
view:clear 清的是编译模板，不是原始 Blade 文件
view:clear 删除 storage/framework/views/ 下所有 .php 编译结果，不影响 resources/views/*.blade.php。它解决的是「改了 Blade 但页面没变」的问题，但前提是你的修改确实已保存且 Web 服务器有读权限。
- 如果用的是
opcache.enable=1，PHP 可能缓存了编译后的视图文件，此时仅view:clear不够，还得opcache_reset()或重启 PHP-FPM -
view:clear不清storage/framework/cache/views/（那是 Blade 编译过程中的临时缓存，Laravel 自己会轮转清理） - 在 Docker 环境中，如果
storage目录挂载为 volume，确保容器内用户对storage/framework/views/有写权限，否则命令看似成功，实际删不掉文件
最常被忽略的是：多个缓存命令之间没有依赖关系，cache:clear 不会顺带清配置或路由；而生产环境一旦开了 config:cache 或 route:cache，后续改配置或路由就必须人工补跑对应 :clear + :cache，不能指望一键命令兜底。
