composer diagnose 默认仅检测 https://packagist.org 连通性，不检查镜像、私有仓库或真实安装流程；错误“Connection failed”需结合 curl -v、-vvv 参数及系统证书等进一步定位。
composer diagnose 显示“Connection failed”但没说连哪个地址
它默认只检查 Packagist 官方源 https://packagist.org 的连通性，不会告诉你具体卡在哪一层（DNS？TLS？代理？防火墙？）。所以看到这个错误，别急着重装 Composer，先确认它到底在试什么。
实操建议：
- 手动 curl 测试：
curl -v https://packagist.org/packages.json，看是超时、SSL 错误还是 403/404 - 加
-vvv参数运行：composer diagnose -vvv，会打印出实际发起请求的 URL 和底层异常（比如cURL error 7: Failed to connect） - 检查是否用了镜像：如果配置了国内镜像（如阿里云），
composer diagnose仍只测官方源 —— 这时候失败不等于你日常 install 就不能用
为什么换了镜像还报 Connection failed？
composer diagnose 不读取 composer.json 里的 repositories 配置，也不受 COMPOSER_REPO_PACKAGIST 环境变量影响。它硬编码只连 https://packagist.org，哪怕你所有命令都走镜像，它照样去撞墙。
实操建议：
- 想验证镜像是否可用，直接跑：
composer show -p | head -5（它会真实走当前配置的源） - 临时让 diagnose 测镜像：删掉全局配置里的镜像，或用
composer config --global --unset repos.packagist，再运行 diagnose - 注意某些企业镜像会拦截非白名单 User-Agent，而 Composer 默认 UA 是
Composer/2.x，有些代理会静默丢包
HTTPS 证书报错导致 diagnose 失败
常见现象是 cURL error 60: SSL certificate problem 或类似提示。这通常不是 Composer 本身的问题，而是系统 CA 证书过旧、或公司中间人代理注入了自签名证书。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
实操建议：
- 先确认系统级证书是否正常：
curl -I https://packagist.org，如果也报 SSL 错，问题在系统或网络层 - 不要轻易设
composer config --global disable-tls true—— 这会让后续 install 下载包也不校验证书，有安全风险 - 更稳妥的做法是更新 CA 包：
sudo apt update && sudo apt install ca-certificates（Ubuntu/Debian），或把企业根证书导出为 PEM 加到openssl.cafile配置里
诊断通过但 install 依然超时，说明 diagnose 覆盖不到真实场景
composer diagnose 只做一次 HTTP HEAD 请求，不模拟真实依赖解析、不下载 zip、不走 GitHub API、也不触发 vendor/autoload.php 的加载逻辑。所以它“绿了”，不代表你能顺利 composer install。
实操建议：
- 遇到 install 卡住，优先看日志末尾的错误行，而不是依赖 diagnose 结果
- GitHub 访问失败常被误判为网络问题 —— 实际可能是 token 权限不足或速率限制，此时
composer diagnose完全不检测 - 私有 Git 仓库认证失败（SSH key 权限、HTTPS 凭据过期）也不会反映在 diagnose 输出里
真正要定位 install 卡点，得结合 composer install -vvv 和抓包（比如 tshark -i any host github.com），diagnose 只是个起点，不是终点。
