根本原因是packagist.org国内访问极慢且ci节点未预装镜像源，导致composer install卡在元数据拉取阶段；解决方法是在pipeline.yml中用composer config -g全局配置阿里云镜像源或通过composer_repo_packagist环境变量注入。
为什么阿里云效里 Composer 总是超时或失败
根本原因不是网络不稳定，而是默认的 packagist.org 在国内访问极慢，且阿里云效的构建节点不预装国内镜像源。CI 环境下没有用户交互，composer install 会卡在元数据拉取阶段，超时后直接报错：Failed to download ... Could not resolve host: packagist.org 或 Connection timed out after 300000 milliseconds。
解决思路不是“换网络”，而是让 Composer 在 CI 启动时就明确使用国内镜像源——必须在执行 composer install 前完成配置，且不能依赖本地 ~/.composer/config.json（CI 容器是干净的）。
在 pipeline.yml 中全局配置镜像源（推荐）
阿里云效的流水线使用 YAML 定义步骤，最稳妥的方式是在 composer install 前插入一条 composer config 命令，强制设置全局镜像：
steps:
- name: Install dependencies
script: |
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
composer install --no-dev --optimize-autoloader
注意三点：
-
-g表示全局配置，作用于当前构建容器的整个用户环境，避免每次都要传参数 - 必须用
https://mirrors.aliyun.com/composer/，不是https://packagist.phpcomposer.com（已停用）或https://packagist.laravel-china.org（不稳定） - 不要用
composer config --global，部分旧版 Composer 会忽略--global，只认-g
用 env 变量临时覆盖（适合多项目复用模板）
如果流水线模板被多个项目共用，不想硬编码镜像地址，可通过环境变量控制：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
environment: COMPOSER_REPO_PACKAGIST: https://mirrors.aliyun.com/composer/
这个变量会在 Composer 启动时自动生效，等价于运行了 composer config repo.packagist composer $COMPOSER_REPO_PACKAGIST。但要注意：
- 仅对 Composer 2.2+ 有效；Composer 1.x 不识别该变量
- 变量值必须以
https://开头，且末尾不能带斜杠（https://mirrors.aliyun.com/composer会失败） - 如果同时用了
composer config -g和该变量，config -g优先级更高
跳过镜像配置的常见误操作
有人试图在 composer.json 里写死镜像，比如加 "repositories" 字段——这在 CI 中无效，因为 composer install 第一步就要从 packagist 拉取 root package 的 metadata，此时还没读到你的 composer.json。
也有人用 sed 替换全局 config 文件路径，结果发现 CI 容器里 ~/.composer/config.json 根本不存在，或者权限不足写入失败。
真正起效的只有两种方式：在命令行显式调用 composer config -g，或通过 COMPOSER_REPO_PACKAGIST 环境变量注入。其他任何“提前改配置文件”的尝试，在阿里云效的无状态构建节点上都不可靠。
镜像源本身没问题，但配置时机错了，整个构建就会卡在第一步。这点和本地开发完全不同——CI 没有“你上次配好了”的概念。
