应设process-timeout和http-basic-timeout：前者控制git clone、unzip等子进程超时（推荐1200秒），后者专管单次HTTPS请求（如下载ZIP包头，推荐300秒），两者必须同时配置，缺一则卡在对应阶段。
CI/CD里composer install总被kill，该设哪个timeout
不是timeout，也不是http-timeout——这两个字段在composer.json里写进去会被静默忽略。真正起效的是process-timeout（控制git clone、unzip等子进程）和http-basic-timeout（控制单次HTTPS请求，如拉ZIP包头），两者必须同时调高。
常见错误是只改process-timeout，结果卡在Downloading https://...阶段，因为http-basic-timeout默认才60秒（Composer 2.1及更早）或300秒（2.2+），远低于大包下载所需时间。
-
process-timeout设为1200（20分钟），覆盖解压、脚本执行等耗时环节 -
http-basic-timeout设为300（5分钟），专治下载卡住；旧版本不支持此字段，只能靠换镜像+--timeout硬扛 - 值必须是整数，不能加引号：
"process-timeout": 1200✅，"process-timeout": "1200"❌
全局配置 vs 命令行参数 vs 环境变量，优先级怎么排
环境变量最高，命令行次之，配置文件最低。但在CI/CD中，环境变量最可靠——它不依赖composer.json是否存在，也不怕缓存污染。
例如：COMPOSER_PROCESS_TIMEOUT=1800会让所有composer install无视composer.json里的process-timeout，但COMPOSER_HTTP_BASIC_TIMEOUT=300只在Composer 2.2+生效。
- 推荐GitLab CI/CD中用
variables:块写死：COMPOSER_PROCESS_TIMEOUT: "1800"、COMPOSER_HTTP_BASIC_TIMEOUT: "300" - GitHub Actions中用
env:设置，注意字符串引号要保留，YAML解析器对数字敏感 - 避免用
composer config -g写全局配置——容器每次重建都会丢失，除非你显式挂载~/.composer
为什么设了超时还是被系统kill
CI平台（如GitLab Runner、GitHub Actions）自身有硬性超时限制，比如GitLab默认作业超时3600秒。如果Composer还没触发自己的process-timeout，就被Runner强制终止，日志里只会显示ERROR: Job failed: execution took longer than 1h0m0s seconds，和Composer无关。
- 检查CI平台的
timeout设置，确保它大于你设的COMPOSER_PROCESS_TIMEOUT - Docker容器内运行时，还要确认
docker run --stop-timeout没比Composer超时还短 - PHP底层限制也得同步调：
php -d max_execution_time=0防止自定义脚本（如post-install-cmd）被PHP掐断 -
default_socket_timeout必须≥http-basic-timeout，否则cURL底层socket会在60秒就断连（查法：php -i | grep default_socket_timeout）
换镜像比调超时更有效，但容易漏掉这三点
国内用户90%的“超时”本质是源慢，不是真超时。换阿里云镜像后，process-timeout常可降回300秒，但以下三点常被忽略：
- 私有仓库（
git@xxx或https://github.com/org/private）不会走镜像，仍由process-timeout控制，需单独优化SSH连接或token权限 - 项目
composer.json里若硬编码了repositories，会覆盖全局镜像配置，必须清理或改用repo.packagist.org结构 - CI缓存
~/.composer/cache时，key若没包含PHP版本或Composer版本，可能跨环境复用损坏缓存，导致后续安装反复失败
超时配置不是堆数字，而是分层拦截：网络层（镜像+CA证书）、HTTP层（http-basic-timeout）、进程层（process-timeout）、PHP层（max_execution_time）、平台层（CI作业超时）。漏掉任何一层，都可能让前面所有设置失效。
