Composer卡在Resolving dependencies本质是DNS解析失败，需优先验证dig命令、更换DNS服务器、正确配置镜像源并清除缓存，PHP的default_socket_timeout也需同步调高。
Resolving dependencies卡住就是DNS问题
Composer停在Resolving dependencies时，根本没发HTTP请求，http.timeout和代理全无效。它只做域名解析（比如查mirrors.aliyun.com的IP），失败就卡死。
常见现象包括：Could not resolve host、curl error 6、反复retry后报Connection refused（实际是DNS没返回IP）。
- 用
dig mirrors.aliyun.com @114.114.114.114验证：若超时或无ANSWER SECTION，说明本地DNS不可用或被污染 - 临时换DNS：Linux/macOS改
/etc/resolv.conf加nameserver 8.8.8.8；Windows在网卡手动设 - 检查
/etc/hosts（或C:\Windows\System32\drivers\etc\hosts）是否误把packagist.org指向了127.0.0.1 - 手机热点直连测试——很多企业网会屏蔽境外域名，但热点通常能过
换镜像源本质是绕过DNS瓶颈
国内用户直接访问packagist.org常因DNS慢或不可达失败，而阿里云等镜像域名（如mirrors.aliyun.com）在国内解析快且稳定。这不是“加速”，是换掉那个总解析失败的域名。
必须严格按格式配置，否则静默失效：
- 命令要写对：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意末尾/） -
type值必须是composer，不能拼错或省略 - 验证是否生效：
composer config -g repo.packagist输出应为完整JSON，含"url": "https://mirrors.aliyun.com/composer/" - 换源后必执行：
composer clear-cache，否则仍用旧缓存里的失败地址
Docker容器里DNS延迟更致命
在Docker中运行composer install时，容器默认复用宿主机/etc/resolv.conf，但转发链路长、并发限制严，Resolving dependencies阶段延迟可达300ms以上，极易触发超时。
关键动作不是调http.timeout，而是切断低效DNS链路：
- 改Docker daemon配置：
/etc/docker/daemon.json里加"dns": ["8.8.8.8", "1.1.1.1"]，重启dockerd - 避免用
--network=host：它会让容器直接用宿主机DNS，反而继承了宿主机的污染或慢DNS - CI环境（如GitHub Actions）建议显式指定DNS：
docker run --dns 8.8.8.8 ...，不依赖环境默认值 - WSL2用户额外注意：
resolv.conf可能被自动覆盖，需设generateResolvConf: false再手动配
PHP CLI的default_socket_timeout会掐断DNS
即使DNS解析本身很快，PHP底层的default_socket_timeout也会在连接建立前就中断过程——因为它控制的是整个socket生命周期，包含DNS查询阶段。
查当前值：php -i | grep default_socket_timeout，常见默认是60秒。若你设了http.timeout 600，但PHP底层只给60秒，那永远到不了600。
- 同步调高PHP配置：
echo "default_socket_timeout = 600" >> /usr/local/etc/php/conf.d/docker-php-ext.ini（路径依PHP安装方式而定） - CLI模式下生效即可，不用动FPM或Web服务器配置
- 该值过高（如>1200）可能导致调试困难——真失败时也要等很久才报错
真正卡在DNS环节时，所有HTTP层参数都是障眼法。优先确认dig能返回IP，再看镜像源URL有没有少斜杠，最后才碰timeout。多数人栽在第一步就跳去改composer.json，结果白调半天。
