Composer 不支持源站负载均衡或弹性伸缩，多活与自动切换需由外部反向代理（如Nginx）实现；repositories数组仅顺序尝试且并发请求，无法替代负载均衡；正确方案是统一入口+健康探测+共享静态文件存储+环境变量注入镜像地址。
Composer 本身不支持源站负载均衡或弹性伸缩——所有“多活”“自动切换”“扩容降级”都必须由外部基础设施实现，不是靠 composer.json 或 composer config 配置出来的。
为什么 repositories 数组不能当负载均衡用
很多人在 repositories 里堆三个国内镜像，以为能自动分流或故障转移，实际是徒增风险：
- Composer 按数组顺序逐个尝试，只用第一个成功响应的源；其余请求仍会并发发出（尤其
packages.json），浪费带宽且拖慢首次安装 - 不同镜像同步延迟不一致（阿里云平均 2 分钟，中科大可能 8 分钟），导致同一
composer update在不同机器上解析出不同版本 - 第一个源卡在 TLS 握手或 DNS 解析时，会等满
http.timeout（默认 30 秒）才 fallback，期间整个依赖安装阻塞 - 禁用官方源后（
"packagist.org": false），后面两个源彻底失效，形同虚设
Nginx 反向代理集群 + 健康探测才是可行方案
真正落地 Active-Active 的核心，是把多个物理镜像抽象成一个统一入口，由反向代理层完成分发与熔断：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 上游配置必须启用
health_check interval=3 fails=2 passes=2，否则宕机节点持续被轮询 - 关键路径如
/packages.json、/p/<package>.json</package>需主动探活，不能只靠 TCP 端口通就认为服务可用 - 所有节点的
root必须指向同一份静态文件（NFS / MinIO / S3），否则packages.json里写的dist.url指向本地路径，其他节点 404 - 响应头务必加
Cache-Control: public, max-age=3600，避免客户端反复拉取元数据压垮源站
CI/CD 中如何避免硬编码镜像地址
开发环境写死镜像 URL 是运维灾难的起点。应统一通过环境变量注入：
- CI 流水线中设置
COMPOSER_MIRROR_URL=https://repo.phpmirror.net，由运维管控后端节点列表 - 本地开发用
COMPOSER_REPO_PACKAGIST=http://127.0.0.1:8080+composer-proxy进程，内部轮询并自动降级 - 禁止在
composer.json里写url字段，否则私有源和官方源冲突（"packagist.org": false必须显式声明） - 私有仓库 URL 末尾斜杠必须严格匹配
satis.json中的homepage，"https://packages.internal/"≠"https://packages.internal"
最易被忽略的是：Satis 生成的静态文件没有状态、不监听端口，它根本不是服务，而是构建产物。你不能对一个 satis build 进程做健康检查，只能对它输出的 packages.json 文件是否可读、内容是否一致做校验。所有 Web 节点看到的必须是同一份字节流，而不是“差不多”的 rsync 同步结果。
