Composer的VCS缓存路径位于cache-dir配置值下的vcs/子目录，如~/.composer/cache/vcs/（macOS/Linux）或%APPDATA%\Composer\Cache\vcs\（Windows），不可单独配置，需确保目录存在且权限正确。
Composer的VCS缓存路径在哪？
Composer在macOS中把Git等版本控制系统元数据缓存到 ~/.composer/cache/vcs/，不是独立配置项，而是 cache-dir 下的子目录。也就是说，改 cache-dir 就自动改了VCS缓存位置，不需要单独设 vcs-cache-dir 这种不存在的配置。
执行 composer config --global cache-dir 查看当前值；若输出是 /Users/xxx/.composer/cache，那VCS缓存就在 /Users/xxx/.composer/cache/vcs/。这个路径必须手动创建、设对权限，否则 Composer 会静默 fallback 到默认位置——你根本察觉不到它没生效。
为什么 composer clear-cache 后 VCS 缓存还在？
composer clear-cache 确实会清掉 vcs/ 目录，但有两个常见漏点：
- 本地
path类型仓库的 Git clone 快照可能被保留在~/.composer/cache/vcs/下，但 Composer 不会主动删掉“正在被引用”的快照，尤其当composer.json里repositories没刷新或写法有误时 - vendor 目录下的 symlink 指向旧 commit，
clear-cache完全不碰vendor/，所以看似更新了，实际加载的还是旧代码
真正干净的做法是：
- 先删
vendor/vendor/package-name（只删对应包，别动整个vendor） - 再删
~/.composer/cache/vcs/* - 最后跑
composer update vendor/package-name --no-cache -vvv，确认日志出现Cloning into...或Reading ./../my-package/composer.json
CI/CD 或 Docker 中 VCS 缓存失效的典型表现
在 macOS 本地配好 cache-dir 并验证过 composer diag 显示路径正确，但 CI 流水线里仍走默认缓存——大概率是用户权限或环境变量冲突：
- Docker 构建时若用
root执行composer config --global cache-dir /tmp/composer-cache，但后续composer install是以www-data用户运行，那/tmp/composer-cache目录就得提前chown www-data:www-data - 检查是否设置了
COMPOSER_CACHE_DIR环境变量：CI 脚本里常有export COMPOSER_CACHE_DIR=/cache，它优先级高于cache-dir配置，会直接覆盖你本地的设置 - GitHub Actions 的
cacheaction 默认缓存的是~/.composer/cache，如果你改了cache-dir却没同步更新 action 的path:字段，缓存就断掉了
怎么确认 VCS 缓存真被用了？
别信 composer config 输出，也别只看 clear-cache 是否报错。最靠谱的验证方式只有两个：
- 执行
composer install -vvv | grep "Cloning\|Writing into cache"，如果看到类似Writing into cache /data/composer-cache/vcs/https---github.com-myorg-mypkg.git/，说明 VCS 缓存路径已生效且正在写入 - 改一次本地 Git 仓库的
composer.json（比如加个空格再删掉），然后composer update --no-cache -vvv，观察是否触发重新读取；若仍显示Using version x.x.x from cache，说明缓存机制或repositories配置仍有问题
VCS 缓存路径本身不难设，难的是它和权限、环境变量、CI 缓存策略、以及 path / vcs 仓库类型的交互逻辑——这些地方一环没扣紧，就会出现“明明改了却没效果”的情况。
