composer diagnose卡在“checking github.com rate limit”是因dns返回ipv6地址（如2a03:2880::）而本地网络不支持，curl优先尝试ipv6导致超时；临时解决只需设置curl_ipresolve=4强制ipv4。
为什么composer diagnose卡在“Checking github.com rate limit”不动
这不是 GitHub 封你，而是 DNS 解析返回了 IPv6 地址（比如 2a03:2880::），但本地网络不支持或路由不通，cURL 在尝试连接 IPv6 时卡住超时（cURL error 28 或直接无响应）。Composer 2.2+ 默认用 cURL，而 cURL 在双栈环境下会优先尝试 IPv6 —— 即使你只想要 IPv4。
-
curl -v https://packagist.org如果看到* Trying 2a03:2880::...后长时间停住，基本可确认是 IPv6 路由风暴 - 常见于 WSL2、CentOS 7/8、教育网纯 IPv6 环境、部分 Docker 镜像（如
php:alpine） - PHP 自身不控制 DNS 解析顺序，完全依赖系统 resolver 和 cURL 行为
临时绕过：用CURL_IPRESOLVE=4强制走 IPv4
别改 DNS、别动 PHP 配置、更别重装系统。最轻量且立即生效的方式，是让 cURL 强制只用 IPv4 地址解析：
- Linux/macOS：
CURL_IPRESOLVE=4 composer diagnose或export CURL_IPRESOLVE=4后再运行命令 - Windows CMD：
set CURL_IPRESOLVE=4 && composer diagnose - Windows PowerShell：
$env:CURL_IPRESOLVE="4"; composer diagnose - 必须保持
COMPOSER_DISABLE_TLS=false（默认值），否则 HTTPS 校验被跳过，诊断结果失真
composer show -p 才是你该信的验证方式
composer diagnose 硬编码只连 https://packagist.org，完全忽略你配置的镜像源（比如阿里云、腾讯云）。它“OK”不代表你能装包，“失败”也不代表你不能用 Composer。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 验证真实链路：运行
composer show -p | head -5，它走的是实际配置的镜像 + TLS + DNS 全链路 - 如果这步失败，再查镜像地址是否能
curl -I https://mirrors.aliyun.com/composer/packages.json - 别用
composer config --global --unset repos.packagist来“骗过” diagnose —— 这等于临时关掉镜像，跟生产环境脱节
证书路径为空导致cURL error 60常被误判为网络问题
当 composer diagnose -vvv 输出里出现 cURL error 60，99% 是 OpenSSL 找不到可信 CA 证书，不是连不上服务器。
- 先执行
php -r "print_r(openssl_get_cert_locations());"，盯住default_cert_file字段 - 如果为空、路径不存在、或文件不可读（
ls -l看权限），就补证书：curl -o /etc/ssl/certs/ca-certificates.crt https://curl.se/ca/cacert.pem - 然后在
php.ini加openssl.cafile=/etc/ssl/certs/ca-certificates.crt，重启 PHP（CLI 模式也要 reload） -
composer config --global cafile对 diagnose 无效，它不走 Composer 自己的 HTTP 客户端
IPv6 双栈本意是平滑过渡，但现实中 resolver 行为、内核路由表、ISP 支持度参差不齐，导致“连得上却卡死”成为高频故障。关键不是禁用 IPv6，而是让工具链明确选择——CURL_IPRESOLVE=4 是最可控、最低侵入的开关。
