curl error 28是操作超时而非网络中断，需三步解决：调高http.timeout（如600秒）应对http请求总耗时，设process-timeout（如1200秒）管控git clone等子进程，并切换阿里云镜像源、清缓存、禁用ipv6及排查dns/tls干扰。
cURL error 28 是操作超时，不是网络断了，调对参数、换对镜像、避开链路干扰三步就能过。
卡在 Downloading 就该调 http.timeout
这一步是 Composer 真正发起 HTTP 请求（比如下载 packages.json 或 dist 包），http.timeout 控制的是单次请求从 DNS 解析、TLS 握手、首字节等待到 body 传输的总耗时，默认仅约 60 秒——国内访问镜像源首字节延迟高时极易触发。
- 全局设为 600 秒：
composer config -g http.timeout 600 - 项目级更稳妥（尤其 CI）：
"http.timeout": 600写进composer.json的config段 - 临时调试可用：
COMPOSER_HTTP_TIMEOUT=600 composer install - 注意：
http.connect_timeout可额外设（如 30 秒），专防 DNS 或 TCP 握手慢，但非所有版本都支持
卡在 Executing command 就该调 process-timeout
这一步常见于 git clone、unzip、运行 post-install-cmd 脚本等子进程操作。process-timeout 控制整个命令生命周期总耗时，默认 300 秒，大项目跑脚本或低带宽下很容易突破。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 推荐设为 1200（20 分钟）：
composer config -g process-timeout 1200 - CI 中建议用环境变量：
COMPOSER_PROCESS_TIMEOUT=1200，它比--timeout更能覆盖插件启动的子进程 - 禁用超时（仅限可控环境）：
composer install --process-timeout=0，但要确认不是内存不足导致的假性卡死
换镜像后还超时？检查这三处隐形失效点
镜像配置“看似成功”但根本没生效，是高频静默失败原因。
- URL 末尾必须带
/：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会拼出非法路径//packages.json） - 项目
composer.json里写了repositories字段，会直接覆盖全局镜像配置 - 系统级代理或杀软 HTTPS 扫描，会让 TLS 握手卡在
* TLSv1.3 (IN), TLS handshake那一步——curl -I测通了，Composer 却静默超时
别忽略 DNS 和 TLS 层的真实卡点
运行 composer install -vvv，盯住最后一行输出：
- 停在
Resolving dependencies→ 是 DNS 问题，跟 timeout 完全无关；用dig mirrors.aliyun.com @8.8.8.8验证解析，临时改/etc/resolv.conf或 hosts - 停在
Downloading https://api.github.com/→ GitHub token 或 rate limit 问题，不是http.timeout能解决的 - 反复出现
retrying后失败 → 上游根本没响应，得换镜像或关掉并行下载：composer config -g use-include-path false
真正卡住的地方往往不在超时数字本身，而在 DNS 解析是否被污染、镜像 URL 是否多一个字符、或者 TLS 握手是否被中间设备劫持——这些地方一错，拉再高的 timeout 也白等。
