Composer 不支持多个 packagist 镜像自动主备，因设计上禁止 repositories 中存在多个 type="composer" 且指向 packagist 的源，否则报 Invalid repository type；主备需靠外部脚本探测可用镜像并动态配置，同时必须 clear-cache、禁用 packagist.org、更新 vendor/ 和 composer.lock 才生效。
Composer 本身不支持“多个 packagist 镜像源自动备用”，强行配置会直接报错 Invalid repository type；所谓主备切换，必须靠外部脚本控制，不能依赖 Composer 自身逻辑。
为什么 repositories 里写两个 packagist 类型源就失败
Composer 认为 packagist 是全局唯一的元数据源，校验时只要发现多个 {"type": "composer", ...} 同时声明为 packagist（或未显式命名但类型冲突），就会拒绝加载整个 repositories 段。错误信息通常是：
Invalid repository type: multiple repositories of type "composer" declared for "packagist"
这不是配置顺序或网络问题，是设计限制——它根本不允许解析第二条。
- 不能在
composer.json的repositories数组里并列写{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}和{"type":"composer","url":"https://mirrors.cloud.tencent.com/composer/"} - 也不能用
composer config多次设置repo.packagist，后一次会完全覆盖前一次 -
packagist.org必须显式设为false，否则即使配了镜像，Composer 仍会先连官方源，超时才 fallback（实际并不 fallback，而是报错中断）
真正可行的“主备”只能靠 shell 脚本控制
CI/CD 或本地自动化中，需手动探测镜像可用性，再动态设置源。Composer 自身无重试、无降级、无超时重定向能力。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先用
curl -I -s -o /dev/null -w "%{http_code}" https://mirrors.aliyun.com/composer/packages.json测阿里云根路径 HTTP 状态码，200才认为可用 - 若失败，换腾讯云地址再测；两次都失败，可 fallback 到 Laravel China 或直接 warn 并 abort
- 探测成功后，执行
composer config --global repo.packagist composer https://xxx/（注意末尾必须带/） - 必须紧接着运行
composer clear-cache，否则旧缓存可能继续发请求到已失效的源
别省略 clear-cache：Composer 的 HTTP 缓存（~/.composer/cache）可能保留上一次失败的 DNS 解析或 404 响应，导致脚本判定成功后仍卡住。
项目级配置比全局更可控，但要注意格式陷阱
进项目根目录后执行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/，它会向 composer.json 写入 "repositories" 对象，但前提是原字段是对象而非数组。
- 如果
"repositories": []（空数组），命令会失败，提示无法写入；需手动改为"repositories": {} - 写入后结构必须是：
"repositories": { "packagist": { "type": "composer", "url": "https://mirrors.aliyun.com/composer/" }, "packagist.org": false } - 漏掉
"packagist.org": false，或把它写进"packagist"对象内部，都会导致 Composer 仍尝试连接官方源 - 换源后必须删掉
vendor/和composer.lock，否则composer install仍按 lock 文件里的原始 URL 下载，和镜像无关
验证是否真走镜像的唯一可靠方式
别信 composer config -g repo.packagist 输出看起来对——它只说明配置写进去了，不说明生效了。优先级永远是：项目 composer.json 中的 repositories > 全局 ~/.composer/config.json > 默认源。
- 运行
composer install -vvv，滚动到底部找日志行，确认出现类似Reading packages.json from https://mirrors.aliyun.com/composer/packages.json - 或者临时加环境变量测试：
COMPOSER_REPO_PACKAGIST=https://packagist.phpcomposer.com composer install -vvv，看日志是否命中该域名 - CI 中若用
sudo composer config -g，很可能写进了root用户的配置，但构建用的是普通用户，根本读不到——应改用项目级配置或明确指定用户执行
最常被忽略的一点：镜像只影响包下载路径，不影响依赖解析速度。如果卡在 Resolving dependencies，和镜像无关，得查 PHP 版本、composer.lock 冲突或内存限制。
