composer怎么解决15小时超时_composer增加运行限时教程

composer 卡住非因内置15小时超时，而是网络请求无限重试或进程被杀导致；需组合设置composer_process_timeout、composer_http_timeout环境变量及php.ini中default_socket_timeout，并排查镜像源、dns、oom等问题。

Composer install/update 卡住 15 小时？不是超时，是默认没设限

Composer 本身没有内置的“15 小时超时”机制——你看到的长时间卡顿，通常是网络请求（比如 git clone、curl 下载包）在后台无限重试，或 PHP 进程被系统 kill 后未报错导致的假性冻结。真正的超时控制得靠两层：PHP 配置和 Composer 自身参数。

怎么让 composer 命令真正「到点就停」

关键不是加一个“超时开关”，而是组合控制底层行为：

• COMPOSER_PROCESS_TIMEOUT 环境变量：控制单个外部进程（如 git、svn）最长运行秒数，默认 300（5 分钟）。想缩短卡死风险，设成 60 或 120 更实际
• COMPOSER_HTTP_TIMEOUT 环境变量：限制 HTTP 请求（如访问 packagist.org）的等待时间，默认 600（10 分钟）。国内网络不稳定时建议设为 30～60
• --timeout 参数只对 composer install 和 update 的整体执行有效，但**不包含子进程**（比如 git clone），所以单靠它不够
• PHP 的 max_execution_time 对 CLI 模式默认是 0（不限制），改它没用；真正要调的是 default_socket_timeout（php.ini 中），建议设为 30

常见错误现象和对应解法

遇到卡住，先别急着改 timeout，先看日志里真正在等什么：

• 卡在 Cloning xxxxx：说明 git 操作慢或失败 → 设置 COMPOSER_PROCESS_TIMEOUT=60 + 换镜像源（如阿里云：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/）
• 卡在 Loading composer repositories with package information：HTTP 请求挂起 → 设置 COMPOSER_HTTP_TIMEOUT=45 + 检查 DNS 或代理
• 命令突然退出但无错误：可能是系统 OOM killer 杀了进程 → 查 dmesg | tail，不是 timeout 问题，得加内存或减并发（--no-plugins --no-scripts 临时降低负载）
• 用了 composer update --dry-run 还卡：说明依赖解析阶段就卡住 → 尝试 composer update --lock 跳过解析，或删掉 composer.lock 再试（慎用）

为什么改了 timeout 还没用？检查这三点

很多情况下你以为改了，其实根本没生效：

• 环境变量没传给子 shell：windows 用 set COMPOSER_HTTP_TIMEOUT=30 && composer install，linux/macos 必须用 COMPOSER_HTTP_TIMEOUT=30 composer install（不能写成 export 后再跑，某些 CI 环境会丢）
• 配置写进了全局 config 但被项目级 config 覆盖：运行 composer config --list --global 和 composer config --list 对比，确认生效位置
• 用了 docker 或 CI 工具（如 github Actions）：环境变量需显式注入，GitHub Actions 中要写进 env: 块，不能只写在 run 行里

超时逻辑本身不复杂，难的是定位到底哪一层在卡——网络？DNS？Git？还是 packagist 元数据解析？盯着 log 里最后一行动词，比盲目调数字有用得多。