Composer不支持差异化镜像站权重分配，无权重、轮询、健康探测或自动fallback机制；镜像配置仅为单点元数据源替换，必须由DNS分流、代理网关或CI脚本等外部设施实现网络分区适配。
Composer 不支持“差异化镜像站权重分配”——它没有权重、轮询、健康探测或自动 fallback 机制。所谓“按网络分区动态切镜像”，必须由外部基础设施（如 DNS、代理网关、CI 脚本）实现，Composer 客户端本身只认一个 repo.packagist 配置，且不感知网络位置。
为什么 composer config repo.packagist 不能设权重或条件路由
Composer 的镜像配置本质是元数据源的单点替换，不是负载均衡器：
-
repo.packagist字段只接受一个 URL，后写覆盖前写，不存在数组或 priority 字段 - 它不发起任何探测请求，也不记录响应延迟或失败次数，更不会根据 IP 段/地理位置自动切换
- 所有依赖解析、
packages.json下载、版本匹配都走这一个地址；dist 文件下载则由composer.lock中记录的dist.url决定，与镜像配置无关 - 即使你用脚本在不同机器上写入不同镜像地址，那也只是静态覆盖，不是运行时决策
真正在用的网络分区适配方案（非 Composer 原生）
要让北京机房走阿里云镜像、深圳机房走腾讯镜像、海外走官方源，得绕开 Composer 配置本身：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 在 DNS 层做地理分流：把
repo.packagist.org解析到不同镜像站 IP（如北京→mirrors.aliyun.com，深圳→mirrors.tencent.com），Composer 完全无感 - 用公司统一 HTTP 代理，在出口网关层拦截对
repo.packagist.org的 HTTPS CONNECT 请求，按客户端 IP 重定向到对应镜像站（需支持 SNI 或证书透传） - CI/CD 流水线中根据 runner 标签注入环境变量：
COMPOSER_REPO_PACKAGIST=https://mirrors.tencent.com/composer/，再执行composer install - Docker 构建时用多阶段构建 + ARG：不同 region 的构建节点传入不同
--build-arg MIRROR_URL，在 RUN 步骤里动态composer config -g repo.packagist $MIRROR_URL
误用 repositories 数组模拟“权重”会出什么问题
有人试图在 composer.json 里写多个 packagist 类型源，指望 Composer 自动 fallback，结果往往失败：
- Composer 不会“尝试第一个，失败再试第二个”——它只对第一个匹配的源做完整依赖解析；若该源返回 404 或结构异常，直接报错
Could not find package - 如果你写了两个镜像地址，比如阿里云和腾讯云，Composer 会把它们当成两个独立仓库，同一包在不同源中可能有不同版本号或缺失
dist字段，导致install卡在 Resolving dependencies - 显式禁用默认源（
"packagist.org": false）后，又漏掉"type": "composer"或 URL 少斜杠，整个repositories就被忽略，退回到官方源 - 这种写法还会污染
composer.lock：lock 文件里会混入多个源的dist.url，下次换环境 install 可能因权限或网络不通而失败
真正需要跨网络分区自动适配的场景，别在 composer.json 或 config.json 里硬编码镜像地址——那只是把配置复杂度从运行时搬到了部署时。关键在于让镜像选择这件事，发生在 Composer 触发 HTTP 请求之前，而不是让它自己判断。
