Composer install/update 卡住或报 timeout 错误主因是默认 300 秒超时不足，应优先切换国内镜像源（如阿里云、腾讯云），其次可调 process-timeout（如 1800 秒）并配合 --no-interaction 用于 CI 环境。
composer install/update 时卡住或报 timeout 错误
默认情况下，composer 的网络请求超时是 300 秒（5 分钟），但实际遇到慢源（比如国内直连 packagist.org）、代理不稳定或大包下载时，经常在 Downloading... 阶段卡死，最终抛出类似 Connection timed out 或 cURL error 28: Operation timed out 的错误。
这不是网络不通，而是默认等待时间不够 —— 尤其在 CI/CD 环境或低带宽机器上更明显。
-
composer config --global process-timeout 1800：把全局超时设为 1800 秒（30 分钟） -
composer config --global use-include-path false：避免 include-path 干扰（非必须，但常和 timeout 问题共存） - 如果只临时调整，加
--timeout=3600参数即可：composer update --timeout=3600
process-timeout 和 http-basic timeout 不是一回事
process-timeout 控制的是整个命令（如 install 或 update）的最长运行时间，包括依赖解析、脚本执行、下载解压等所有环节；而真正影响 HTTP 下载阶段的是 cURL 层的 timeout，它由 Composer 底层调用决定，不能直接通过 config 设置。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
process-timeout是唯一可配置的“总时限”，单位是秒，设为0表示不限制（不推荐） - HTTP 层 timeout 实际由 cURL 的
CURLOPT_TIMEOUT和CURLOPT_CONNECTTIMEOUT控制，Composer 没开放用户配置入口 - 若需更细粒度控制（比如只延长连接超时），只能改源码或换镜像源（见下一条）
用国内镜像源比调 timeout 更有效
单纯拉长 process-timeout 只是“拖时间”，并不能解决根本问题。很多 timeout 实际源于 DNS 解析慢、TLS 握手失败或路由绕行 —— 这些在用 https://packagist.phpcomposer.com 或 https://mirrors.aliyun.com/composer/ 后会大幅缓解。
- 设置阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 设置腾讯云镜像：
composer config -g repo.packagist composer https://mirrors.cloud.tencent.com/composer/ - 确认生效：
composer config -g repo.packagist，输出应为对应镜像 URL - 镜像源本身已优化 TLS 和 CDN，实测平均下载速度提升 3–5 倍，timeout 几乎不再出现
CI 环境中 timeout 要配合 --no-interaction 使用
在 GitHub Actions、GitLab CI 等无交互环境里，composer 遇到问题可能挂起等待输入（比如证书确认、auth token 提示），看起来像 timeout，其实是卡在 stdin。
- 务必加上
--no-interaction（简写-n）：composer install -n --timeout=1800 - 同时确保
COMPOSER_AUTH环境变量已正确注入（尤其私有包），否则会卡在 auth 步骤 - CI 日志里若看到
Authentication required (repo.packagist.org)却没报错，大概率是缺--no-interaction
