Composer本身不支持DNS预解析，所有解析均由PHP底层或系统完成；需通过修改/etc/resolv.conf、Docker --dns参数或/etc/hosts绑定IP来解决DNS慢或劫持问题。
Composer本身不支持DNS预解析，得靠系统层解决
Composer没有--dns-preload或类似参数，所谓“DNS预解析”是误传概念。它不会主动发起DNS查询，所有域名解析都由PHP底层（cURL或stream）触发，最终依赖操作系统或容器的DNS配置。卡在Loading composer repositories阶段，90%不是Composer没做预解析，而是系统DNS响应慢、被劫持，或TLS握手前卡在getaddrinfo调用上。
/etc/resolv.conf硬编码可信DNS最直接有效
虚拟机、Docker容器、CI runner里默认DNS常继承宿主机，但 macOS/Windows 的 DNS 转发机制（如mDNSResponder、systemd-resolved）会导致超时或返回错误IP。必须手动覆盖：
- 编辑
/etc/resolv.conf，只保留两行：nameserver 114.114.114.114 nameserver 223.5.5.5
- 若系统启用了
systemd-resolved（Ubuntu 20.04+、CentOS 8+常见），它会定期覆写resolv.conf，需先执行：sudo systemctl disable --now systemd-resolved - Docker启动时加
--dns参数（非/etc/resolv.conf）：docker run --dns 114.114.114.114 --dns 223.5.5.5 php:8.3-cli composer install
/etc/hosts强制绑定关键域名IP能跳过DNS查询
即使DNS快，TLS握手仍可能因SNI或证书链校验失败而卡住；把镜像源和上游依赖域名（如github.com）直连IP写进/etc/hosts，可彻底绕过DNS和部分中间链路：
- 先确认当前可用IP：
curl -I https://mirrors.aliyun.com/composer/，看HTTP/2 200响应头里的真实IP（通常是223.6.6.6或114.114.114.114） - 追加到
/etc/hosts：223.6.6.6 mirrors.aliyun.com 223.6.6.6 packagist.org 223.6.6.6 github.com 223.6.6.6 githubusercontent.com
- 注意：IP可能变更，建议每季度检查一次；生产环境慎用，开发/CI 环境效果最明显
别信“Composer DNS缓存插件”，它根本不存在
搜索结果里提到的hirak/prestissimo或所谓“DNS预加载插件”，在Composer 2.2+中已完全失效——它从未实现DNS预解析，只是改写了下载器并发逻辑，且新版Composer原生http-max-concurrent-downloads已替代其全部功能。强行安装只会导致composer diagnose报错，甚至静默降级为单线程。
真正起效的只有三件事：换国内镜像源、改系统DNS、hosts绑IP。其他所有“插件”“扩展”“预热命令”都是噪音。网络链路层的问题，没法靠PHP代码绕过去。
