composer clear-cache 不清理私有 GitLab 仓库缓存，因为它默认跳过 vcs/ 目录；GitLab 裸仓库缓存（300–800 MB）存放于 ~/.composer/cache/vcs/ 下，需手动删除对应域名子目录，如 *gitlab.com*，并确保无后台 composer 进程运行。
为什么composer clear-cache不清理私有GitLab仓库缓存
因为 Composer 默认跳过 vcs/ 目录——它把私有 Git 仓库（包括 GitLab）的裸克隆缓存放在 ~/.composer/cache/vcs/ 下，而 composer clear-cache 只清 files/ 和 repo/，对 vcs/ 完全无视。一个 GitLab 项目裸仓库常占 300–800 MB，还可能耗尽 inode，但命令执行后你完全看不到变化。
手动删 GitLab 仓库缓存的正确路径和命令
先确认真实缓存位置：composer config --global cache-dir，再进 vcs/ 子目录找 GitLab 相关条目。GitLab 仓库缓存名通常含 gitlab.com 或你的自建域名（如 git.example.com），后面跟着哈希值。
- Linux/macOS：
rm -rf ~/.composer/cache/vcs/*gitlab.com*或更精准地rm -rf ~/.composer/cache/vcs/*your-gitlab-domain.com* - Windows PowerShell：
Remove-Item -Recurse -Force "$env:APPDATA\Composer\Cache\vcs\*gitlab.com*" - 删之前务必确保没有
composer install或update进程在后台运行，否则可能触发Corrupted cache file报错
删完仍拉不到最新提交？检查 Git 配置和锁文件
私有 GitLab 仓库更新失败，往往不是缓存问题，而是 Composer 锁定了旧 commit 或凭证失效：
Git Changelog Generator
下载
使用约定式提交（Conventional Commits）从 Git 历史记录中生成结构化变更日志，支持多种格式、AI 增强型描述以及可自定义的范围……
-
composer.lock中记录了source.reference，如果没跑composer update vendor/package，它不会自动刷新到最新 commit - 若用 token 认证，检查
auth.json里gitlab.com对应的 token 是否过期或权限不足（需apiscope） - GitLab 私有组/项目若启用了
project visibility限制（如 internal），确保 token 所属账号有访问权限 - 临时验证：手动
git clone https://gitlab.com/xxx/yyy.git看是否能通，排除网络或认证层问题
如何避免下次又堆满 vcs/ 缓存
Composer 不提供自动清理 VCS 缓存的机制，长期方案只有两个方向：
- 禁用 VCS 缓存（适合 CI 或只读环境）：
composer config -g cache.vcs false，之后所有 Git 操作走干净克隆，不存裸仓库 - 改用 dist 包而非 source：在
composer.json中为私有包显式加"dist": {"url": "https://...", "type": "zip"}，绕过 Git 克隆流程 - 定期脚本清理（仅限多项目维护）：
find ~/.composer/cache/vcs -maxdepth 1 -name "*gitlab.com*" -mtime +180 -exec rm -rf {} \;，删 6 个月未访问的 GitLab 缓存
真正麻烦的从来不是“怎么删”，而是删完发现 GitLab 仓库根本没被 Composer 当作源地址识别——比如配置写成 repos.packagist 而不是 repo.packagist，这种拼写错误会让所有缓存操作都白费。
