应先查GitLab Runner和Docker的外层超时限制，再设COMPOSER_PROCESS_TIMEOUT；多数“配了仍超时”因未触达Composer逻辑，常见漏点包括runner_timeout、docker stop-timeout、PHP max_execution_time被禁用、内存不足OOM或扩展缺失。
GitLab CI 里 Composer 超时，90% 不是 Composer 自己的问题，而是被外层限制截断了——先查 runner 级超时和容器 stop-timeout，再动 COMPOSER_PROCESS_TIMEOUT。
为什么设了 process-timeout 还超时？
多数“明明配了还挂”是因为根本没走到 Composer 的超时逻辑。常见漏点：
- GitLab Runner 配置了
timeout: 1200（单位秒），比COMPOSER_PROCESS_TIMEOUT更早杀掉 job - Docker 执行器下，
docker run --stop-timeout设得太小（比如默认 10 秒），容器还没响应 SIGTERM 就被强制 kill - PHP 的
max_execution_time被disable_functions禁用了，set_time_limit()直接报错，Composer 无法动态延长 - 内存不足（尤其
composer update解析锁文件时），OOM killer 先干掉进程，日志里只显示 “Killed” —— 不是超时，是爆内存
COMPOSER_PROCESS_TIMEOUT 和 process-timeout 怎么配才生效？
两者不是互斥，而是分层作用：环境变量控制整个命令生命周期，全局 config 控制子进程（如 git clone）。必须同时设，且值要合理：
- 在
.gitlab-ci.yml里显式声明：variables: { COMPOSER_PROCESS_TIMEOUT: "1800" }（单位秒，推荐 1800=30 分钟） - 同步运行
composer config -g process-timeout 1200，专治卡在Executing command或Cloning into - 别设为 0：某些网络异常下会无限重试，job 彻底卡死，连
Ctrl+C都无效 - CI 容器重启后配置丢失，所以不能只靠
composer config -g，必须每次 job 都通过variables或before_script显式注入
HTTPS 下载卡在 TLS 握手怎么办？
http.timeout 对 HTTPS 卡顿基本无效，它不覆盖 TLS 握手阶段。真正该调的是：
-
composer config -g http-basic-timeout 300：管每个 HTTPS 请求的连接 + 读取总时长（含 TLS 握手），推荐 300 秒 -
composer config -g process-timeout 1200：管整个流程，和上面叠加生效 - 验证是否卡在证书层：
curl -v https://mirrors.aliyun.com/composer/packages.json，看是否停在* Initializing SSL connection - 若确认是 CA 问题，可临时指定证书路径：
export CURL_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
代理配置常被忽略的关键细节
国内 CI 环境用代理很常见，但只配 http-proxy 一定失败：
- Composer 所有仓库请求（Packagist、GitHub、GitLab）全走 HTTPS，必须同时配
https-proxy -
https-proxy的值协议头必须是http://，哪怕代理服务监听的是 HTTPS 端口，写成https://或不带协议都会静默失效 - 验证方式：
composer config -g --list | grep -E "(http|https)-proxy"，两行都得有且格式正确 - NTLM 代理（如公司域环境）原生不支持，得用
cntlm或px做中转，再把 Composer 的两个 proxy 都指向中转地址
最常被跳过的一步：确认 PHP 扩展是否装全。CI 镜像里缺 ext-zip 或 ext-openssl，composer install 会直接退出，看起来像超时，实际连第一步都没跑完。
