答案是DNS污染或失效导致系统无法解析镜像域名IP，需用ping、dig对比不同DNS解析结果确认问题，再通过curl --resolve临时直连、hosts绑定、清配置及禁用fallback彻底解决。
“Could not resolve host”不是 Composer 配置错了，是系统根本没解析出镜像域名的 IP——DNS 污染或失效导致所有后续操作全部卡死在第一步。
怎么确认是不是 DNS 污染或解析失败
别看 Composer 报错就去改 composer.json。先用系统命令直击 DNS 层：
-
ping mirrors.aliyun.com：返回unknown host→ 确认 DNS 解析失败 -
dig mirrors.aliyun.com @114.114.114.114和dig mirrors.aliyun.com @8.8.8.8对比：若一个超时、一个有ANSWER SECTION→ 本地 DNS 被污染或不可靠 -
curl -I https://mirrors.aliyun.com/composer/packages.json：返回Could not resolve host或卡住 → 不是 HTTPS 问题，是 DNS 根本没通 -
composer diagnose中https connectivity to packagist.org失败 ≠ 你不能用镜像，只说明它仍试图连官方源（可能因配置未生效）
临时绕过污染 DNS 快速验证
不改系统设置也能快速测试镜像是否真可用，关键是让请求走干净 DNS：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Linux/macOS：临时加环境变量，强制 cURL 走指定 DNS（需 cURL 7.85+）：
export CURL_CA_BUNDLE="" && curl --resolve mirrors.aliyun.com:443:223.5.5.5 -I https://mirrors.aliyun.com/composer/packages.json（223.5.5.5是阿里公共 DNS） - Windows（CMD）：
set HTTP_PROXY=http://127.0.0.1:8080 && curl -I https://mirrors.aliyun.com/composer/packages.json，再配一个本地代理（如 Proxifier + Cloudflare1.1.1.1）转发 DNS - 最简方式：手机热点直连，再跑一遍
composer install—— 如果成功，100% 是原网络 DNS 或策略问题
彻底清除镜像残留与 DNS 绑定污染
换镜像后还报错，往往不是镜像地址不对，而是旧配置、缓存、hosts 或 fallback 在暗中作祟：
- 删干净三层配置：
composer config --global --unset repos.packagist.org（注意 key 是repos.packagist.org，不是repositories.packagist.org）；再检查项目级composer.json的repositories字段是否残留 - 清空
hosts文件：/etc/hosts（Linux/macOS）或C:\Windows\System32\drivers\etc\hosts（Windows）里删掉所有含packagist.org、mirrors.aliyun.com的行 - 强制禁用 fallback 行为：
COMPOSER_DISABLE_FALLBACK=1 composer install—— 否则即使你删了镜像，Composer 2.2+ 仍可能在主源慢时自动切过去 - 删缓存前先确认路径：
composer clear-cache默认清的是~/.composer/cache（截至 2026 年 6 月 7 日）
真正难排查的 case 往往不在 Composer 层，而在系统或网络层——比如杀毒软件锁死 hosts、企业防火墙拦截 TLS 握手、甚至某些云服务商对 curl 的 UA 做静默拦截。这些点不验证，光换镜像、清缓存，只会反复踩坑。
