私有VCS仓库拉取慢是因为镜像源仅代理packagist.org元数据，对"type": "vcs"完全无感知；Composer每次解析版本均执行原生git命令（如ls-remote或clone），不经过任何HTTP镜像代理。
私有 VCS 仓库的缓存行为不由镜像源控制，也不受 repo.packagist 配置影响；Composer 会为每个 vcs 类型仓库单独缓存元数据和 Git 克隆内容，路径在 {$cache-dir}/vcs 下，且无法通过全局镜像“加速”私有源拉取。
为什么配了腾讯云/阿里云镜像，私有 GitLab 仓库还是慢？
镜像源只代理 packagist.org 的公开元数据，对 "type": "vcs" 条目完全无感知。Composer 每次解析私有包版本（比如 dev-main 或 ^2.0）时，都会执行一次 git ls-remote 或完整克隆，这些操作走的是原生 Git 协议，不经过任何 Composer 镜像代理。
- 现象：运行
composer update时卡在Reading composer.json of your-org/private-pkg (dev-main)几十秒 - 本质：这是 Composer 在
git ls-remote https://gitlab.example.com/your-org/private-pkg.git，不是 HTTP 请求，没法被镜像加速 - 验证方法：加
-vvv参数，看日志里是否出现Executing command (/tmp/...): git ls-remote --heads ...
如何清理 VCS 缓存并强制刷新私有仓库元数据？
VCS 缓存分两层：Git 远程引用缓存（ls-remote 结果）和实际克隆副本（用于读取 composer.json）。二者都存在 {$cache-dir}/vcs 目录下，但结构由 URL 哈希决定，不能手动删子目录——必须用 Composer 命令或清整个缓存。
- 推荐方式：运行
composer clear-cache，它会清空{$cache-dir}/vcs和{$cache-dir}/repo，最彻底 - 精准方式：先查缓存位置
composer config cache-dir，再进$(composer config cache-dir)/vcs找到对应仓库的哈希目录（通常含 URL 片段），rm -rf掉它 - 注意：删完后首次
composer update会重新git clone，耗时更长，但后续ls-remote会快很多 - 若用 SSH URL（如
git@gitlab.example.com:org/pkg.git），缓存目录名可能含gitlab.example.com，但不保证可读，别依赖路径名判断
能否跳过 VCS 元数据检查、直接用本地已知版本？
可以，但需放弃语义化版本动态解析，改用 path 类型仓库 + "*" 约束。这本质是绕过 Git 操作，把本地目录当“已编译包”挂载。
- 适用场景：CI 构建中已 checkout 私有包到
./packages/private-pkg，想跳过重复 clone - 配置示例（写入项目
composer.json的repositories）：{ "type": "path", "url": "./packages/private-pkg" } - require 中必须写
"your-vendor/private-pkg": "*"，写dev-main或1.2.3会失败 - 副作用：不再响应远程分支更新，
composer update不会拉新 commit，只认该目录下composer.json里的version字段
VCS 缓存不可代理、不可跳过 Git 操作，这是设计使然。真正要优化的不是缓存本身，而是减少 ls-remote 触发频率——比如避免在 CI 中对每个 job 都跑 composer update，改用 composer install + 提前生成的 composer.lock。
