composer update仍克隆Git仓库，是因为--prefer-dist对VCS源（如"type": "vcs"或直连GitHub/GitLab的私有仓库）无效，Composer默认强制走--prefer-source；缓存不参与代码拉取，仅加速元数据探测。
为什么composer update还在克隆Git仓库？
缓存对VCS（Git、SVN等）项目基本无效，因为Composer默认走--prefer-source路径——它不下载ZIP，而是直接git clone。这个过程完全绕过~/.composer/cache/files/，也无法复用已有包。
常见现象：明明配了国内镜像、--prefer-dist，但日志里仍出现Cloning https://github.com/symfony/console.git；cache-dir下vcs/目录有内容，但每次更新都重来。
-
--prefer-dist只对Packagist托管的dist包生效，对"type": "vcs"或"url"直连GitHub/GitLab的仓库无效 - 私有仓库、
repositories里手动加的git@或https://源，默认强制--prefer-source -
vcs/缓存仅用于加速“元数据探测”，比如判断分支是否存在，不参与实际代码拉取
preferred-install配置怎么真正起作用？
必须在composer.json根级显式声明"preferred-install"，且键名要精确匹配vendor或包名，不能靠全局设置覆盖。
例如想让所有myorg/*走dist，但monolog/monolog仍走source：
{
"preferred-install": {
"myorg/*": "dist",
"monolog/monolog": "source"
}
}
- 该配置只在
composer install或update时读取，改完后需删vendor/和composer.lock再重装才生效 - 若包本身没有dist ZIP（如私有GitLab仓库未启用Package Registry），Composer会静默fallback到source，不报错
- 使用
composer config --global preferred-install dist是无效的——此命令只影响新包安装策略，不改变已有repositories定义的行为
Git仓库怎么强制走镜像加速？
镜像源（如阿里云、腾讯云）只代理Packagist元数据（packages.json），不托管原始Git仓库。所以codeload.github.com或gitlab.com的请求仍会直连。
真实可行的加速手段只有两个：
- 用
ghproxy.com类反向代理：把"url": "https://github.com/user/repo"改成"url": "https://ghproxy.com/https://github.com/user/repo"，让Git克隆走代理中转 - 在CI/CD中预置Git缓存：GitLab CI用
cache: key: $CI_COMMIT_REF_SLUG-git-cache缓存~/.composer/cache/vcs/，并设git config --global url."https://ghproxy.com/".insteadOf "https://github.com/" - 避免在
repositories里写裸Git URL；优先用Packagist托管的dist包，或自建Satis服务统一发布ZIP
为什么~/.composer/cache/vcs/越来越大却没提速？
vcs/目录缓存的是Git仓库的“浅克隆”和ref信息（如refs/heads/main SHA），不是完整代码。它的作用仅限于：composer update前快速校验分支是否存在、最新commit是否变化。一旦决定要安装，Composer仍会执行全新git clone --no-checkout。
- 缓存体积增长快，是因为每个Git URL+分支组合都会生成独立子目录，不同项目共用同一全局缓存时极易冗余
- Docker构建中若未挂载
~/.composer/cache/vcs，每次都是空缓存，但git clone仍会走本地.git目录的packfile复用（如果基础镜像已含） - 真正减少Git开销的方式是：删掉
repositories里非必要源，禁用xdebug（它会让git调用慢5倍以上），并确保memory_limit≥ 512M
最常被忽略的一点：VCS优化永远比不上换源+dist。只要包能上Packagist，就别手动加Git仓库——哪怕只是多加了一行"type": "vcs"，整个依赖树的解析逻辑都会降级。
