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 是否过期或权限不足（需 api scope）
• 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，这种拼写错误会让所有缓存操作都白费。