Composer不支持多源并行下载，仅按repositories顺序查找，首个返回有效元数据的源即被全程使用；需禁用默认源、设阿里云为首位镜像、官方源作兜底，并通过脚本+curl检测实现动态切换。
Composer 本身不支持多源并行下载，也没有“最优链路选择算法”——它按顺序查源，不并发拉包，也不测速或切链路。
为什么不存在真正的多源并行下载
Composer 的 repositories 是静态顺序列表，不是负载均衡器。它只做“命中即用”，不会同时向阿里云、腾讯云、官方源发请求；也不会根据响应时间自动切换。所谓“多镜像”，本质是 fallback（失败后才试下一个），且默认等待 30 秒才放弃当前源。
- 并发下载只发生在单个源内部：比如从
https://mirrors.aliyun.com/composer/同时拉多个 ZIP 包，靠http-max-concurrent-downloads - 多个
type: "composer"源共存时，Composer 只会用第一个能返回有效packages.json的源来解析所有包名 —— 后面的源根本不会被用于下载 dist 文件 - dist 文件（ZIP）的真实 URL 来自元数据，不是你配置的镜像地址；如果某个包的
dist.url写死为 GitHub，那 Composer 就直连 GitHub，绕过所有镜像
怎么让 Composer 实际走更快的源
关键不是“多源并发”，而是确保 99% 的包都从响应最快的镜像拉取，且失败时能快速降级。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须关闭默认源：
"packagist.org": false写在composer.json根节点，否则你配的镜像只是“额外仓库”，不替代主流程 - 把最快镜像放
repositories数组第一位，例如阿里云："url": "https://mirrors.aliyun.com/composer/" - 第二位放兜底源（如官方源），但要接受它慢——这是唯一合法 fallback 方式
- 别在
repositories里混写type: "vcs"和type: "composer"，前者不参与包发现，后者才管元数据
如何模拟“链路选择”效果（实操方案）
Composer 不做链路选择，但你可以用脚本在运行前动态选源 —— 这是 CI/CD 中最稳妥的做法。
- 用
curl -I -s -o /dev/null -w "%{http_code}" https://mirrors.aliyun.com/composer/packages.json测镜像存活状态 - 若返回非
200，立刻切到腾讯云：composer config -g repo.packagist https://mirrors.cloud.tencent.com/composer/ - 每次切换后必须执行
composer clear-cache，否则旧元数据残留会导致 404 - 临时设置优先于全局配置，项目级
composer.json中的repositories会覆盖全局repo.packagist，调试时注意层级
容易被忽略的瓶颈点
就算你把阿里云、腾讯云、华为云全写进 repositories，只要没关掉默认源、没清缓存、没验证日志里的实际域名，所有优化都白搭。
-
composer install -vvv日志里出现Downloading https://packagist.org/？说明镜像根本没生效 -
composer config -g repo.packagist输出仍是https://packagist.org/？说明配置命令没跑对或被项目级配置覆盖 - 看到多个
Downloading行但进度卡在 (1/42) → (2/42) 跳得很慢？问题不在源数量，而在 DNS 或 TLS 握手——换镜像 + 调高http-max-concurrent-downloads才治本
