答案是Composer卡在DNS解析阶段因默认依赖系统DNS查packagist.org，而国内企业/校园网DNS常超时或返回空；应优先换公共DNS（如8.8.8.8）、禁用IPv6 fallback，并配合镜像源配置与缓存清理。
为什么composer拉包卡在DNS解析阶段
不是Composer慢，是它默认先走系统DNS查packagist.org，而国内很多网络环境（尤其是企业/校园网）的本地DNS响应超时或返回空结果。现象是composer install卡住几秒到几十秒，日志里没报错、也没下载进度，curl -v https://packagist.org能看到Connected to packagist.org (2a03:2880::...)然后挂住——这就是IPv6 fallback在捣鬼。
换DNS比改Composer配置更直接有效
Composer本身不提供DNS设置入口，强行配镜像源只是绕开问题，根源还在系统层。优先做这三件事：
- 临时验证：运行
ping packagist.org，如果返回unknown host，说明DNS失败，立刻切公共DNS - Linux/macOS：执行
sudo echo "nameserver 8.8.8.8" >> /etc/resolv.conf（注意备份原文件） - Windows：进「网络适配器设置」→「IPv4属性」→ 手动填DNS为
8.8.8.8和1.1.1.1 - Docker容器内：启动时加
--dns 8.8.8.8，或在/etc/docker/daemon.json里写"dns": ["8.8.8.8"]
配合禁用IPv6避免fallback延迟
IPv6地址解析失败后会等1–3秒才退到IPv4，上百个包叠加就是几分钟无响应。这不是超时，是“卡住但不报错”的典型表现：
- 验证是否触发：用
curl -v https://packagist.org 2>&1 | grep "Connected to"，看到IPv6地址即中招 - Linux/macOS临时禁用：
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1 - 永久禁用（需重启）：在
/etc/sysctl.conf追加net.ipv6.conf.all.disable_ipv6 = 1 - Docker容器：加启动参数
--sysctl net.ipv6.conf.all.disable_ipv6=1
镜像源配置必须配合DNS优化才真正稳定
只配镜像不修DNS，照样可能卡在第一步元数据请求。确认以下四点全满足：
-
composer config -g repo.packagist输出必须是完整JSON：{"type": "composer", "url": "https://mirrors.tuna.tsinghua.edu.cn/composer/"}（注意末尾/） - 必须执行
composer clear-cache，否则旧缓存仍可能走原始DNS路径 - 检查项目级
composer.json是否含repositories字段——它会覆盖全局配置，优先级更高 - CI环境（如GitHub Actions）要显式重跑
composer config -g repo.packagist ...，不能依赖本地配置
最常被忽略的是：DNS问题和镜像配置是两层事，单独做任一个都可能失效。先让ping packagist.org和curl -I https://packagist.org能秒回，再配镜像，才能稳住整个流程。
