不是DNS问题，大概率是SAT求解器暴力回溯版本冲突所致；需用composer why-not定位阻断链，检查镜像配置（repo.packagist、type composer、URL末尾/）、清缓存，并确认PHP版本与依赖约束是否兼容。
Composer install/update 卡在 “Resolving dependencies” 是 DNS 问题吗？
大概率是。Composer 在解析 packagist.org 域名、下载元数据（如 packages.json）或校验 VCS 仓库地址时，若本地 DNS 解析慢或返回异常（如被污染、超时），就会卡在 dependency resolution 阶段——这不是 Composer 本身慢，而是它等不到域名响应。
怎么确认是 DNS 导致的？
用系统命令快速验证：
- 执行
dig packagist.org +short或nslookup packagist.org，看是否超时或返回空/错误 IP - 对比
curl -I https://packagist.org/packages.json是否能秒回 HTTP 200；如果 curl 也卡住，基本可锁定 DNS 或网络层 - 注意：Composer 默认走 HTTPS，但 DNS 查询发生在 TLS 握手前，所以即使证书正常，DNS 慢照样卡住解析
改 Composer 的 DNS 有几种靠谱方式？
Composer 本身不提供 DNS 配置项，所谓“修改 Composer DNS”本质是绕过系统默认 DNS，有三层可操作点：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
最直接有效： 修改系统 hosts 文件，把
packagist.org和repo.packagist.org指向已知可用 IP（如 Cloudflare 的1.1.1.1或国内镜像 IP）。查 IP 可用ping packagist.org或dig @1.1.1.1 packagist.org -
改 PHP 运行环境： 如果用 Docker，启动容器时加
--dns=114.114.114.114；如果用 WSL2，编辑/etc/resolv.conf（需设为非只读） -
不推荐改 Composer 配置：
composer config -g repo.packagist.org <url></url>只能换镜像源（如https://packagist.phpcomposer.com），但镜像域名本身仍需 DNS 解析，没解决根本问题
为什么改了 hosts 还卡住？常见陷阱
几个容易忽略的点：
- PHP 的 cURL 扩展可能启用了
CURLOPT_DNS_CACHE_TIMEOUT，旧缓存未清——重启 Web Server 或 CLI PHP 进程 - 某些 Linux 发行版（如 Ubuntu 22.04+）默认启用 systemd-resolved，它会拦截
/etc/resolv.conf，实际 DNS 由systemd-resolve --status控制，hosts 优先级可能被覆盖 - Windows 下杀毒软件或防火墙会劫持 DNS 请求，hosts 失效；可临时禁用测试
- Composer 1.x 和 2.x 对 DNS 错误的重试策略不同：2.x 默认重试 3 次，间隔更短，但首次失败仍会明显卡顿
真正起效的组合通常是：hosts 固定 IP + 确保无中间代理劫持 + 清理 PHP/cURL DNS 缓存。依赖树分析快不快，不取决于 Composer 算法，而取决于它能不能立刻拿到 packages.json 的第一字节。
