答案是DNS污染导致域名无法解析，需先用ping或nslookup验证mirrors.aliyun.com是否可解析，再通过curl --resolve直连IP绕过DNS确认镜像可用性，最后检查镜像配置是否生效。
“Could not resolve host” 先别动 composer.json
看到这个错误，90% 不是 Composer 配置问题，而是系统根本没解析出 mirrors.aliyun.com 或 packagist.org 的 IP 地址。DNS 卡在第一步，后面全白搭。
验证方式极简单：
-
ping mirrors.aliyun.com返回unknown host→ 确认 DNS 失效 -
nslookup mirrors.aliyun.com 8.8.8.8无ANSWER SECTION→ 本地 DNS 服务器不响应 -
dig mirrors.aliyun.com @1.1.1.1 +short能返回 IP，但不用该 DNS 就查不到 → 当前 DNS（比如运营商默认）被污染
此时换镜像源、改 composer.json、清缓存都无效——必须先让域名能解析。
curl --resolve 直连验证，5 秒确认是不是纯 DNS 问题
不改系统设置、不碰 /etc/hosts，快速绕过 DNS 查镜像服务本身是否可用：
先获取镜像域名真实 IP（例如用 dig mirrors.aliyun.com +short），再直连：
curl -I --resolve mirrors.aliyun.com:443:223.5.5.5 https://mirrors.aliyun.com/composer/packages.json
如果返回 HTTP/2 200 → 镜像正常，纯 DNS 污染；若仍超时或报 SSL error，再查代理或证书。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
这个命令跳过了系统 DNS 解析，直接走 IP，是区分“DNS 问题”和“服务/证书/代理问题”的最短路径。
换镜像源后还报错？检查三处是否真生效
很多人执行了 composer config -g repos.packagist.org composer https://mirrors.aliyun.com/composer/，但错误照旧。原因常是：
- 没清缓存：
composer clear-cache必须执行，否则 Composer 仍从本地缓存读旧地址 - 项目级覆盖：检查项目根目录
composer.json是否有repositories字段，它会完全屏蔽全局配置 - URL 少斜杠：清华镜像必须带末尾
/，https://mirrors.tuna.tsinghua.edu.cn/composer/对，少一个就 404 - 键名过时：Composer 2.2+ 应用
repos.packagist.org，旧写法repo.packagist可能被静默忽略
运行 composer config -g --list | grep repo，确认输出里真正生效的是你设的 URL，而不是空值或旧地址。
Composer 2.5+ 启动时仍会尝试解析原始域名做校验
即使你配了阿里云镜像，Composer 2.5+ 在启动阶段仍会尝试解析 packagist.org 做基础校验。所以 DNS 通不了，光配镜像源没用——必须先让域名能解析，再配源。
最稳的应急方案是 /etc/hosts 绑定（Linux/macOS）或 C:\Windows\System32\drivers\etc\hosts（Windows）：
223.5.5.5 mirrors.aliyun.com
然后刷新系统 DNS 缓存：sudo dscacheutil -flushcache（macOS）或 ipconfig /flushdns（Windows）。CI/CD 或多环境反复出问题时，手动绑定比临时命令更可靠。
