Composer卡住需分别设置process-timeout和COMPOSER_HTTP_TIMEOUT：项目级运行composer config process-timeout 1800，全局用composer config -g process-timeout 1800；HTTP超时则通过环境变量COMPOSER_HTTP_TIMEOUT=600或php -d default_socket_timeout=600调用。
Composer install/update 命令卡住，怎么调大超时？
默认 300 秒（5 分钟）超时经常不够用，尤其在国内拉包或遇到慢源时，composer install 或 composer update 直接中断并报错：Failed to decode response: file_get_contents(): SSL: Connection timed out 或类似 cURL error 28: Operation timed out。这不是网络故障，是 Composer 主动放弃等待。
全局设置 timeout：修改 config.json 的 process-timeout
这个值控制所有耗时子进程（如 git clone、unzip、curl 下载）的单次执行上限，不是 HTTP 超时，但覆盖了绝大多数卡死场景。直接改项目级或全局配置最稳妥：
- 项目内改：
composer config process-timeout 1800（单位秒，这里设为 30 分钟） - 全局改（影响所有项目）：
composer config -g process-timeout 1800 - 手动编辑
composer.json里的"config"段，加一行："process-timeout": 1800
注意：process-timeout 不作用于 HTTP 请求本身（比如 packagist.org 的 API 响应），它管的是 Composer 启动的外部命令；设太高可能掩盖真实网络问题，不建议无脑设成 0（禁用超时）。
HTTP 层 timeout：通过 http-proxy 或环境变量干预
如果卡在 Downloading https://repo.packagist.org/packages.json 这类 HTTP 步骤，process-timeout 不生效。此时需靠 PHP 的 stream_context 或 cURL 设置：
- 临时生效（推荐调试用）：
COMPOSER_PROCESS_TIMEOUT=1800 COMPOSER_HTTP_TIMEOUT=600 composer install——COMPOSER_HTTP_TIMEOUT是 Composer 1.10+ 引入的专用变量，专管 HTTP 请求超时（单位秒） - PHP 配置层面：确保 php.ini 中
default_socket_timeout = 600，否则 Composer 底层file_get_contents()可能提前失败 - 不推荐用
http-proxy绕过 timeout：代理本身不改变超时逻辑，还可能引入额外延迟
脚本中安全调用：别只靠环境变量硬编码
写部署脚本（如 shell / CI YAML）时，直接拼 COMPOSER_HTTP_TIMEOUT=600 composer update 看似简单，但容易被子 shell 或权限隔离吃掉环境变量。更可靠的做法：
- 用
php -d default_socket_timeout=600 $(which composer) update—— 强制 PHP 层参数透传 - CI 中（如 GitHub Actions）显式设 env：
env: COMPOSER_HTTP_TIMEOUT: 600 COMPOSER_PROCESS_TIMEOUT: 1800
- 避免在
composer.json里写死http-basic凭据后又忽略 timeout：凭据正确 ≠ 网络不丢包，两者要分开处理
真正难搞的是混合场景：比如 git clone 卡住（归 process-timeout 管），紧接着 composer install 又去 fetch zip 包（归 COMPOSER_HTTP_TIMEOUT 管）。两个 timeout 得同时设，缺一不可。
