Composer不支持多镜像自动fallback，容灾必须依赖外部脚本探测镜像可用性、动态切换源并清除元数据缓存；其缓存机制会将502/503等错误响应误存为有效元数据，导致后续请求直接读取损坏缓存而集体卡死，需手动清理repo/目录并配合curl探活与--no-cache安装。
Composer 镜像源本身不会“雪崩”，但当大量项目共用同一镜像、且配置不当或缺乏容灾边界时，一个节点抖动会引发连锁超时、缓存污染扩散、甚至构建失败——这不是镜像站的问题，而是你没关掉 Composer 的隐式 fallback 和缓存复用。
为什么composer install会因单个镜像抖动集体卡死
Composer 不做重试，也不换源，但它会把元数据（packages.json）缓存到 ~/.composer/cache/repo/https---mirrors.aliyun.com-composer/。一旦这个缓存被写入损坏内容（比如 502 响应体被误存），后续所有 composer install 都会直接读坏缓存，连请求都不发——看起来像“全挂了”，实则是本地缓存中毒。
- 镜像站返回非 200 响应（如 503）时，Composer 默认把它当有效响应存进缓存，下次就不再联网校验
-
composer clear-cache只清内存和部分缓存，不自动清理repo/下的元数据缓存目录 - Docker 构建中若复用
~/.composer/cache卷，一个失败构建会污染整个缓存层，下游所有构建都继承问题
composer config -g repo.packagist不是万能开关，它会被三类场景静默覆盖
全局配置只在“无项目级 repositories”时生效。而现实中，这三类情况会让 repo.packagist 形同虚设：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 项目
composer.json里写了空"repositories": {}—— 这会禁用默认源，包括你配的全局镜像 - CI 脚本里执行了
composer config repo.packagist ...（没加-g），结果写进项目级配置，覆盖全局 - 某些框架脚手架（如 Laravel Installer）生成的
composer.json自带"packagist.org": false，但没指定替代源，导致 Composer 直接报错退出
防“羊群效应”的四个硬性动作
别指望 Composer 自己 fallback，得靠外部控制流+明确边界：
- 每次部署前强制清元数据缓存：
rm -rf ~/.composer/cache/repo/https---mirrors.aliyun.com-composer/ - 用
curl -I -s -o /dev/null -w "%{http_code}" https://mirrors.aliyun.com/composer/packages.json探活，非 200 就切备用源（如清华源），再执行composer config -g repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/ -
composer install必须加--no-scripts --no-autoloader --no-dev，避免脚本失败中断流程；之后单独跑composer dump-autoload -o - 所有 CI 流水线开头加
composer diagnose | grep "secure-http\|signature"，确保签名验证开启，防止缓存污染包被静默安装
最易被忽略的点：镜像源地址是否带结尾斜杠、type 字段是否显式写出、缓存是否真被清掉——这三个字符级细节，决定你是“加速”还是“集体卡死”。
