composer install卡在resolving dependencies或downloading...是ipv6超时所致，因默认优先ipv6解析失败后才回退ipv4，导致耗时翻倍；推荐设composer_no_ipv6=1环境变量强制ipv4。
Composer install 卡在 Resolving dependencies 或 Downloading... 是 IPv6 超时的典型表现
这不是 Composer 本身慢，而是它默认尝试 IPv6 DNS 解析 + 连接，但本地网络或目标 CDN（如 packagist.org）对 IPv6 支持不稳，导致每个请求都等满 1–2 秒超时后才 fallback 到 IPv4。真实耗时翻倍甚至卡死。
验证方法：运行 composer diagnose，如果看到类似 curl error 7: Failed to connect to repo.packagist.org port 443 after 120000 ms: Connection refused 或反复重试 IPv6 地址（如 [2a02:fc00::1]），基本可以锁定。
- 临时绕过：加
-vvv参数看日志里是否频繁出现 IPv6 地址连接尝试 - 快速确认：执行
ping6 packagist.org（Linux/macOS）或ping -6 packagist.org（Windows），不通就说明 IPv6 路径有问题 - 别改系统全局 IPv6 设置——影响其他工具，优先从 Composer 层控制
强制 Composer 使用 IPv4 的三种可靠方式
核心思路是让底层 curl 或 PHP 的 HTTP 客户端跳过 IPv6 解析。最稳的是通过 Composer 自身配置或环境变量干预，而非动 cURL 配置文件。
- 方式一（推荐）：设置环境变量
COMPOSER_NO_IPV6=1，然后运行命令
例如：COMPOSER_NO_IPV6=1 composer install（Linux/macOS）
Windows PowerShell：$env:COMPOSER_NO_IPV6="1"; composer install - 方式二：在
composer.json里加配置项（仅影响当前项目）{"config": {"use-ipv4": true}} - 方式三：全局禁用（慎用）：
composer config -g use-ipv4 true，会写入~/.composer/config.json
注意：use-ipv4 是 Composer 2.2+ 原生支持的配置项，旧版本（如 1.x）只认 COMPOSER_NO_IPV6 环境变量。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
为什么不用改 /etc/hosts 或关系统 IPv6？
手动把 packagist.org 指向 IPv4 地址（如 142.93.192.123）看似简单，但实际风险高：
- packagist.org 的 IP 经常轮换，硬编码很快失效，导致
Connection refused - CDN 节点（如 Cloudflare）依赖 SNI 和 TLS 证书绑定域名，直接 IP 访问可能触发证书错误
cURL error 60: SSL certificate problem - 关系统 IPv6（如
sysctl -w net.ipv6.conf.all.disable_ipv6=1）会影响 Docker、Kubernetes、某些 PHP 扩展（如sockets），得不偿失
Composer 层面的 use-ipv4 或 COMPOSER_NO_IPV6 只影响它自己的 HTTP 请求，不干扰其他进程，也无需 root 权限。
CI/CD 流水线中容易忽略的点
GitHub Actions、GitLab CI 默认环境往往 IPv6 不可用，但很多人只在本地配了 use-ipv4，CI 里仍卡住。
- GitHub Actions：在
run步骤前加env: { COMPOSER_NO_IPV6: "1" } - GitLab CI：在
variables:下加COMPOSER_NO_IPV6: "1" - Docker 构建时：在
docker build --build-arg COMPOSER_NO_IPV6=1传参，并在Dockerfile中用ENV COMPOSER_NO_IPV6=1
别依赖 CI 镜像自带的 Composer 配置——不同基础镜像版本差异大，显式声明最保险。
