Composer不支持负载调度，多源轮询、fallback、按延迟选源需外部脚本实现，其repo.packagist配置为单字符串，后设覆盖前设，官方明确拒绝多源支持。
Composer 本身不支持负载调度，所谓“多源轮询”“自动 fallback”“按延迟选源”全是外部逻辑，不是 composer config 能解决的。你配置的 repo.packagist.org 是单值字段，写两次，后一次直接覆盖前一次。
为什么 composer config -g repo.packagist 不能做负载调度
这个配置项底层就是一个字符串，不是数组，也不是策略引擎。执行：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ composer config -g repo.packagist composer https://mirrors.163.com/composer/
第二行会彻底抹掉第一行——没有并存，没有优先级，没有探测重试。官方 GitHub issue #8729 明确拒绝加入多源 fallback 支持。
常见误操作包括：
- 用空格拼两个 URL：
composer config -g repo.packagist composer https://a.com/ https://b.com/→ 只有第一个生效，第二个被忽略 - 以为
repositories数组能当 fallback 用 → 它只用于合并元数据，下载 ZIP 时只认第一个声明该包的源，502 或超时直接报错退出 - 没清缓存就换源 →
composer install仍从 ~/.composer/cache 读旧 packages.json，根本没发新请求
真正可行的负载调度必须靠外部脚本控制
CI/CD 中可落地的调度逻辑，本质是「测速 + 切源 + 清缓存」三步闭环，不是 Composer 功能，而是 shell 预处理：
- 用
curl -o /dev/null -s -w '%{time_total}\n' -L https://mirrors.aliyun.com/composer/packages.json测各镜像根路径延迟 - 取平均耗时最低的 URL，执行
composer config -g repo.packagist composer $URL - 强制清缓存：
composer clear-cache && rm -f composer.lock vendor/，避免旧 dist.url 干扰 - 加
-vvv验证真实请求：composer install -vvv 2>&1 | grep 'GET.*packages.json'确认 URL 域名正确
注意：Docker 构建中要确保脚本在 RUN 阶段执行，而非 build-arg 传参后静态写入，否则缓存会跳过测速逻辑。
项目级 repositories 写法对调度的影响
一旦项目 composer.json 中定义了 repositories 字段，全局 repo.packagist 配置完全失效。这意味着：
- 团队协作时，
repositories必须显式写进composer.json并提交 Git，否则 CI 和新人本地行为不一致 - 若想让项目也参与调度，得在 CI 脚本里动态改写
composer.json的repositories[1].url字段（用 jq 或 sed），再composer update --no-cache -
"packagist.org": false必须作为独立对象放在repositories数组首位，否则 Composer 仍会偷偷连官方源 - URL 末尾必须带
/，写成https://mirrors.aliyun.com/composer会导致请求路径拼成/composerpackages.json，404 后静默 fallback
最易被忽略的一点：镜像站本身是否启用 GSLB（智能 DNS）决定了“就近”是否真实有效。哪怕你脚本选了最快源，如果 dig mirrors.aliyun.com 在北京和广州返回同一个 IP，那所有用户其实都在打同一个中心节点——调度只是假动作。
