composer clear-cache对VCS仓库无效，因其仅清理~/.composer/cache/files/和部分索引，而Git类仓库缓存独立存于~/.composer/cache/vcs/，需手动删除该目录才能生效。
为什么composer clear-cache对VCS仓库无效？
因为composer clear-cache只清~/.composer/cache/files/和部分索引，但VCS类仓库（Git）的缓存存在~/.composer/cache/vcs/下，是独立的裸仓库目录。它不会被自动清理，也不会在下次update时自动刷新——Composer会直接复用旧克隆，哪怕远程分支已变。
- 运行
composer update时若日志里出现Cloning into bare repository，说明首次拉取；后续再跑，大概率跳过，直接用缓存 - 但一旦你本地改了
repositories配置、切了分支、或远程强制推送过，缓存就可能 stale，导致拉不到最新 commit -
rm -rf ~/.composer/cache/vcs/*才是针对 VCS 的有效清理动作（Linux/macOS）；Windows 对应路径是%APPDATA%\Composer\Cache\vcs\ - 删完别急着
update，先确认composer.json里repositories字段没被其他源覆盖（比如空对象{}或含packagist），否则整个块会被忽略
composer update仍卡在 Git 克隆？检查这三处配置
VCS 仓库慢，不一定是网络问题，常是 Composer 自身行为被误配触发 fallback。重点看是否同时满足：
-
--prefer-dist没加：缺这个参数，Composer 默认 fallback 到--prefer-source，强制走 Git clone，完全绕过 ZIP 缓存 - 镜像源配错：
composer config -g repo.packagist输出必须是带/结尾的国内镜像 URL（如https://mirrors.aliyun.com/composer/）。如果显示https://packagist.org或为空，VCS 请求仍会直连 GitHub，DNS 和 TLS 卡顿随之而来 -
github-protocols未设为https：运行composer config -g github-protocols https，避免 SSH 协议协商失败后重试 Git over SSH，尤其在 CI 环境中常见
手动加速 VCS 依赖下载：跳过 clone，用本地 ZIP 替代
如果你能提前拿到目标分支的 ZIP 包（比如从 GitHub Actions Artifacts 或 CI 构建产物里下载），可跳过整个 Git 流程：
- 先查缓存路径：
composer config --global cache-dir，进入files/子目录 - 按包名+版本构造 ZIP 名：例如
vendor/package/dev-feature.zip（注意dev-前缀和.zip后缀） - 把 ZIP 放进对应路径（如
~/.composer/cache/files/vendor/package/），确保文件权限可读 - 再跑
composer update vendor/package --prefer-dist --no-cache，Composer 会校验 SHA256 并跳过下载 - 注意：
--no-cache此时不是禁用缓存，而是跳过“检查已有缓存是否匹配”的逻辑，强制走 dist 路径并读你放的 ZIP
Docker/CI 中 VCS 慢？缓存挂载和 DNS 是关键
容器环境里 VCS 慢，90% 是因为缓存没挂载 + DNS 查询每次新建连接：
- 务必挂载
~/.composer/cache到宿主机卷，否则每次构建都是“裸跑”，vcs/和files/全丢 - Docker 启动时加
--dns 8.8.8.8 --dns 1.1.1.1，避免继承不可靠的内网 DNS - CI 脚本开头加
composer config -g repo.packagist https://mirrors.aliyun.com/composer/，别依赖全局配置——很多 CI 镜像根本不带预设 - GitHub Actions 中，
actions/checkout@v4之后再跑composer install，否则composer update可能因工作区未 ready 而反复重试 Git
VCS 仓库的“慢”往往不是单点问题，而是缓存路径、协议选择、DNS、镜像源四者联动失效的结果。逐项验证比盲目清缓存更省时间。
