单镜像源在ci/cd中易卡住流水线，因并发请求触发限流（如429）、dns抖动或同步延迟；需配置多镜像（canonical: false）+ 并行下载（parallel-downloads=15、http-max-concurrent-downloads=8）实现自动故障转移与高并发安装。
为什么单镜像源在CI/CD中容易卡住
CI/CD流水线批量触发 composer install 时，多个构建节点同时打向同一个镜像（比如阿里云或清华），极易触发服务端限流或 DNS 解析抖动，表现为大量 429 Too Many Requests 或 file_get_contents(): SSL operation failed 错误。这不是你机器的问题，而是单一镜像扛不住并发压力。
- 镜像站本身有连接数/请求数限制（如清华镜像默认每 IP 每分钟 60 次请求）
- DNS 缓存不一致导致部分请求仍打向已不可用的镜像地址
- 某个镜像同步延迟（如 dist 包已更新但源未同步），Composer 会反复重试失败路径
怎么配置多镜像实现自动故障转移
Composer 原生支持 mirrors 配置，但必须写在 composer.json 的 repositories 下，且需显式启用 canonical: false 才能启用负载分发逻辑。只改 repo.packagist 是不够的——那只是换源，不是均衡。
在项目根目录的 composer.json 中添加：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
{
"repositories": [
{
"type": "composer",
"url": "https://mirrors.tuna.tsinghua.edu.cn/composer/",
"canonical": false
},
{
"type": "composer",
"url": "https://mirrors.aliyun.com/composer/",
"canonical": false
},
{
"type": "composer",
"url": "https://mirrors.cloud.tencent.com/composer/",
"canonical": false
}
]
}
-
canonical: false是关键，缺了它 Composer 就只认第一个镜像，后面两个形同虚设 - 顺序不重要，Composer 内部会按响应时间动态选择“最优”镜像发起首次请求
- 一旦某个镜像返回 4xx/5xx 或超时，Composer 会自动 fallback 到下一个，无需人工干预
并行下载 + 多镜像 = 真正高并发安装
光配多镜像不等于快；必须确保 parallel-downloads 和 http-max-concurrent-downloads 同时生效，否则所有请求还是串在一条线上排队。
- 检查是否启用：运行
composer config -g parallel-downloads，输出应为15（推荐值） - 确认 HTTP 并发上限：运行
composer config -g http-max-concurrent-downloads，建议设为8 - 验证是否真并发：加
-vvv运行composer install，日志里应看到多条Downloading https://...交错出现，而不是逐行等待 - 注意冲突：若全局设置了
COMPOSER_DISABLE_PARALLEL=1环境变量，所有并发配置都会被无视
CI 环境下最容易被忽略的三个点
本地跑得通 ≠ CI 上不出问题。很多团队在 GitHub Actions 或 GitLab CI 里踩坑，核心是环境隔离和缓存策略没对齐。
- CI runner 默认不继承你的全局镜像配置，必须在 job 步骤里显式执行
composer config -g repo.packagist ...或写入composer.json -
vendor/目录不能靠actions/cache简单缓存——如果镜像源变了、composer.lock更新了，缓存 vendor 可能导致依赖版本错乱或 autoloader 加载失败 - 别在 CI 中用
--no-scripts跳过脚本后又忘记补composer dump-autoload --optimize，这会导致生产环境class not found
