Composer不支持多节点负载均衡，需通过项目级composer.json声明多个镜像、顺序兜底及并发参数调优实现容灾；全局配置无法同步因路径与用户权限差异，且镜像URL格式、结构、顺序等均须严格符合规范。
Composer 本身不支持多节点负载均衡，所谓“同步镜像源”实际是靠项目级 composer.json 显式声明多个镜像 + 顺序兜底 + 并发参数调优来模拟容灾能力。全局配置 composer config -g repo.packagist 只能设一个值，跨机器写死命令根本不可靠。
为什么 composer config -g 在多节点上无法真正同步
它把配置写进每个用户的 ~/.composer/config.json，而 CI 容器、宝塔的 www 用户、Docker 的 runner 用户路径全不同。更隐蔽的是：有人用 sudo composer config -g 写进了 root 配置，但 PHP 进程以 www-data 身份运行，结果镜像完全不生效。
-
repo.packagist键名必须拼写准确——多一个s（repos.packagist）就静默失败 - 命令中中间的
composer是 type 值，漏掉会 fallback 到官方源 - URL 必须是 HTTPS 且末尾带
/，否则请求变成/composerpackages.json导致 404 - Windows 用户改完需重启终端，否则环境变量未刷新
项目级 composer.json 中正确声明多镜像的写法
这是唯一可版本化、可复现、能随 Git 提交到所有节点的方案。注意结构必须严格，少一行或多一个逗号都会让 Composer 忽略整个 repositories 数组。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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里 -
repositories必须是数组，不能是对象；第一项必须是{"packagist.org": false}独立对象 - 镜像 URL 顺序即优先级：阿里云在前，清华在后，超时或 502 不会自动切，只有明确 404 才往下查
- 每个镜像 URL 末尾必须有
/，可用curl -I https://mirrors.aliyun.com/composer/packages.json验证返回 200
{
"repositories": [
{"packagist.org": false},
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"},
{"type": "composer", "url": "https://mirrors.tuna.tsinghua.edu.cn/composer/"},
{"type": "composer", "url": "https://mirrors.tencent.com/composer/"},
{"packagist": true}
],
"packagist.org": false
}
提升并发的关键参数：不只是换镜像
单镜像扛不住 CI 批量构建，不是因为“选错了源”，而是所有节点挤在同一个 IP 下载 dist 包，触发服务端限流（如 429 Too Many Requests）。这时靠 fallback 没用，得让单次 install 自己并发拉取。
- 加
"config": {"parallel-downloads": 10, "http-max-concurrent-downloads": 10}到composer.json根节点 - 避免手动设
http.timeout：默认 30 秒，DNS 卡住或 TLS 握手慢就会拖满半分钟，不推荐调低 - CI 环境中务必清缓存：
composer clear-cache，并删掉旧vendor和composer.lock再重装 - 私有 VCS 源（如 GitLab 包）要插在镜像数组之后、
{"packagist": true}之前，否则同名包可能被覆盖
CI/CD 中自动探活切换镜像的最小可行脚本
别指望 Composer 自己重试或测速。真要主备切换，必须用外部逻辑控制——比如在 GitHub Actions 或 GitLab CI 的 setup 步骤里跑一段 shell。
- 先
curl -s -o /dev/null -w "%{http_code}" https://mirrors.aliyun.com/composer/packages.json测状态码 - 只接受 200，其他一律 fallback 到清华或腾讯
- 用
composer config repo.packagist composer <url>动态写入当前项目composer.json - 执行前加
composer clear-cache，否则 HTTP 缓存可能让旧镜像请求继续发出 - 不要用
sed或jq直接改config.json：Composer 加载时只读第一个repo.packagist字段，脚本写错位置等于白干
最易被忽略的一点：所有镜像都必须能返回合法的 packages.json，且元数据同步延迟不能超过 1 小时，否则新发布的包会报 Could not find package——这不是配置问题，是镜像站自身的同步机制缺陷，得靠 {"packagist": true} 兜底，而不是硬等某个镜像追平。
