Composer的VCS缓存目录路径需通过composer config --global cache-dir获取根路径后拼接/vcs/，Linux/macOS默认为~/.composer/cache/vcs/，Windows为%APPDATA%\Composer\Cache\vcs\，不可直接猜测或依赖其他命令。
Composer 的 VCS 缓存目录路径怎么查
Composer 把 Git/Hg/Svn 仓库的裸克隆（bare clone）存在 cache/vcs/ 下，不是项目里 .git 那种工作目录。它不随项目走，是全局复用的——所有项目只要 require 同一个 Git URL，就共用同一个 vcs/ 子目录。
查真实路径最准的方式是运行：composer config --global cache-dir，然后拼上 /vcs/。Linux/macOS 通常是 ~/.composer/cache/vcs/，Windows 是 %APPDATA%\Composer\Cache\vcs\。
别依赖 which composer 或 composer --version——它们不暴露缓存位置；也别直接猜 ~/.composer/vcs，那是错的，vcs/ 必须在 cache/ 内部。
为什么 composer clear-cache 有时没清掉 VCS 缓存
composer clear-cache 默认会清 vcs/，但有三个常见例外：
- 命令执行时有其他 Composer 进程正在用某个 vcs 目录（比如另一个终端正
composer update），那对应子目录会被跳过，不报错也不提示 - 你设置了
COMPOSER_CACHE_DIR环境变量但没导出（export COMPOSER_CACHE_DIR=...），clear-cache实际清的是空路径或默认路径 - CI/CD 脚本里用
sudo执行了composer install，导致vcs/下部分目录属主是 root，而后续普通用户跑clear-cache没权限删
验证是否真清了：进 vcs/ 目录后 ls -A | head -5，如果还有一堆十六进制命名的子目录（如 github.com-2a7b1f9c1e...），说明没清干净。
手动清理 VCS 缓存的安全操作方式
VCS 缓存可以整删，下次需要时自动重建，比 files/ 更“无害”。但别用 rm -rf ~/.composer/cache 全删——那会连 repo/ 和 files/ 一起干掉，可能影响元数据一致性。
推荐做法：
- Linux/macOS：
rm -rf $(composer config --global cache-dir)/vcs/* - PowerShell（Windows）：
Remove-Item "$env:APPDATA\Composer\Cache\vcs\*" -Recurse -Force - Cmd（Windows）：
rd /s /q "%APPDATA%\Composer\Cache\vcs"，再mkdir "%APPDATA%\Composer\Cache\vcs"
注意：vcs/ 下的子目录名是根据 Git URL + reference（如 dev-main）哈希生成的，删了不影响其他 URL；但如果你正在调试某个特定 Git 包，删完后首次 composer update 会多花几秒重新 clone。
VCS 缓存残留会导致什么典型问题
最常被误判为“网络问题”或“版本没更新”的现象，其实根子在 vcs/：
- 本地改了 Git 包的代码，
composer update vendor/package却没拉新提交——因为 Composer 复用vcs/里旧的裸仓库，直接 checkout 已有 commit - 删了远程分支，但
composer update仍尝试 fetch 它，报错fatal: couldn't find remote ref refs/heads/old-branch——旧 ref 信息卡在vcs/的packed-refs里 - 同一 Git URL 用不同 protocol（
https://vsgit@）配置了多个 repository，结果vcs/里存了两份几乎一样的裸仓库，浪费空间且易冲突
这类问题不会出现在 files/ 或 repo/ 里，只盯 vcs/ 就对了。它不像 lock 或 vendor 那样牵一发而动全身，但恰恰是最容易被忽略的“静默污染源”。
