Composer本身不支持冗余镜像仓库，repositories数组中写多个Packagist镜像会导致只取首个且不fallback，正确做法是仅配置一个稳定镜像并依赖服务端故障转移；cache-vcs缓存需手动清理或禁用，项目级repositories字段会完全覆盖全局repo.packagist配置。
Composer 本身没有“冗余镜像仓库”这个概念——你看到的所谓冗余，其实是配置错误、缓存堆积或行为误解导致的假象。真正要管的不是“镜像”，而是repositories数组写法、cache-vcs残留、以及repo.packagist和私有源的冲突逻辑。
为什么repositories里写多个镜像反而失效？
很多人把阿里云、腾讯云镜像都塞进repositories数组，结果发现只走第一个，或者报Package x is not available。这不是 Composer 懒，是它根本没打算让你这么用。
-
repositories是给私有包、VCS 仓库（Git）、Satis 或 Artifactory 这类非 Packagist 源设计的，不是给“多个 Packagist 镜像”准备的 - 写两个
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，Composer 会当它们是两个独立源，而不是“主备”——它不会 fallback，只会按顺序查，遇到 502/超时直接中断，不试下一个 - 更危险的是：如果没显式写
"packagist.org": false，Composer 会在你所有repositories查完后，自动追加官方源兜底，导致私有同名包被跳过 - 正确做法：只配一个稳定镜像（如
https://mirrors.tencent.com/composer/），靠服务端能力做故障转移；想多源轮询，得用composer-proxy或 DNS/hosts 层路由
cache-vcs才是真·冗余元凶，clear-cache默认不碰它
你以为composer clear-cache清完了就干净了？错。~/.composer/cache/vcs/里的 Git 裸仓库（每个包一个，300–800 MB）完全不在清理范围内，却是No space left on device和Inode use% 100%的头号黑手。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
df -i确认是不是 inode 耗尽——如果是，rm -rf ~/.composer/cache/vcs/立刻见效 - 一劳永逸：执行
composer config --global cache-vcs false，之后所有包强制走--prefer-dist，不再克隆 Git - 注意：
cache-vcs false后首次composer update会慢一点（重下 ZIP），但后续稳定，且彻底避开 Git 历史文件爆炸问题 - 别信“删
vendor/再重装就能清 VCS 缓存”——vendor/里的.git是 clone 副本，cache/vcs/才是源头缓存，两者互不影响
全局repo.packagist和项目级repositories谁赢？
命令行配了composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，但composer install还是卡在Loading composer repositories——大概率是项目composer.json里的repositories字段把它覆盖了。
- 优先级：项目级
repositories> 全局repo.packagist。只要composer.json里有repositories字段（哪怕空数组[]），全局镜像就失效 - 验证方法：
composer config -g repo.packagist看全局是否生效；composer config repo.packagist（不带-g）看项目级是否覆盖 - 安全追加镜像到项目：进项目根目录，运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（无-g），它会自动 merge 到repositories对象中，前提是原repositories是{}而非[] - 如果原
repositories是数组格式（[{"type":"vcs","url":"..."}]），该命令会失败，必须手动编辑composer.json，并在末尾加一条{"type":"composer","url":"..."}
最常被忽略的点：cache-dir路径可能被COMPOSER_HOME或团队自定义配置改过，composer clear-cache只清它指向的位置，不会遍历所有可疑目录。先跑composer config --global cache-dir确认真实路径，再动手——否则清了个寂寞。
