Composer的vcs缓存位于~/.composer/cache/vcs/（Linux/macOS）或%APPDATA%\Composer\Cache\vcs\（Windows），存储Git等VCS裸克隆，单个仓库可达数百MB甚至1GB以上，且不会被composer clear-cache智能甄别清理，需手动定期删除冗余子目录以释放空间。
Composer的vcs缓存到底存在哪、占多大空间
Composer把Git等VCS仓库的裸克隆（bare clone）存在~/.composer/cache/vcs/（Linux/macOS）或%APPDATA%\Composer\Cache\vcs\（Windows）。它不是每次composer install都重新拉代码，而是复用这个目录下的git仓库快照——所以一个私有包被多个项目引用，只会存一份裸仓库，但分支多、tag多、历史提交深的仓库，单个目录就可能达几百MB甚至1GB以上。
这个目录不会随composer clear-cache自动清理旧内容，因为Composer默认认为“所有vcs缓存都可能被下次需要”，所以长期不清理会越积越多。
手动清vcs缓存比配参数更实际
Composer没有类似cache-files-maxsize那样的vcs-cache-maxsize配置项，也没有--prune-vcs命令。所谓“限制空间占用”，目前只能靠主动管理：
- 删整个
vcs/目录最彻底：rm -rf ~/.composer/cache/vcs/*（Linux/macOS）或直接清空Windows对应文件夹 - 删特定仓库：进
vcs/找含项目域名或组织名的子目录，比如gitlab.example.com$myorg$my-package.git/，整目录删掉 - 删完不影响功能——下次
composer update需要时会自动重建，只是首次拉取稍慢 - 别碰
vcs/外的其他缓存目录（如repo/），否则首次update可能卡在元数据同步
为什么不能只靠clear-cache解决vcs膨胀
composer clear-cache确实会清vcs/，但它是一次性全量操作，无法区分“哪些仓库还在用、哪些已废弃”。而真实场景中：
- 你可能已迁走某个GitLab项目，但
vcs/里还留着它的裸仓库 - 测试分支
dev/test-branch被删了，但vcs/里的ref信息没自动GC - CI流水线用临时用户跑过
composer install，残留的vcs/归属root或build用户，普通用户clear-cache删不掉
所以定期人工核查vcs/子目录修改时间（ls -lt ~/.composer/cache/vcs/），比依赖自动机制更可靠。
CI/CD和Docker中必须禁用vcs缓存
在无状态环境里保留vcs/不仅没意义，还会拖慢构建、浪费镜像体积：
- Docker构建时加
--no-cache或在composer.json里设"cache-vcs": false（注意：这不是官方配置项，无效）——正确做法是构建前清空或挂载空目录覆盖vcs/ - GitHub Actions中，在
steps开头加：run: rm -rf $HOME/.composer/cache/vcs
- GitLab CI中，用
before_script清理：before_script: - rm -rf "$COMPOSER_HOME/cache/vcs"
- 关键点：不要试图“限制”它，而是让它根本不存在——vcs缓存对CI是冗余开销
vcs缓存的设计初衷是给开发者本地反复调试私有包用的，一旦脱离这个场景，它就从加速器变成累赘。真正要盯的，是那些你半年没打开过的vcs/子目录，它们大概率已经失效，且占着最顽固的空间。
