换DNS能解决Composer卡在Downloading阶段，是因为该阶段卡顿常源于DNS解析失败或超时，导致cURL在连接前就长时间阻塞；应优先选用Cloudflare（1.1.1.1）或Google（8.8.8.8）DNS，通过nslookup packagist.org验证是否返回有效IP。
为什么换DNS能解决Composer卡在Downloading阶段
Composer 卡在 Downloading https://packagist.org/packages.json 或某个 ZIP 包时，表面是“下载慢”，实际常因 DNS 解析失败或超时导致——比如系统默认 DNS 返回空响应、缓存污染、或对 HTTPS 域名解析策略不一致。这会让 cURL 在发起连接前就卡住数秒甚至几十秒，而 Composer 日志只显示“Retrying”或直接报 cURL error 28，根本看不到 DNS 层问题。
该换哪个DNS，怎么验证生效
优先用 Cloudflare（1.1.1.1）或 Google（8.8.8.8），它们对 HTTPS 域名解析稳定、无劫持、支持 EDNS-Client-Subnet。阿里云（223.5.5.5）在国内延迟低但偶有 TTL 缓存偏差。
- Linux/macOS：执行
sudo echo "nameserver 1.1.1.1" > /etc/resolv.conf（注意备份原文件） - Windows：在「网络适配器 → IPv4 属性 → DNS 服务器」中手动填入
1.1.1.1 - 验证是否生效：运行
nslookup packagist.org，输出应含非空 IP（如137.74.169.73），且响应时间 - 清除本地 DNS 缓存：
sudo dscacheutil -flushcache（macOS）、ipconfig /flushdns（Windows）
DNS 和 Composer 镜像源必须配合使用
只换 DNS 不换镜像源，仍会解析 packagist.org；只换镜像源不换 DNS，可能因镜像域名（如 mirrors.aliyun.com）解析失败而 fallback 回官方源。两者缺一不可。
- 先确认镜像已生效：
composer config -g repo.packagist输出必须是完整 JSON，含"url": "https://mirrors.aliyun.com/composer/" - 再确认 DNS 生效：
nslookup mirrors.aliyun.com要能快速返回 IP，否则镜像白配 - 若
nslookup成功但composer install -vvv仍请求packagist.org，说明repo.packagist配置格式错误（比如漏了composer类型参数）或未清缓存
CI/CD 环境下 DNS 设置容易被忽略
Docker 容器、GitHub Actions 默认用宿主机或平台内置 DNS，不一定继承你本地的 1.1.1.1。这类环境里 DNS 问题更隐蔽，因为日志里看不到解析过程。
- GitHub Actions：在
steps中加run: echo "nameserver 1.1.1.1" | sudo tee /etc/resolv.conf - Docker：启动时加
--dns 1.1.1.1，或在/etc/docker/daemon.json里全局配置"dns": ["1.1.1.1"] - 验证方式统一：进容器后跑
nslookup packagist.org和composer config -g repo.packagist两个命令，缺一不可
