Composer默认process-timeout为300秒（5分钟），非300分钟；设为0会致无限等待、CI卡死，应按卡点分别调http-basic-timeout（下载阶段）和process-timeout（解压/脚本阶段），并同步调高PHP default_socket_timeout。
Composer 没有“三百分钟”默认超时限制——它的默认 process-timeout 是 300 秒（5 分钟），不是 300 分钟。你看到的“三百分钟”很可能是误读或配置残留，直接调成 0 并不安全。
为什么设成 0 会出问题
把 process-timeout 或 http-basic-timeout 设为 0 表示禁用超时，但 Composer 在 TLS 握手失败、代理无响应、镜像返回空包等场景下可能无限等待，连 Ctrl+C 都无法中断，尤其在 CI 环境里会导致任务卡死、资源占满。
- 某些企业防火墙会静默丢弃 HTTPS CONNECT 请求，此时
https-proxy配了也卡住，timeout=0 就真挂了 -
http-basic-timeout为 0 时，哪怕 DNS 解析失败也会一直重试，不报错也不退出 - PHP 的
default_socket_timeout若仍为 60（常见 CLI 默认值），它会在 Composer 层超时前先掐断连接，造成行为不可预测
真正该调哪些 timeout 参数
Composer 的超时是分层的，必须按实际卡点位置调整对应参数，不能只盯着一个“总开关”：
- 卡在
Loading composer repositories或Downloading https://...：调http-basic-timeout（推荐 300） - 卡在
Extracting archive、Running post-install-cmd或报The process "" exceeded the timeout：调process-timeout（推荐 1200） - 卡在
Cloning into 'xxx'或git clone命令里：process-timeout也管这个，但 git 自身还有core.sshCommand和网络层超时，需另查
怎么安全地延长超时（不是解除）
用明确的、可退的数值代替 0，同时确保底层支撑项同步生效：
- 全局设为 20 分钟：
composer config -g process-timeout 1200和composer config -g http-basic-timeout 300 - 验证 PHP socket 限制是否够用：
php -i | grep default_socket_timeout，若输出60，运行php -d default_socket_timeout=300 -r "echo 'ok';"测试，再考虑改系统 php.ini - 临时调试可用环境变量，优先级最高：
COMPOSER_PROCESS_TIMEOUT=1200 COMPOSER_HTTP_BASIC_TIMEOUT=300 composer install - 别只改 timeout——90% 的“假超时”其实源于没换国内镜像，先跑
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
超时参数不是越长越好，关键是要和你的网络实际延迟、镜像响应速度、项目规模匹配。设太高掩盖问题，设太低频繁失败；最常被忽略的是 http-basic-timeout 和 process-timeout 必须同时调，且两者单位都是秒，不是分钟。
