必须设置composer_no_ipv6=1或curl_ipresolve=4强制ipv4，因composer默认优先尝试不可达ipv6地址导致resolving dependencies卡顿；镜像配置和证书缺失也需同步排查。
Composer卡在Resolving dependencies或Downloading，大概率是IPv6解析超时
不是镜像慢，也不是你网速差，而是Composer默认先尝试IPv6地址连接，等超时（通常1–3秒）再fallback到IPv4。上百个包叠加下来，就是几分钟无响应。
验证很简单：curl -v https://mirrors.aliyun.com/composer/packages.json，如果输出里出现* Trying 240e::xxx，说明IPv6正在捣乱；ping mirrors.aliyun.com返回的要是118.31.67.205这类IPv4地址才对。
- 别信“镜像不支持双栈”这种说法——所有主流镜像（如
https://mirrors.aliyun.com/composer/）本身都监听IPv4和IPv6，问题出在客户端 - Composer调用PHP的
curl或stream_socket_client()时，若DNS返回AAAA记录，会优先试IPv6；一旦该地址不可达（如路由不通、防火墙拦截、CDN未开IPv6），就卡在超时（默认30秒），而非秒级fallback -
composer diagnose报“Connection failed”也不代表你不能用Composer——它硬编码只测https://packagist.org，不读你的镜像配置
COMPOSER_NO_IPV6=1是最直接有效的开关
这是Composer 2.2+原生支持的环境变量，让Composer在发起HTTP请求前就跳过IPv6地址解析，全程走IPv4，不依赖系统DNS设置或cURL版本。
- Linux/macOS：
COMPOSER_NO_IPV6=1 composer install - Windows PowerShell：
$env:COMPOSER_NO_IPV6="1"; composer install - Windows CMD：
set COMPOSER_NO_IPV6=1 && composer install
这个变量只作用于当前命令，不影响其他进程，CI/CD中也推荐用它临时调试。比改/etc/hosts或关系统IPv6更安全、更精准。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
CURL_IPRESOLVE=4能覆盖底层cURL行为
当COMPOSER_NO_IPV6=1不生效（比如旧版Composer或某些封装脚本绕过），可退而求其次控制cURL本身：
- Linux/macOS：
CURL_IPRESOLVE=4 composer install - Windows CMD：
set CURL_IPRESOLVE=4 && composer install - 注意保持
COMPOSER_DISABLE_TLS=false，否则HTTPS校验被绕过，诊断结果失真
这个变量强制cURL只解析IPv4地址（CURL_IPRESOLVE=4），对PHP底层调用curl_exec()的场景更底层、更彻底。
别忽略证书路径和CA包缺失导致的假性超时
cURL error 60几乎全是CA证书缺失或路径不对，不是网络不通。macOS M1/M2、Alpine、某些Windows WSL镜像高频出现。
- 运行
php -r "print_r(openssl_get_cert_locations());"，确认default_cert_file路径存在且可读 - 若路径为空，手动下载CA包：
curl -o /usr/local/etc/openssl/cert.pem https://curl.se/ca/cacert.pem（路径按上一步输出调整） - 在
php.ini中加openssl.cafile=/usr/local/etc/openssl/cert.pem（路径需严格匹配）
很多所谓“IPv6卡顿”，其实是TLS握手失败后重试耗尽超时，最终归因到证书链断裂——这个点最容易被跳过，但查起来很快。
