Composer缓存默认有自动GC，无需定期清理；仅当缓存超1.5GB、存在半年未访问ZIP或vcs目录耗尽inode时才需手动干预，且clear-cache默认跳过vcs目录，须单独清理或禁用cache.vcs。
不需要定期清理——Composer 缓存默认有自动垃圾回收（GC），只要配置合理，手动清缓存反而可能拖慢后续安装。
缓存目录大小超过 1.5GB 才值得动手
Composer 默认限制缓存体积为 300MiB，但实际中常因未设 cache-files-maxsize 或长期未更新而膨胀。真正该干预的信号是：
-
du -sh $(composer config --global cache-dir)输出 > 1.5GB - 缓存里存在大量半年以上未被访问的
.zip文件（find ~/.composer/cache/files -name "*.zip" -mtime +180） -
vcs/目录占满 inode（尤其 WSL/macOS APFS 下报No space left on device却df -h显示空间充足）
为什么 composer clear-cache 有时没反应？
它只清 cache-dir 指向的路径，而这个路径可能已被覆盖或失效：
- 环境变量
COMPOSER_CACHE_DIR被设置但未生效 →clear-cache实际操作空目录 - 公司私有镜像强制改了缓存位置，
composer config --global cache-dir查出的仍是默认值 - 权限错乱：之前用
sudo composer install写入的文件，当前用户无权删除 - 杀毒软件或 IDE（如 PHPStorm）锁住了
files/或vcs/下的文件
vcs/ 目录才是磁盘和 inode 真正杀手
composer clear-cache 默认跳过 vcs/，但它单个 Git 裸仓库就常达 300–800 MB，且含成千上万小文件，极易耗尽 inode：
- 手动清理：
rm -rf ~/.composer/cache/vcs/*（Linux/macOS）或rd /s /q "%APPDATA%\Composer\Cache\vcs"（Windows） - 一劳永逸：禁用 VCS 缓存 →
composer config --global cache-vcs false，后续所有 Git 包强制走--prefer-dist - CI/CD 中建议加此配置，避免构建机磁盘缓慢爬升
比清理更有效的长期策略
与其反复清，不如从源头控量：
- 设硬上限：
composer config --global cache-files-maxsize "500MiB" - 缩短缓存寿命：
composer config --global cache-files-ttl 2592000（30 天） - 迁移缓存到大分区：
composer config -g cache-dir /data/composer-cache - 升级 Composer 到 2.5+：新版 GC 更激进，压缩率更高，对重复包去重更好
最常被忽略的一点：清完 vcs/ 后首次 composer update 会变慢，不是命令失败，是它在重建元数据索引——这个延迟无法绕过，只能接受。
