卡在downloading https://时应调http.timeout，它控制dns解析、tls握手、首字节等待及整个body传输总时间，默认300秒易超时，需同步确保php default_socket_timeout不小于该值。
Composer 没有全局“timeout”配置项，写 config.timeout 无效 —— 这是旧文档残留的误导字段，新版 Composer 完全不识别。
卡在 Downloading https:// 时该调哪个参数
这是 HTTP 请求生命周期超时，错误里常带 cURL error 28 或反复 retry 后失败。它只响应 http.timeout，和 process-timeout 无关。
-
http.timeout控制 DNS 解析 + TLS 握手 + 首字节等待 + 整个 ZIP 包 body 传输的总时间，默认仅 300 秒（5 分钟），弱网下极易中断 - 必须同步检查 PHP CLI 的
default_socket_timeout：运行php -i | grep default_socket_timeout，若结果是 60，哪怕你设了http.timeout=1200，底层 socket 也会在 60 秒后直接掐断连接 - 项目级生效：运行
composer config http.timeout 600，写入当前composer.json的config段，可提交、可复现 - 全局生效：运行
composer config -g http.timeout 1200，写入~/.composer/config.json - 临时覆盖（CI 最常用）：设置环境变量
COMPOSER_HTTP_TIMEOUT=1200 composer install，优先级最高
报 “The process timed out” 错误该改哪一项
错误信息里一定含 [RuntimeException] The process "" exceeded the timeout，并伴随 -vvv 输出中最后执行的命令（如 unzip、git clone、php artisan optimize）。这是子进程执行超限，和 HTTP 下载完全无关。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
process-timeout控制单个外部命令最大执行时间，默认 300 秒；它不区分是解压、克隆还是自定义脚本，一律计时 - 项目级修改：在
composer.json顶层加"config": {"process-timeout": 1200} - 全局修改：运行
composer config -g process-timeout 1800 - 临时覆盖：用
--timeout=1200（注意等号不能少），或环境变量COMPOSER_PROCESS_TIMEOUT=2000 - 设为 0 表示禁用超时，但不推荐长期使用——一旦网络卡死或镜像不可用，命令会无限挂起
为什么调了 timeout 还失败？三个隐藏断点
很多“超时”根本不是时间问题，而是其他环节提前中断：
- DNS 卡在
Resolving dependencies：这步只做域名解析，http.timeout完全不生效；运行dig mirrors.aliyun.com验证是否能拿到 IP，否则换 DNS 或改/etc/hosts - 内存不足导致 OOM：尤其
composer update解析锁文件阶段，表现和超时一模一样；检查php -r "echo ini_get('memory_limit');"，建议 ≥ 1.5G - 私有 Git 包反复计入
process-timeout：每次git clone、git checkout都独立计时，且全部累加进总耗时；换成 HTTPS 地址或预配置GIT_SSH_COMMAND可缓解
真正要解除等待上限，得先确认卡在哪一层 —— HTTP 层、子进程层、DNS 层、还是内存层。盲目调高 process-timeout 或 http.timeout 只会让失败来得更慢，而不是更少。
