laravel清理缓存需分类型执行：1. cache:clear清应用缓存；2. config:clear删配置缓存文件；3. route:clear移除路由缓存；4. view:clear清编译视图；5. optimize:clear一键清除全部。
不清理 PHP 缓存文件，storage/framework/cache、runtime/cache 或 opcache 残留数据会持续膨胀，尤其在本地开发或小内存 VPS 上，几天内就可能吃光磁盘空间，直接触发 No space left on device 错误——这不是性能问题，是存储告急。
缓存目录无节制增长的真实路径
不同缓存类型写入位置差异极大，同一项目可能同时堆积多处：
-
OPcache本身不占磁盘，但opcache.file_cache启用后会在指定目录（如/tmp/opcache）生成 .bin 文件，重启 PHP 不自动清理 - Laravel 的
storage/framework/cache/data/下每个缓存项都是独立小文件，数量可达数万，find storage/framework/cache/data -type f | wc -l经常超 50000 - ThinkPHP 的
runtime/cache/默认按模块+时间戳分目录，但clear:cache命令不清理runtime/data/中的序列化缓存，残留文件长期存在 - Composer 的
vendor/composer/autoload_classmap.php虽然不大，但频繁composer update后旧版本缓存残留在~/.composer/cache/，单个包缓存可达几十 MB
Linux 下快速定位缓存磁盘占用大户
别靠猜，用系统命令直击问题目录：
- 查 Laravel 项目：运行
du -sh storage/framework/{cache,views,logs}，重点关注cache/data子目录 - 查 ThinkPHP 项目：运行
du -sh runtime/{cache,data,temp}，cache/下若出现大量1234567890_abcde.php类似命名，基本是未过期的 file 驱动缓存 - 全局扫描：用
sudo du -sh /var/tmp/* /tmp/* 2>/dev/null | sort -hr | head -n 10，opcache或apcu的文件缓存常藏在这里 - 注意隐藏增长点：
~/.composer/cache/files/里每个 vendor 包都有完整 zip 缓存，composer clear-cache才真正释放空间
定时清理不能只依赖框架命令
Artisan 或 php think clear 只清框架层，漏掉底层和跨项目缓存：
-
php artisan cache:clear不影响opcache，也不清理storage/framework/views编译模板（得配view:clear） -
php think clear --all会删runtime/log/，但生产环境日志不该被清——要拆开执行：php think clear:cache+ 手动find runtime/cache -name "*.php" -mmin +1440 -delete（删 24 小时前的） - OPcache 文件缓存需单独处理：设
opcache.file_cache_fallback=0禁用，或定期rm -f /tmp/opcache/*（路径以php -i | grep opcache.file_cache为准） - 最稳妥的定时脚本逻辑是：
composer clear-cache && php artisan optimize:clear 2>/dev/null || true && find storage/framework/cache -type f -mtime +7 -delete
磁盘爆满往往不是突然发生的，而是缓存文件日积月累、权限错乱导致无法自动覆盖、旧缓存永不淘汰。定期清理的关键不是“频率”，是确认每类缓存的落盘路径和生命周期——删错地方比不删更危险。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
