composer 的 http 请求超时由 http.timeout 控制，专用于 packages.json 等元数据下载阶段，覆盖 dns 解析、tcp 连接、tls 握手及响应等待全过程；process-timeout 对此无效，仅影响后续 git clone 等外部进程。
直接调 http.timeout，不是 process-timeout，也不是 --timeout——后者管的是整个命令生命周期，而“请求包信息”这一步纯走 HTTP，卡住时必须用对参数。
卡在 Resolving dependencies 或 packages.json 下载时该调哪个 timeout
这是典型的 metadata 请求阶段：Composer 先 GET https://mirrors.aliyun.com/composer/packages.json，再逐个查 vendor/package 的 dist 和 source 地址。这一环只受 http.timeout 控制（v2.2+ 也支持 http-basic-timeout），和 process-timeout 完全无关。
- 停在
Resolving dependencies：大概率是 DNS 解析慢或镜像域名无法连通，先试curl -I https://mirrors.aliyun.com/composer/packages.json看是否秒回 - 停在
Downloading https://...（后面跟着 .json 或 .zip）：说明已发请求但没收到响应，http.timeout就是为此设的 -
process-timeout在这一步完全不生效——它只影响后续的git clone、unzip、post-install-cmd等外部进程
怎么设 http.timeout 才真正生效
必须确认你用的是 Composer v2.2+，且参数名拼写准确：http.timeout（不是 http-basic-timeout，也不是已废弃的 http-basic.timeout）。旧版本只认 http-basic-timeout，但 v2.2 起统一为 http.timeout。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 全局设（推荐）：
composer config -g http.timeout 600 - 项目级覆盖（CI 中更可控）：在
composer.json的config字段里加"http": {"timeout": 600} - 临时调试：
COMPOSER_HTTP_TIMEOUT=600 composer install -vvv，注意环境变量名是COMPOSER_HTTP_TIMEOUT，不是COMPOSER_TIMEOUT - 别碰
http.connect_timeout：它只控制 TCP 连接建立阶段（如 DNS + SYN），多数国内用户卡的是 TLS 握手或首字节等待，http.timeout已包含这部分
换镜像源后还超时？检查这三个隐形坑
设了 http.timeout 600 仍失败，往往不是参数问题，而是镜像配置本身被绕过或干扰：
- 项目
composer.json里写了repositories字段，会直接覆盖全局镜像配置；删掉或改成镜像兼容格式（如"url": "https://mirrors.aliyun.com/composer/"，末尾不能多/） - 系统开了 HTTPS 代理或杀软启用“HTTPS 扫描”，导致 TLS 握手卡在
* TLSv1.3 (IN), TLS handshake阶段——curl -v能通，Composer 却静默超时 - 用了私有 Git 包（
"type": "git"），Composer 会跳过 HTTP 流程直接git clone，此时http.timeout完全无效；查具体包拉取方式：composer show vendor/package --all | grep -A5 dist
最常被忽略的一点：http.timeout 只管 Composer 自己发的 HTTP 请求，不管 git、svn、hg 这些子进程——一旦看到 Cloning into，就得去调 Git 的 core.sshCommand 或 http.postBuffer，跟 Composer 配置无关。
