Composer原生不支持多源fallback，仅首个可用源参与下载，失败不自动切换；可靠方案为服务端代理或客户端插件（如composer-plugin-mirror），禁用VCS缓存可防inode耗尽。
Composer 本身不支持多源 fallback，硬配 repositories 不会自动切换
你往 repositories 数组里塞多个 Packagist 镜像（比如阿里云 + 腾讯 + 官方），composer install 依然只从第一个能返回完整 packages.json 的源拉 ZIP，其余源完全不参与下载。超时、502、DNS 失败时直接报错退出，不会尝试下一个——只有 404 才往下走。所以这种配置不是“冗余”，而是“混乱”：
- 元数据合并顺序导致 dist URL 被覆盖，官方包可能仍走慢速私有源
- 私有源临时不可达，
composer update直接中断，不降级 - 同一个包在不同镜像中版本不一致，依赖解析失败概率上升
真正可用的冗余方案只有两种：服务端代理 or 客户端插件
想实现故障时自动切源，必须绕过 Composer 原生逻辑：
-
推荐用
composer-plugin-mirror：它在下载阶段拦截失败请求，按你配置的镜像列表顺序重试，直到成功或耗尽全部地址。兼容 Composer 2/3，无需改项目配置，只需全局安装：composer global require hellogerard/composer-plugin-mirror，再在~/.composer/config.json中加"mirrors"字段 - 或者部署一个带自动 failover 的反向代理服务（如 Nginx + health check），把
repo.packagist指向该代理地址。所有请求先经代理，由它决定转发到哪个镜像站——这层能力不在 Composer，而在你自己的基础设施里
别碰 config --global repo.packagist 多次设置
这条命令只能存一个值：composer config --global repo.packagist https://mirrors.aliyun.com/composer/ 之后再执行 composer config --global repo.packagist https://packagist.org，前者就被覆盖了。所谓“多镜像配置”，本质是把 repo.packagist 指向一个本身具备兜底能力的服务端（例如腾讯镜像），而不是本地拼凑一堆 URL。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 检查当前生效源：
composer config --global repo.packagist - 错误示范：
sed -i 's|https://.*|https://mirrors.tencent.com/composer/|' ~/.composer/config.json—— 手动改 JSON 容易格式错，且不如命令可靠 - 正确做法：只设一个稳定地址，把 fallback 逻辑交给服务端或插件
缓存目录里的 vcs/ 是隐形单点故障源
你以为镜像挂了才构建失败？其实更常见的是 ~/.composer/cache/vcs/ 目录占满 inode 导致 No space left on device，而这个目录默认不被 composer clear-cache 清理。
- 禁用 VCS 缓存：
composer config --global cache.vcs false - 立刻清理已有：
rm -rf ~/.composer/cache/vcs/（Windows 用rd /s /q "%APPDATA%\Composer\Cache\vcs"） - 配合设置 TTL：
composer config --global cache-files-ttl 604800（7 天），否则files/也会缓慢回涨
真正要防的不是镜像宕机，而是本地缓存失控后连基础命令都跑不起来——这点比源配置更容易被忽略。
