VCS缓存对composer update几乎无效，因其仅在--prefer-source模式下启用，而该模式会绕过ZIP缓存、克隆完整Git仓库，且vcs/目录不压缩、不校验、不跨项目共享，每次仍需git checkout等高开销操作。
Composer 的 VCS 缓存（vcs/ 目录）基本无法被 composer update 复用，强行依赖它提速反而会拖慢构建 —— 真正该盯紧的是 files/ 目录下的 ZIP 包缓存。
为什么 vcs/ 缓存对 composer update 几乎无效
VCS 缓存只在 --prefer-source 模式下起作用，而这个模式默认只在以下情况 fallback 触发：目标包没有 dist ZIP、镜像源返回 404、或你显式加了 --prefer-source。但生产环境更新必须禁用它 —— 否则每次都会克隆完整 Git 仓库，绕过所有 ZIP 缓存逻辑。
更关键的是：vcs/ 缓存本身不压缩、不校验、不跨项目共享；同一仓库不同分支的克隆会写入不同子目录，且 Composer 不会自动复用已有克隆来 checkout 新 commit —— 它宁可删掉重来。
-
vcs/缓存只保存裸仓库（.git），不保存工作区文件，每次仍需git checkout+git reset --hard，开销不小 - 即使本地有缓存，只要
composer.json中repositories配置变动，或 Git URL 带 query 参数（如?ref=dev），缓存就失效 - Docker 或 CI 中未挂载
~/.composer/cache/vcs，实际每次都是空的 —— 但你根本察觉不到
composer config -g cache-dir 必须是绝对路径且可写
很多人设了 cache-dir 却没提速，是因为 Composer 会静默 fallback 到系统临时目录（如 /tmp/composer），而那里无法跨构建复用。
确认方式不是看配置输出，而是直接检查目录是否存在、是否可写：
- 运行
composer config -g cache-dir，输出必须是类似/home/user/.composer/cache的绝对路径 - 手动执行
ls -ld $(composer config -g cache-dir)，确保属主有读写权限 - 进入该目录，检查
files/下是否有 ZIP 文件（如monolog/monolog/2.10.0.0/monolog-monolog-6a8c4b5.zip） - 若
files/为空，说明缓存根本没写进去 —— 常见于 Docker 未挂载、用户权限错误、或用了相对路径（如./cache）
真正影响 composer update 速度的三个硬条件
缺一不可，漏掉任一个，files/ 缓存就等于白配：
- 镜像源必须生效：
composer config -g repo.packagist输出得是https://mirrors.aliyun.com/composer/这类国内地址，且末尾带/；旧版 Composer 1.x 要用repos.packagist配置项 - 命令必须带
--prefer-dist：只有这个参数才会走 ZIP 下载路径，从而读取files/缓存；--prefer-source或不加参数都可能 fallback 到 VCS - 必须加
--no-dev：跳过 dev 依赖解析能减少 30–60% 的 dependency resolution 时间，尤其避免卡在Resolving dependencies阶段
正确命令示例：composer update --prefer-dist --no-dev --no-progress
Docker 和 CI 中缓存 vcs/ 是伪需求
在 docker-compose.yml 里挂载 ~/.composer/cache/vcs，或者在 GitHub Actions 中缓存 ~/.composer/cache/vcs，几乎不会带来任何收益 —— 因为构建时根本不会用到它。
你应该专注的只有两件事：
- 挂载或缓存
~/.composer/cache/files（GitHub Actions 用actions/cache，key 基于composer.lockhash） - 在多阶段 Docker 构建中，把
vendor/和~/.composer/cache/files/一起打进最终镜像，而不是指望容器启动时再“预热”
如果看到 CI 日志里反复出现 Cloning into '/tmp/xxx'，第一反应不该是优化 vcs/，而是检查是否误启了 --prefer-source、镜像源是否失效、或 composer.lock 是否引用了已下线的包。
