php artisan cache:clear 清的是 cache 通道（如 file 或 redis）中的键值对缓存，不删除 storage/framework/cache 下的原始 .bin 文件；需用 --all 清 config/view/route 等缓存，或手动清 cache 目录。
php artisan cache:clear 清的是什么缓存？
它只清 cache 通道（默认是 file 或 redis）里的键值对，比如 Cache::put('key', 'val') 存的那些。不是删文件，更不碰 storage/framework/cache 目录下的原始缓存文件——除非你用的是 file 驱动且没配 store，这时它才顺手扫一遍目录。
常见错误现象：php artisan cache:clear 执行完，storage/framework/cache/data/ 里一堆 .bin 文件还在，页面还是旧逻辑。
- 确认当前缓存驱动：
config('cache.default')，多数项目是file或redis - 如果驱动是
redis，cache:clear只删 Redis 的 key，和磁盘无关 - 想强制刷新所有缓存键（含 config、view、route 等），得加
--all：运行php artisan cache:clear --all
storage/framework/cache/ 下的 .bin 文件怎么删干净？
这些是 Laravel 自己用 FileStore 写的序列化缓存文件，cache:clear 不保证全删，尤其当缓存过期时间设得长、或进程卡住没触发清理时，它们就堆在那里。
使用场景：部署后发现视图没更新、配置改了不生效、甚至 storage 磁盘爆满。
- 最直接的办法：
rm -rf storage/framework/cache/*（Linux/macOS）或del /s /q storage\framework\cache\*（Windows CMD） - 别只删
data/，整个cache/目录下所有子目录（data/、tags/、pool/）都要清，否则 tag 缓存残留会干扰后续写入 - 注意权限：确保 Web 进程（如 nginx/php-fpm）有权限重建目录，删完建议跑一次
php artisan storage:link检查软链是否完好
storage/logs 和 storage/framework/views 占空间太大怎么办？
这两处不是“缓存”，但常被误认为可一并清理；它们影响日志追踪和 Blade 编译结果，不能无脑删。
性能影响：views 文件夹里几千个 .php 编译文件会让 file_exists() 检查变慢；log 文件过大则拖慢 tail -f 和日志轮转。
-
storage/logs/：用 Logrotate 或 Laravel 的dailychannel 配置自动归档，手动清理可用find storage/logs -name "*.log" -mtime +7 -delete -
storage/framework/views/：安全删除方式是php artisan view:clear，它只删已编译的 Blade 模板，不碰源码；别直接rm -rf views/，否则首次访问页面会卡顿（要重新编译） - 如果确定没自定义
view缓存路径，删前可先看大小：du -sh storage/framework/views
为什么 php artisan optimize:clear 不起作用？
这个命令在 Laravel 9+ 已废弃，Laravel 10 完全移除。它曾试图清 bootstrap/cache/ 下的 packages.php、services.php 等优化文件，但现在这些由 composer dump-autoload 和框架自动管理。
容易踩的坑：看到老教程写 optimize:clear 就照搬，结果报错 Command "optimize:clear" is not defined。
- 替代操作只有两个：
composer dump-autoload（重生成类映射） +php artisan config:clear && php artisan route:clear && php artisan view:clear -
bootstrap/cache/config.php等文件若存在，说明之前跑过config:cache，上线环境建议保留；开发环境可删掉，让每次请求都读原始配置 - 删
bootstrap/cache/全部内容后，首次请求会稍慢，这是正常现象
file_put_contents 往 storage 写临时文件。 
