卡在downloading https://时起作用的是http-basic-timeout（composer 2.2+）或旧版http.timeout，它控制dns解析、tls握手、首字节等待及整个body传输，默认60秒太短，建议设300～600秒。
composer install/update 卡在 Downloading https:// 是哪个 timeout 在起作用
看 -vvv 输出最后一行，如果停在 Downloading https://...，说明是单次 HTTP 请求卡住，不是整体流程慢。这时候起作用的是 http-basic-timeout（Composer 2.2+）或旧版的 http.timeout，它控制 DNS 解析、TLS 握手、首字节等待、整个 body 传输——不是“下载慢”，而是连接阶段就僵死。默认 60 秒对国内网络太短，建议设为 300～600。
process-timeout 和 http-basic-timeout 必须一起调
这两个参数互不覆盖，只改一个大概率仍失败：
-
process-timeout管总耗时：含依赖解析、解压、运行post-install-cmd、生成 autoload 等全部步骤，默认300秒 -
http-basic-timeout管每个 HTTP 请求：比如拉一个 ZIP 包，哪怕只差 1 字节没传完，也会在这里触发超时
临时生效：composer install --timeout=1200 --http-basic-timeout=300
永久生效：composer config -g process-timeout 1800 + composer config -g http-basic-timeout 300
换阿里云镜像源比加 timeout 更治本
80% 的“超时”本质是源不稳定，不是网速慢。阿里云镜像能绕过 DNS 污染、TLS 握手抖动和国外源响应延迟：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 配置命令：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 配完必须清缓存：
composer clear-cache，否则仍可能读取损坏的本地缓存 - 验证是否生效：
composer config -g repo.packagist应输出对应 URL，且composer install --dry-run中下载链接要变成mirrors.aliyun.com
注意："type": "git" 的包会绕过镜像直连 GitHub，此时必须配合 process-timeout 和 Git 自身超时设置。
中断后 vendor/ 里残留的破损文件最麻烦
Composer 没有断点续传，中断后残留的破损 ZIP、截断的 installed.json 或卡死的临时目录会持续干扰后续执行：
- 不要直接删整个
vendor/——这会导致autoload.php缺失，引发后续命令报错 - 精准清理：
rm vendor/autoload.php+rm -rf vendor/composer/ - 再运行：
composer dump-autoload→composer install - 若仍报
Failed to extract或Content-Length mismatch，说明缓存已坏，必须composer clear-cache
真正麻烦的从来不是“等多久”，而是中断后 vendor/ 里那些看似完整、实则校验失败的包文件——它们不会自己消失，也不会被自动跳过。
