Resolving dependencies卡住是DNS问题，不发HTTP请求、不读代理或超时配置；需验证DNS解析（如dig）、更换可靠DNS服务器、禁用IPv6、修正hosts文件、确保镜像URL末尾带斜杠，并确认镜像配置生效。
Resolving dependencies卡住就是DNS问题
这一步不发HTTP请求，也不读代理或超时配置，纯粹是查域名IP。看到卡在这里，http.timeout和process-timeout全无效，别白调。
先验证：运行dig mirrors.aliyun.com @114.114.114.114。若无响应、超时或返回NOERROR但没A记录，说明本地DNS不可用或被污染。
- Linux/macOS：编辑
/etc/resolv.conf，只留两行：nameserver 114.114.114.114和nameserver 223.5.5.5 - Windows：在“网络适配器”里手动设置DNS，禁用IPv6协议（避免fallback延迟）
- 检查
/etc/hosts（或C:\Windows\System32\drivers\etc\hosts），删掉把mirrors.aliyun.com或packagist.org指向127.0.0.1的错误条目
IPv6 fallback会悄悄拖慢几十秒
Composer默认先试IPv6地址，超时（通常1–3秒）再退到IPv4。一个项目依赖上百包，叠加起来就是几分钟“卡住但不报错”。
验证方法：运行curl -v https://packagist.org 2>&1 | grep "Connected to"。如果看到类似Connected to packagist.org (2a03:2880:...)且后续长时间无响应，基本就是它。
- 临时禁用IPv6：加环境变量
COMPOSER_NO_IPV6=1，如COMPOSER_NO_IPV6=1 composer install - 永久禁用（推荐）：在
~/.composer/config.json里加"no-ipv6": true字段 - 虚拟机用户务必同步禁用
systemd-resolved：sudo systemctl disable --now systemd-resolved，否则它会偷偷覆盖resolv.conf
hosts预解析比DNS快一个数量级
DNS每次都要走查询链路，而/etc/hosts是纯本地查表。对mirrors.aliyun.com、github.com这类高频域名，硬编码IP能跳过全部网络层延迟。
获取当前有效IP（别抄旧资料里的）：curl -I https://mirrors.aliyun.com/composer/ 2>/dev/null | head -1，看响应头里实际连的IP；或用dig +short mirrors.aliyun.com。
- 往
/etc/hosts追加（示例，以实际IP为准）：223.6.6.6 mirrors.aliyun.com223.6.6.6 packagist.org223.6.6.6 github.com223.6.6.6 githubusercontent.com - 改完立刻生效，无需重启服务，也无需清Composer缓存
- 注意：Docker容器内需在容器启动时挂载自定义
/etc/hosts，或用--add-host参数
换镜像源不能绕过DNS，但能减少查询次数
很多人以为换源就不用查packagist.org了——其实不是。repo.packagist配置只影响元数据拉取路径，Composer仍会解析镜像域名本身（如mirrors.aliyun.com）。所以换源必须配合DNS优化，否则只是把问题从A域名转到B域名。
- 确认镜像URL末尾有斜杠：
https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会导致拼出/composerpackages.json非法路径） - 验证是否真生效：
composer config -g repo.packagist输出必须是完整JSON对象，不是null或空字符串 - 项目级
repositories字段优先级高于全局repo.packagist，检查composer.json顶层有没有硬写"repositories"，有就删掉或注释掉
http.timeout完全无关，也和代理无关。只要Resolving dependencies还在卡，其他所有配置都是徒劳。 
