本质是composer调用git clone时被kill，超时由process-timeout控制（默认300秒），需调高该值并检查git协议、github token、php及系统限制。
拉取远程分支超时，本质是 Composer 在执行 git clone 或 git fetch 时被 kill，和 HTTP 下载无关——http.timeout 完全无效，必须调 process-timeout，并检查 Git 行为本身是否受阻。
卡在 Cloning into 'xxx' 或 Executing command: git clone？这是 process-timeout 生效点
Composer 解析到 "type": "vcs" 或依赖中含 dev- 分支（如 "monolog/monolog": "dev-main"）时，会调用 Git 命令拉源码。此时超时由 process-timeout 控制，不是网络层。
-
process-timeout默认仅 300 秒，而大仓库（如 Laravel、Symfony）克隆 + 检出可能耗时 5–10 分钟，尤其在 CI 或低带宽环境 - 错误日志明确含
The process "git clone --no-checkout ..."或exceeded the timeout，就是它 - 全局改：运行
composer config -g process-timeout 1800（30 分钟） - 项目级更稳妥：在
composer.json顶层加"config": {"process-timeout": 1200} - CI 中建议用环境变量兜底：
COMPOSER_PROCESS_TIMEOUT=2000，某些旧版 Composer 对它响应更直接
Git 克隆慢或卡死，不一定是超时，可能是协议或认证问题
即使延长了 process-timeout，仍卡住，大概率是 Git 层阻塞：SSH 连接 hang、HTTPS 认证失败、或 GitHub API 限流触发降级重试。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 确认是否用了 SSH 地址（如
git@github.com:user/repo.git）：公司网络常屏蔽 SSH 端口（22），换成 HTTPS 地址可绕过 - GitHub 限流会导致
git clone https://...静默卡顿：API 调用失败后 Composer 会退化为反复尝试，实际是403 rate limit exceeded，不是网速问题 - 解决办法：配 GitHub Token，运行
composer config -g github-oauth.github.com <your_token></your_token>，权限只需repo - 验证：运行
curl -H "Authorization: token <your_token>" https://api.github.com/rate_limit | grep limit</your_token>，返回5000才生效 - 避免
--prefer-source：它强制走 Git，对连接稳定性要求更高；CI 中优先用--prefer-dist
PHP 或系统限制也会掐断 Git 进程
Composer 启动的 Git 子进程，最终跑在 PHP CLI 下，受 PHP 和系统两级限制。
-
php -i | grep max_execution_time若输出max_execution_time => 30，PHP 自身会中断脚本，需设为0或足够大 -
ulimit -t查看 CPU 时间限制，某些容器或 CI 环境默认设为 300 秒，会直接 kill 子进程 - WSL2 或 Docker for Mac 下，NTFS 挂载卷上
git clone极慢：换用 Linux 原生路径（如/home/xxx）或禁用 Windows symlink 支持 - 检查
git config --global http.postBuffer，若太小（如默认 1M），克隆大仓库会失败，可设为524288000（500MB）
真正卡在 Git 分支拉取时，别碰 http.timeout，它完全不参与；重点盯 process-timeout、GitHub Token、Git 协议选择和底层执行环境限制——四者漏一，调再久都白等。
