Composer请求超时主因是默认timeout和process-timeout过短，或DNS/代理/TLS问题；应优先用-vvv排查真实错误码，再针对性调整http.timeout、process-timeout或镜像源。
Composer 请求超时，通常不是网络“完全不通”，而是默认的 timeout 和 process-timeout 太保守，尤其在源站响应慢、镜像同步延迟或本地 DNS/代理不稳定时直接中断。改两个配置就能解决，但得知道改哪、为什么改、以及改完还失败该怎么继续排查。
为什么 composer install 卡在 “Loading composer repositories” 就不动？
这是最典型的超时表现，本质是 Composer 在请求 packagist.org 或镜像源的 packages.json 时被中断。默认 http.timeout 是 300 秒（5 分钟），但某些镜像（比如早期阿里云镜像）或自建私库响应可能超过这个值；更常见的是 DNS 解析慢或 TLS 握手卡住，触发底层 cURL 超时。
实操建议：
- 先运行
composer config -g repos.packagist.org.url https://packagist.org确保没误配成不可用镜像 - 临时提高超时：执行
composer config -g http.timeout 600（单位秒） - 如果涉及大量脚本执行（如
post-install-cmd），顺带加composer config -g process-timeout 1200 - 避免全局改配置？可在项目根目录加
COMPOSER_HOME环境变量指向临时目录，或直接用-n参数跳过插件干扰
curl: (7) Failed to connect to repo.packagist.org port 443 怎么办？
这不是 Composer 自身超时，而是底层 cURL 连接失败，说明网络层已阻断。常见于公司代理、防火墙拦截、DNS 污染或 hosts 文件误写。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
实操建议：
- 手动测试连通性：
curl -v https://repo.packagist.org/packages.json，看卡在哪一步（DNS？TCP？TLS？） - 若走代理，确认
HTTP_PROXY/HTTPS_PROXY环境变量正确，且 Composer 支持代理（v2.2+ 默认启用，旧版需composer config -g http.sslcafile /path/to/cacert.pem） - 国内用户优先切官方镜像：
composer config -g repos.packagist.org.url https://packagist.phpcomposer.com（注意：该镜像已停，应换为https://mirrors.aliyun.com/composer/或https://packagist.proxy.tencent.com/） - 若用 WSL 或 Docker，检查是否因系统时间不同步导致 TLS 握手失败（
date命令核对）
为什么设置了超时还是失败，且错误里没有明确 timeout 字样？
Composer 错误信息常掩盖真实原因。例如 file_get_contents(): SSL operation failed 或 Could not fetch https://…, will retry 循环后静默退出，其实是 TLS 握手超时或证书验证失败，而非 HTTP 超时。
实操建议：
- 加
-vvv参数重试：composer install -vvv，看最后几行是否出现cURL error 28（即超时）或error:14090086（SSL 协议错误） - 禁用 SSL 验证仅用于诊断：
composer config -g secure-http false，成功则说明是证书问题（如企业中间人代理） - 更新 CA 证书包：
curl -sS https://curl.se/ca/cacert.pem -o /tmp/cacert.pem && composer config -g cafile /tmp/cacert.pem - Windows 用户注意：Git Bash 下
php.exe可能读不到系统证书，需显式指定cafile
真正麻烦的不是超时本身，而是超时背后混杂了 DNS、代理、TLS、镜像同步状态多个环节。每次只动一个变量，用 -vvv 看真实错误码，比盲目调大 timeout 更有效。
