composer卡住需区分两类超时：http-timeout控制http请求（如downloading https://），默认300秒，应设为600；process-timeout控制子进程（如git clone），默认300秒，推荐设为1800，且全局生效须用环境变量composer_process_timeout。
Composer 卡住，不能只调一个 timeout —— 它分两类：网络下载（http-timeout）和本地命令执行（process-timeout），设错地方完全无效。
卡在 Downloading https:// 或 curl error 28？该调 http-timeout
这是 PHP cURL 层的网络请求超时，和 git、解压、脚本完全无关。错误典型如 Could not fetch https://repo.packagist.org/packages.json、反复重试后失败、或卡在 Downloading https://mirrors.aliyun.com/...。
-
http-timeout控制 Composer 发起的所有 HTTP 请求（拉取元数据、下载 ZIP 包）最大等待秒数，默认 300 秒 - 项目级生效：
composer config http-timeout 600，写入当前composer.json的"config"段 - 全局生效：
composer config --global http-timeout 600，影响所有项目 - 临时覆盖优先级最高：
COMPOSER_HTTP_TIMEOUT=600 composer install - 注意：
http-basic、github-oauth配置项不干预超时；若用了私有源，还得检查 Nginx 的proxy_read_timeout和 PHP 的default_socket_timeout（运行php -i | grep default_socket_timeout查看 CLI 模式值）
卡在 Installing dependencies 或报 The process timed out？该调 process-timeout
这是子进程（比如 git clone、unzip、php artisan optimize）跑太久被杀，错误里常带 [RuntimeException] The process timed out. 或 Symfony\Component\Process\Exception\ProcessTimedOutException。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
process-timeout默认 300 秒，只管子进程执行时长，不影响任何网络行为 - 项目级推荐（最安全）：
composer config process-timeout 1800，写入当前composer.json - 全局配置已废弃：
composer config --global process-timeout在新版中无效，别信老教程 - 真正有效的全局方式是环境变量：
export COMPOSER_PROCESS_TIMEOUT=1800（Linux/macOS），Windows 下设系统变量 - 临时调试：
composer install --process-timeout=1800或COMPOSER_PROCESS_TIMEOUT=1800 composer update - 设为
0表示禁用检查，但不推荐——真遇到 Git 不可达或脚本死循环，会无限卡住
怎么确认到底卡在哪一类？用 -v + 环境变量组合验证
加 -v 能暴露最后执行的命令，是定位的关键：
- 运行
composer install -v，看最后输出的Running command (CWD): ...是不是长时间没反应 - 如果最后卡在
git clone或php ./vendor/bin/phpunit，说明是process-timeout问题 - 如果最后卡在
Downloading https://...，说明是http-timeout问题 - 快速排除脚本干扰：
composer install --no-scripts，如果不再卡，说明问题出在post-install-cmd等脚本里 - 验证配置是否生效：
composer diagnose -v | grep timeout，它会打印当前实际读取的http-timeout和process-timeout值
镜像源没换，光调 timeout 是硬扛，不是解决
国内用户最常忽略的一点：超时只是表象，根源往往是源慢或不可达。
- 先换镜像源比调 timeout 更治本：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 某些企业内网 Git 服务（如 Gitee 私有版）本身有连接限制，Composer 改了
http-timeout也没用，得同步调 Git：git config --global http.postBuffer 524288000 - 拉高 timeout 只是“等它慢慢死”——如果某个
post-install-cmd脚本稳定要 12 分钟，大概率该优化逻辑或拆分任务，而不是设成 3600 - 某些老旧插件（如
hirak/prestissimo）在高并发下载时可能触发子进程调度异常，导致误判超时
