卡在“Downloading”时应调http.timeout、换镜像并清缓存：http.timeout控制DNS解析至传输完成总时长，默认300秒，弱网建议设为600；必须执行composer clear-cache，且镜像URL须以/结尾，如https://mirrors.aliyun.com/composer/。
国内直连 packagist.org 基本不可用，这不是你本地网络坏了，而是链路被干扰或超时阈值太低——换镜像 + 调超时 + 清缓存，三步到位。
卡在 “Downloading https://…” 时该调 http.timeout
这是 HTTP 请求阶段卡住，比如拉 packages.json、下载 ZIP 包，错误里常带 cURL error 28 或反复 retry 后失败。它不看 process-timeout，只认 http.timeout（Composer 2.x）。
-
http.timeout控制 DNS 解析 + TLS 握手 + 首字节等待 + 整个 body 传输的总时间，单位秒，默认仅 300（5 分钟），弱网下极易触发 - 项目级最稳：运行
composer config http.timeout 600，写入当前composer.json的config段，可提交、可复现 - 全局生效：用
composer config -g http.timeout 600，写入~/.composer/config.json - 临时覆盖优先级最高：
COMPOSER_HTTP_TIMEOUT=1200 composer install，适合 CI 调试 - 注意：
php -i | grep default_socket_timeout查出的 PHP CLIdefault_socket_timeout若低于你设的http.timeout，会提前掐断连接——常见值是 60，务必同步调高
“file could not be downloaded” 或 “Content-Length mismatch” 优先换镜像 + 清缓存
这类错误 90% 是因默认源直连失败，不是权限或配置问题。镜像源走 CDN 直连，无隧道依赖，成功率远高于代理。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 立刻切阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意 URL 必须以/结尾） - 切完必须清缓存：
composer clear-cache，否则旧失败记录还在，重试照样失败 - 如果还报
Content-Length mismatch，说明缓存里已有损坏 ZIP 文件，清缓存比重试更管用 - 确认
~/.composer/cache/files/目录为空后再重试，安全，不影响vendor/或composer.lock
GitHub API 调用失败（如卡在 api.github.com/.../zipball）要配 Token
Composer 安装含 GitHub 包时，会高频调用 GitHub API，未认证请求有速率限制，容易卡住或 403。
- 在
~/.composer/auth.json中添加：{"github-oauth": {"github.com": "your_token_here"}} - Token 可在 GitHub Settings → Developer settings → Personal access tokens 创建，勾选
repo权限即可 - 避免用
--prefer-source：它强制走 Git 克隆，比--prefer-dist（下 ZIP）更容易因 SSH/Git 超时卡死 - CI 环境建议加
--no-scripts --no-plugins缩短等待时间，排除钩子脚本干扰
真正难搞的不是“连不上”，而是缓存已坏却还在复用、PHP 超时和 Composer 超时不一致、或者 GitHub Token 没生效但错误日志不提示——这些点不手动查，光重试十次也没用。
