Composer timeout设置最佳实践有哪些-composer-PHP中文网

卡在downloading https://时应调http.timeout，它控制dns解析、tls握手、首字节等待及整个zip包传输总耗时，默认300秒易超时，需同步调高php的default_socket_timeout；the process timed out错误则须调process-timeout，它管控git clone、unzip等子进程，默认300秒，与http无关。

composer timeout设置最佳实践有哪些

Composer timeout 设置不是“调高就完事”，关键在分清 http.timeout 和 process-timeout 各管哪一段，且必须同步调整 PHP 底层限制，否则白配。

卡在 Downloading https:// 时该改 `http.timeout`

这是 DNS 解析、TLS 握手、首字节等待、整个 ZIP 包传输的总耗时，错误里常带 cURL error 28 或反复 retry。它完全不看 process-timeout。

http.timeout 默认仅 300 秒（5 分钟），弱网或大包下极易触发
项目级最稳：运行 composer config http.timeout 600，写入当前 composer.json 的 config 段，可提交、可复现
全局生效：用 composer config -g http.timeout 600，写入 ~/.composer/config.json
临时覆盖优先级最高：设环境变量 COMPOSER_HTTP_TIMEOUT=1200，再跑 composer install，适合 CI 调试
⚠️ 注意：php -i | grep default_socket_timeout 查出的 CLI 值若低于你设的 http.timeout（常见是 60），连接会被 PHP 提前掐断——必须同步调高 default_socket_timeout

报 `The process timed out` 错误该调 `process-timeout`

这是子进程执行超时，比如 git clone、unzip、post-install-cmd 脚本卡住，错误里一定含 [RuntimeException] The process "" exceeded the timeout，加 -vvv 可看到最后那条命令。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

process-timeout 控制单个外部命令最大执行时间，默认 300 秒，和 HTTP 完全无关
全局改：运行 composer config -g process-timeout 1800（30 分钟），写入 ~/.composer/config.json
项目级改：直接在 composer.json 顶层加 "config": {"process-timeout": 1200}
临时覆盖：用 COMPOSER_PROCESS_TIMEOUT=1800 composer install，或命令行参数 --timeout=1800（注意必须带等号）
设为 0 表示禁用超时，但可能卡死无响应；调试建议先设 600，确认能走通再调高

换源只是辅助，`http.timeout` 和 `process-timeout` 必须配对使用

国内用户常因 DNS 解析慢或镜像响应不稳定触发超时，但错误提示只显示 Failed to download，掩盖了真实瓶颈。阿里云镜像是目前最稳定可用的国内源：

设镜像：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（末尾斜杠不能少）
禁用 fallback：composer config -g repo.packagist false，防止 Composer 自动回退到官方源拖慢流程
验证是否生效：跑 composer clear-cache && composer require monolog/monolog -vvv，在日志里搜 Downloading，确认 URL 是阿里云地址；composer diagnose 里的 Repo packagist.org: 行也更可靠
注意：镜像只加速 packagist.org 公共包，对 git@、https://github.com/xxx 类 VCS 源无效，这类仍走 process-timeout

真正卡住时，别只盯着 timeout

很多“超时”本质不是时间问题，而是资源或配置阻塞：

内存不足时，composer update 在解析锁文件阶段会 OOM，表现和超时几乎一样；检查 memory_limit 是否 ≥ 1.5G
用了 "type": "vcs" 的包，每次 git clone 都计入 process-timeout 总时长，不是单次；可先手动 git clone 测试是否卡在 SSH 或代理
CI 环境中，COMPOSER_PROCESS_TIMEOUT 必须显式设置，否则容器重启后配置丢失；Docker 中还要确认未被 docker run --stop-timeout 或外层 timeout 命令包裹
set_time_limit() 对 composer install 主进程无效——它只作用于当前 PHP 进程，而 Composer 是靠 proc_open() 启动子进程干活的