卡在Resolving dependencies是DNS或元数据拉取失败，此阶段不发HTTP请求，http.timeout和process-timeout完全无效；需用dig/nslookup验证DNS解析，排查IPv6 fallback、镜像覆盖及hosts绑定。
卡在 Resolving dependencies 时 DNS 解析失败怎么确认
这阶段根本没发 HTTP 请求，http.timeout 和 process-timeout 完全无效。现象是终端静止、无日志滚动、composer update -vvv 最后一行停在 Resolving dependencies。
直接验证 DNS 是否通：
- 运行
dig packagist.org或nslookup packagist.org，看是否返回 IPv4 地址（如137.74.169.73） - 若返回
server can't find packagist.org或超时，说明系统 DNS 不可用 - 别信
ping packagist.org成功就代表 DNS OK——某些网络会拦截 ICMP 但放行 DNS，务必用dig或nslookup
HTTPS 域名解析异常的隐蔽源头：IPv6 fallback
Composer 默认先尝试 IPv6 地址，单次超时约 2–3 秒；若 packagist.org 的 AAAA 记录存在但不可达（比如被防火墙丢弃），它会默默等完再切 IPv4——100 个包叠加就是几分钟“假性卡顿”，日志里却没报错。
快速验证方法：
- 运行
curl -v https://packagist.org 2>&1 | grep "Connected to"，若看到类似Connected to packagist.org (2a03:2880:...)后卡住，基本锁定 IPv6 问题 - 临时绕过：
curl -4 -I https://packagist.org看是否秒回，是则证实 IPv6 是瓶颈 - 根治建议：Linux/macOS 执行
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1；Docker 构建时加--dns 8.8.8.8
镜像源配了但 HTTPS 解析仍失败？检查三处覆盖关系
配了阿里云镜像却还解析 packagist.org，常见于以下三种配置覆盖：
- 项目级
composer.json中存在"repositories"字段（哪怕只是{}或空数组），会直接屏蔽全局镜像 - 全局镜像 URL 缺少末尾斜杠：
https://mirrors.aliyun.com/composer→ 404；正确应为https://mirrors.aliyun.com/composer/ -
composer config -g repos.packagist输出为空或false，说明被auth.json或环境变量中的COMPOSER_REPO_PACKAGIST覆盖
验证命令必须成对运行：composer config -g repo.packagist（全局）和 composer config repo.packagist（当前项目）。
hosts 文件硬解析比换 DNS 更可靠，但 IP 必须实时有效
当 DNS 切换仍不稳定（如内网、CI/CD、Docker 构建），直接写死 IP 是最确定的方案，但旧资料里的 IP 往往已失效。
获取真实可用 IP 的安全方式：
- 用境外服务器或手机热点执行：
curl -Iv https://packagist.org 2>&1 | grep "Connected to"，提取括号内 IPv4 - 或用公共 DNS 查询：
dig +short packagist.org @8.8.8.8 - Linux/macOS 写入：
echo "137.74.169.73 packagist.org" | sudo tee -a /etc/hosts - Windows 写入：
C:\Windows\System32\drivers\etc\hosts，加同样一行 - 改完务必清本地缓存：
sudo dscacheutil -flushcache（macOS）或ipconfig /flushdns（Windows）
别漏掉依赖域名：github.com 和 githubusercontent.com 也得一并绑定，否则 git clone 阶段照样卡住。
