单纯调高 timeout 不能解决镜像源加速问题，但不配置 timeout，再快的镜像也可能卡住；需同时设置 process-timeout（控制全生命周期）和 http.timeout（控制单次 HTTP 请求），推荐全局设为 600 秒和 300 秒，CI 中可用 COMPOSER_PROCESS_TIMEOUT=0 不限时，并确认镜像 URL 正确且已清缓存。
单纯调高 timeout 不能解决镜像源加速问题，但不配 timeout，再快的镜像也可能卡住——尤其在 CI 环境或低带宽机器上。
为什么镜像源配好了还超时？
镜像站本身响应快，但 Composer 在下载前要先拉取几十 MB 的 packages.json 元数据、校验 hash、解压 tarball、生成 autoload —— 这些环节都受 process-timeout 和 http.timeout 控制。默认值（300 秒）在 Docker 容器、CI 节点或老旧 VPS 上极易触发 Connection timed out 或 Operation timed out。
常见错误现象：
-
composer install卡在Loading composer repositories或Downloading https://mirrors.aliyun.com/composer/... -
php -d memory_limit=-1 /usr/bin/composer update仍报file_get_contents(): failed to open stream: Connection timed out - 本地能跑通，CI 流水线里反复失败
必须设置的两个 timeout 参数
process-timeout 控制整个命令生命周期（含依赖解析、下载、解压、autoload 生成），http.timeout 仅管单次 HTTP 请求。两者都要设，且推荐值不同：
- 全局设
process-timeout：运行composer config -g process-timeout 600（单位秒，600=10 分钟） - 全局设
http.timeout：运行composer config -g http.timeout 300（单次请求最长 5 分钟，避免小包重试卡死） - 若用 CI（如 GitHub Actions/GitLab CI），建议改用环境变量更可靠：
COMPOSER_PROCESS_TIMEOUT=0（0 表示不限时） - 注意：
http.timeout在 Composer 2.5+ 中才被完整支持；1.x 用户需 ≥ 1.10.22 才生效
timeout 和镜像源的配合要点
换源和调 timeout 是“一前一后”的关系：先确保镜像 URL 正确（composer config -g repo.packagist 输出含 "url": "https://mirrors.aliyun.com/composer/" 且末尾有斜杠），再调 timeout。否则 timeout 再大也白搭——它只是让失败来得更慢。
- 别在没清缓存的情况下调 timeout：先执行
composer clear-cache，否则旧元数据还在，镜像根本没走 - 项目级配置下，
process-timeout仍走全局，但http.timeout可被项目composer.json的config.http-basic或自定义 repository 覆盖 - 某些私有包（如
git@或https://github.com/org/private）不走镜像，但依然受http.timeout限制——如果它们响应慢，一样会超时
临时覆盖 timeout 的实用命令
不想改全局配置？用 --timeout 参数临时生效（注意是双短横）：
-
composer install --timeout=1200（覆盖process-timeout） -
composer update --http-timeout=600（Composer 2.5+ 支持，覆盖http.timeout） - CI 脚本中推荐组合写法：
COMPOSER_PROCESS_TIMEOUT=0 composer install --no-interaction --prefer-dist --optimize-autoloader
最易被忽略的是：timeout 设置后不验证是否真正加载。运行 composer config -g process-timeout 和 composer config -g http.timeout 看输出值，别只信自己敲过命令。
